[OpenSIPS-Users] UPDATE message and sdp
Daniel Goepp
dan at goepp.net
Wed Apr 28 20:15:43 CEST 2010
Damn, I'm sorry, I completely missed that example in the doc...my bad...it
shows exactly how to switch the offer/answer based on an sdp in the original
invite or not, then branching to different reply routes and testing for sdp
in the 200 and ACK. Thanks for pointing that out!
-dg
On Wed, Apr 28, 2010 at 2:51 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:
> For such cases (SDP negotiation via 200OK + ACK), see the "s" flag in
> the force_rtp_proxy() function:
>
> http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id271384
>
> Also, you are saying that has_body(sdp) does not work on the ACK ? can
> you post the ACK request you test?
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > 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
> > <mailto: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
> > <http://sip:2021@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 <http://sip:2021@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
> > <mailto: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>
> > <mailto:sip%3A6502734101 at mydomain.com<sip%253A6502734101 at mydomain.com>
> >>;tag=7ad977f50f0f9d94
> > To: "Daniel Goepp" <sip:2021 at mydomain.com <sip%3A2021 at mydomain.com>
> > <mailto:sip%3A2021 at mydomain.com <sip%253A2021 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
> > <http://mydomain.com>", username="6502734101",
> > uri="sip:mydomain.com <http://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
> > <mailto: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>
> > <mailto:sip%3A6502734101 at mydomain.com<sip%253A6502734101 at mydomain.com>
> >>;tag=7ad977f50f0f9d94
> > To: "Daniel Goepp" <sip:2021 at mydomain.com <sip%3A2021 at mydomain.com>
> > <mailto:sip%3A2021 at mydomain.com <sip%253A2021 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
> > <http://mydomain.com>", username="6502734101",
> > uri="sip:mydomain.com <http://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
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100428/2c6b1a91/attachment-0001.htm
More information about the Users
mailing list