Thanks, I will look into this. -dg
On Wed, Apr 28, 2010 at 2:51 AM, Bogdan-Andrei Iancu <[email protected] > 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 <[email protected] > > <mailto:[email protected]>> 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:[email protected]: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:[email protected]:5069 > > <http://sip:[email protected]:5069> > > Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: > > Found a response from a private address! - > > sip:[email protected]:5069 <http://sip:[email protected]: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: [email protected] > > <mailto:[email protected]> > > CSeq: 104 UPDATE > > Contact: <sip:[email protected]:5060;transport=tcp> > > From: <sip:[email protected] <sip%[email protected]> > > <mailto:sip%[email protected]<sip%[email protected]> > >>;tag=7ad977f50f0f9d94 > > To: "Daniel Goepp" <sip:[email protected] <sip%[email protected]> > > <mailto:sip%[email protected] <sip%[email protected]> > >>;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: [email protected] > > <mailto:[email protected]> > > CSeq: 104 UPDATE > > Contact: <sip:6502734101@<home_public_ip>:33774;transport=tcp> > > From: <sip:[email protected] <sip%[email protected]> > > <mailto:sip%[email protected]<sip%[email protected]> > >>;tag=7ad977f50f0f9d94 > > To: "Daniel Goepp" <sip:[email protected] <sip%[email protected]> > > <mailto:sip%[email protected] <sip%[email protected]> > >>;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 > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > -- > Bogdan-Andrei Iancu > www.voice-system.ro > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
