[OpenSIPS-Users] UPDATE message and sdp
Daniel Goepp
dan at goepp.net
Wed Apr 28 18:21:54 CEST 2010
Thanks, I will look into this.
-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/b0a09626/attachment.htm
More information about the Users
mailing list