[OpenSIPS-Users] t_relay() not relaying payload
Thamer Alharbash
talharbash at gmail.com
Fri Feb 5 02:12:44 CET 2010
Bogdan you are correct.
Thanks for your help. It was an issue with fixing the NATed contact
on the first reply.
On 4-Feb-10, at 4:14 AM, Bogdan-Andrei Iancu wrote:
> 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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Thamer
More information about the Users
mailing list