[OpenSIPS-Users] UPDATE message and sdp

Wed Apr 28 01:53:55 CEST 2010

One follow up on this...and this pains me...I have a gateway that calls us
with no SDP on the INVITE, then we send back a 200 OK w/SDP, and it then
sends back an ACK with SDP.  Now I believe that although very uncommon, does
not violate the spec.  However in this case, I see that the rtpproxy_answer
is set on the 200 OK reply, but the if(has_body("application/sdp")) has no
affect on the ACK.  I'm sure I'm missing something here so any thoughts on
the matter are greatly appreciated.

Thanks

-dg

On Tue, Apr 27, 2010 at 2:56 PM, Daniel Goepp <dan at goepp.net> wrote:

> And just after replying regarding my success (I have been running this for
> many months now without problems), I do have a very specific issue related
> to UPDATE messages.
>
> I have added some logging and for the following call, I get:
>
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Request
> UPDATE: sip:2021@<home_public_ip>:5069 - sip:6502734101 at 192.168.1.110:5060
> ;transport=tcp
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Setting
> rtpproxy_offer - Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Fixing
> Contact - Route 1
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Relay
> message
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: new
> branch route 1 at sip:2021@<home_public_ip>:5069  - sip:6502734101@
> <home_public_ip>:33774;transport=tcp
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: incoming
> reply route 1 - <null> - sip:2021 at 192.168.1.101:5069
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: Found a
> response from a private address! - sip:2021 at 192.168.1.101:5069
> Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: Setting
> rtpproxy_answer - Reply 1
> Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command:
> lookup on ports 30882/29328, session timer restarted
> Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command:
> lookup on ports 31198/28836, session timer restarted
>
> Which to me looks like it is identifying that it needs to fix the SDP, but
> then in the outbound UPDATE the connection IP is still the private address.
> See trace below.  The signaling seems okay otherwise, and the experience
> that I get is that the endpoint being called to (2021) can no longer see the
> calling party (we are testing video).  The 200 OK coming back does not have
> this problem, it's connection IPs in the SDP are rewritten fine, making me
> think perhaps it's something related to just UPDATE message, but I don't
> know enough about the inner workings of OpenSIPS.  Thoughts?
>
> Thanks
>
> -dg
>
> ========================
> 2010-04-27 14:45:49
> tcp:<home_public_ip>:33774 -> tcp:<opensips_ip>:5060
>
> UPDATE sip:2021@<home_public_ip>:5069 SIP/2.0
> Via: SIP/2.0/TCP 192.168.1.110:5060
> ;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport
> Call-ID: 4fdbf3351f21733c at 192.168.1.110
> CSeq: 104 UPDATE
> Contact: <sip:6502734101 at 192.168.1.110:5060;transport=tcp>
> From: <sip:6502734101 at mydomain.com <sip%3A6502734101 at mydomain.com>
> >;tag=7ad977f50f0f9d94
> To: "Daniel Goepp" <sip:2021 at mydomain.com <sip%3A2021 at mydomain.com>
> >;tag=DC151CA5-80A23EC4
> Max-Forwards: 70
> Route: <sip:<opensips_ip>;lr;transport=tcp;transport=tcp>
> Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> Proxy-Authorization: Digest nonce="*****", realm="mydomain.com",
> username="6502734101", uri="sip:mydomain.com", response="*******",
> algorithm=MD5
> Supported: replaces,100rel,timer,gruu,path,outbound
> Session-Expires: 500;refresher=uac
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 455
>
> v=0
> o=tandberg 17 2 IN IP4 192.168.1.110
> s=-
> c=IN IP4 192.168.1.110
> b=CT:768
> t=0 0
> m=audio 2354 RTP/AVP 100 102
> c=IN IP4 192.168.1.110
> b=TIAS:64000
> a=rtpmap:100 G7221/16000
> a=fmtp:100 bitrate=32000
> a=rtpmap:102 telephone-event/8000
> a=fmtp:102 0-15
> a=sendrecv
> m=video 2356 RTP/AVP 97
> b=TIAS:768000
> a=rtpmap:97 H264/90000
> a=fmtp:97
> profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
> a=sendrecv
> a=content:main
> a=label:11
>
> ========================
> 2010-04-27 14:45:49
> udp:<opensips_ip>:5060 -> udp:<home_public_ip>:5069
>
> UPDATE sip:2021@<home_public_ip>:5069 SIP/2.0
> Record-Route: <sip:<opensips_ip>;lr;transport=tcp>
> Via: SIP/2.0/UDP <opensips_ip>;branch=z9hG4bK7e7f.ef3c6013.0;i=9
> Via: SIP/2.0/TCP 192.168.1.110:5060
> ;received=<home_public_ip>;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport=33774
> Call-ID: 4fdbf3351f21733c at 192.168.1.110
> CSeq: 104 UPDATE
> Contact: <sip:6502734101@<home_public_ip>:33774;transport=tcp>
> From: <sip:6502734101 at mydomain.com <sip%3A6502734101 at mydomain.com>
> >;tag=7ad977f50f0f9d94
> To: "Daniel Goepp" <sip:2021 at mydomain.com <sip%3A2021 at mydomain.com>
> >;tag=DC151CA5-80A23EC4
> Max-Forwards: 69
> Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
> User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)
> Proxy-Authorization: Digest nonce="*****", realm="mydomain.com",
> username="6502734101", uri="sip:mydomain.com", response="****",
> algorithm=MD5
> Supported: replaces,100rel,timer,gruu,path,outbound
> Session-Expires: 500;refresher=uac
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 455
>
> v=0
> o=tandberg 17 2 IN IP4 192.168.1.110
> s=-
> c=IN IP4 192.168.1.110
> b=CT:768
> t=0 0
> m=audio 2354 RTP/AVP 100 102
> c=IN IP4 192.168.1.110
> b=TIAS:64000
> a=rtpmap:100 G7221/16000
> a=fmtp:100 bitrate=32000
> a=rtpmap:102 telephone-event/8000
> a=fmtp:102 0-15
> a=sendrecv
> m=video 2356 RTP/AVP 97
> b=TIAS:768000
> a=rtpmap:97 H264/90000
> a=fmtp:97
> profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
> a=sendrecv
> a=content:main
> a=label:11
>
> -dg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100427/fcfd56e8/attachment.htm 