[OpenSIPS-Users] t_relay() not relaying payload
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu Feb 4 10:14:43 CET 2010
Hi Thamer,
actually I see a 408 TIMEOUT for the second re-INVITE - but I see not
outgoing re-INVITE in the second step (only the inbound message)
Looking at the 2 re-INVITEs, I would say you have a routing issue as the
first re-INVITE has as RURI a public IP
(sip:1003 at uac.ip.address.here:5060), while the second re-INVITE has a
private IP (sip:1003 at 192.168.2.12:5060)
So, maybe the NAT traversal logic for the sequential requests is not
correct.
Regards,
Bogdan
Thamer Alharbash wrote:
> Hi Bogdan,
>
> Sorry for not getting back sooner. I've updated my config a bit. I'm
> including what our reinvite handling looks like and the two reinvites
> that pass through opensips. The second one as you can see has no
> payload (ngrep shows ...) I have verified this as well under wireshark.
>
> if (has_totag()) {
>
> # sequential request within a dialog should
> # take the path determined by record-routing
>
> if (loose_route()) {
>
> if (is_method("BYE")) {
> setflag(1); # do accounting ...
> setflag(3); # ... even if the
> transaction fails
>
> } else if (is_method("INVITE")) {
> # even if in most of the cases is
> useless, do RR for
> # re-INVITEs also, as some buggy
> clients do change route set
> # during the dialog.
> record_route_preset
> ("proxy.ip.address.here");
> }
> # route it out to whatever destination was
> set by loose_route()
> # in $du (destination URI).
> route(1);
> ...
> route[1] {
> # for INVITEs enable some additional helper routes
> if (is_method("INVITE")) {
> t_on_branch("1");
> t_on_reply("1");
> t_on_failure("1");
> if(has_body("application/sdp")) {
> rtpproxy_offer("frc","proxy.ip.address.here");
> xlog ("Setting rtpproxy_offer");
> }
> if (isbflagset(6)) {
> fix_nated_contact();
> }
>
> }
>
>
>
>
> -- FIRST REINVITE
>
> U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060
> INVITE sip:1003 at uac.ip.address.here:5060;transport=udp;user=phone SIP/
> 2.0.
> Via: SIP/2.0/UDP carrier.ip.address.here:
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b735e0 at 192.168.2.12.
> From: <sip:
> 2165928121 at our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash" <sip:
> 1003 at our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247939 INVITE.
> Expires: 180.
> Min-SE: 1800.
> Session-Expires: 1800;refresher=uac.
> Supported: 100rel,timer.
> Max-Forwards: 69.
> Contact: <sip:2165928121 at our.proxy.ip.address:5060;transport=udp>.
> Content-Type: application/sdp.
> Content-Length: 216.
> Route: <sip:carrier.ip.address.here;lr=on>.
> .
> v=0.
> o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
> s=-.
> c=IN IP4 carrier.ip.address.here.
> t=0 0.
> m=audio 10044 RTP/AVP 0 101.
> a=sendrecv.
> a=ptime:20.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
>
> U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
> SIP/2.0 100 Giving a try.
> Via: SIP/2.0/UDP carrier.ip.address.here:
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b735e0 at 192.168.2.12.
> From: <sip:
> 2165928121 at our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash" <sip:
> 1003 at our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247939 INVITE.
> Server: OpenSIPS (1.6.0-notls (i386/linux)).
> Content-Length: 0.
> .
>
> U our.proxy.ip.address:5060 -> uac.ip.address.here:5060
> INVITE sip:1003 at uac.ip.address.here:5060;transport=udp;user=phone SIP/
> 2.0.
> Record-Route: <sip:our.proxy.ip.address;lr=on>.
> Via: SIP/2.0/UDP our.proxy.ip.address;branch=z9hG4bK20d7.90192965.0.
> Via: SIP/2.0/UDP carrier.ip.address.here:
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0g10.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b735e0 at 192.168.2.12.
> From: <sip:
> 2165928121 at our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash" <sip:
> 1003 at our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247939 INVITE.
> Expires: 180.
> Min-SE: 1800.
> Session-Expires: 1800;refresher=uac.
> Supported: 100rel,timer.
> Max-Forwards: 68.
> Contact: <sip:2165928121 at carrier.ip.address.here:5060;transport=udp>.
> Content-Type: application/sdp.
> Content-Length: 217.
> .
> v=0.
> o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
> s=-.
> c=IN IP4 our.proxy.ip.address.
> t=0 0.
> m=audio 32104 RTP/AVP 0 101.
> a=sendrecv.
> a=ptime:20.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
> -- SECOND REINVITE
>
> U carrier.ip.address.here:5060 -> our.proxy.ip.address:5060
> INVITE sip:1003 at 192.168.2.12:5060;transport=udp;user=phone SIP/2.0.
> Via: SIP/2.0/UDP carrier.ip.address.here:
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b735e0 at 192.168.2.12.
> From: <sip:
> 2165928121 at our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash" <sip:
> 1003 at our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247940 INVITE.
> Expires: 180.
> Min-SE: 1800.
> Session-Expires: 1800;refresher=uac.
> Supported: 100rel,timer.
> Max-Forwards: 69.
> Contact: <sip:2165928121 at carrier.ip.address.here:5060;transport=udp>.
> Content-Type: application/sdp.
> Content-Length: 216.
> Route: <sip:our.proxy.ip.address;lr=on>.
> .
> v=0.
> o=- 3474221042 3474221054 IN IP4 carrier.ip.address.here.
> s=-.
> c=IN IP4 carrier.ip.address.here.
> t=0 0.
> m=audio 10044 RTP/AVP 0 101.
> a=sendrecv.
> a=ptime:20.
> a=rtpmap:0 PCMU/8000.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
>
>
> U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
> SIP/2.0 100 Giving a try.
> Via: SIP/2.0/UDP carrier.ip.address.here:
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b735e0 at 192.168.2.12.
> From: <sip:
> 2165928121 at our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash" <sip:
> 1003 at our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247940 INVITE.
> Server: OpenSIPS (1.6.0-notls (i386/linux)).
> Content-Length: 0.
> .
>
>
> U our.proxy.ip.address:5060 -> uac.ip.address.here:5060
> ....
>
> U our.proxy.ip.address:5060 -> carrier.ip.address.here:5060
> SIP/2.0 408 Request Timeout.
> Via: SIP/2.0/UDP carrier.ip.address.here:
> 5060;branch=z9hG4bK2kspjh305gqgrfskk5s0sbk9m0020.1.
> Call-ID: 3110d9027c77f4e246f17ef1f5b735e0 at 192.168.2.12.
> From: <sip:
> 2165928121 at our.proxy.hostname.here;user=phone>;tag=SD1ko0299-324092c7
> +1+ad440023+8233f214.
> To: "Thamer Al-Harbash" <sip:
> 1003 at our.proxy.hostname.here;user=phone>;tag=83134be1983195b6.
> CSeq: 878247940 INVITE.
> Server: OpenSIPS (1.6.0-notls (i386/linux)).
> Content-Length: 0.
> .
>
> On 1-Feb-10, at 8:55 AM, Bogdan-Andrei Iancu wrote:
>
>
>> Hi Thamer,
>>
>> Could you post the first re-INVITE (received and sent) to see what
>> could
>> be the problem?
>>
>> Regards,
>> Bogdan
>>
>> Thamer Alharbash wrote:
>>
>>> We currently have opensips setup to route through another carrier for
>>> certain calls. All signaling and media works well except for
>>> reinvites.
>>>
>>> if (has_totag()) {
>>>
>>> # sequential request within a dialog should
>>> # take the path determined by record-routing
>>>
>>> if (loose_route()) {
>>> if (is_method("BYE")) {
>>> setflag(1); # do accounting ...
>>> setflag(3); # ... even if the
>>> transaction fails
>>> } else if (is_method("INVITE")) {
>>> # even if in most of the cases is
>>> useless, do RR for
>>> # re-INVITEs alos, as some buggy
>>> clients do change route set
>>> # during the dialog.
>>> record_route_preset("<hidden>");
>>> }
>>> fix_nated_contact();
>>> t_relay();
>>> ...
>>>
>>> The first reinvite passes through fine with the nated contact fixed
>>> for the contact field. The second reinvite does not get relayed
>>> correctly. Instead a udp packet with no SIP payload at all is sent to
>>> the UA. We can't find any particular error in the debug log.
>>>
>>> Does anyone have thoughts on this?
>>>
>>>
>>>
>> --
>> Bogdan-Andrei Iancu
>> www.voice-system.ro
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
More information about the Users
mailing list