[OpenSIPS-Users] t_relay() not relaying payload

Thamer Alharbash talharbash at gmail.com
Wed Feb 3 23:19:43 CET 2010


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

-- 
Thamer







More information about the Users mailing list