Hi Daniel, Are you doing force_rtp_proxy for the UPDATE request?
Regards, Bogdan Daniel Goepp 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] > <mailto:sip%[email protected]>>;tag=7ad977f50f0f9d94 > To: "Daniel Goepp" <sip:[email protected] > <mailto: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] > <mailto:sip%[email protected]>>;tag=7ad977f50f0f9d94 > To: "Daniel Goepp" <sip:[email protected] > <mailto: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
