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.<br><br>I have added some logging and for the following call, I get:<br>
<br>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@192.168.1.110:5060;transport=tcp<br>Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Route 1<br>
Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Setting rtpproxy_offer - Route 1<br>Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Fixing Contact - Route 1<br>Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21903]: Relay message<br>
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<br>Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: incoming reply route 1 - <null> - <a href="http://sip:2021@192.168.1.101:5069">sip:2021@192.168.1.101:5069</a><br>
Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: Found a response from a private address! - <a href="http://sip:2021@192.168.1.101:5069">sip:2021@192.168.1.101:5069</a><br>Apr 27 14:45:49 ip-10-250-14-133 /usr/local/sbin/opensips[21896]: Setting rtpproxy_answer - Reply 1<br>
Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command: lookup on ports 30882/29328, session timer restarted<br>Apr 27 14:45:49 ip-10-250-14-133 rtpproxy[20092]: INFO:handle_command: lookup on ports 31198/28836, session timer restarted<br>
<br>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?<br>
<br>Thanks<br><br>-dg<br><br>========================<br>2010-04-27 14:45:49<br>tcp:<home_public_ip>:33774 -> tcp:<opensips_ip>:5060<br><br>UPDATE sip:2021@<home_public_ip>:5069 SIP/2.0<br>Via: SIP/2.0/TCP 192.168.1.110:5060;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport<br>
Call-ID: <a href="mailto:4fdbf3351f21733c@192.168.1.110">4fdbf3351f21733c@192.168.1.110</a><br>CSeq: 104 UPDATE<br>Contact: <sip:6502734101@192.168.1.110:5060;transport=tcp><br>From: <<a href="mailto:sip%3A6502734101@mydomain.com">sip:6502734101@mydomain.com</a>>;tag=7ad977f50f0f9d94<br>
To: "Daniel Goepp" <<a href="mailto:sip%3A2021@mydomain.com">sip:2021@mydomain.com</a>>;tag=DC151CA5-80A23EC4<br>Max-Forwards: 70<br>Route: <sip:<opensips_ip>;lr;transport=tcp;transport=tcp><br>
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY<br>User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)<br>Proxy-Authorization: Digest nonce="*****", realm="<a href="http://mydomain.com">mydomain.com</a>", username="6502734101", uri="sip:<a href="http://mydomain.com">mydomain.com</a>", response="*******", algorithm=MD5<br>
Supported: replaces,100rel,timer,gruu,path,outbound<br>Session-Expires: 500;refresher=uac<br>Min-SE: 90<br>Content-Type: application/sdp<br>Content-Length: 455<br><br>v=0<br>o=tandberg 17 2 IN IP4 192.168.1.110<br>s=-<br>
c=IN IP4 192.168.1.110<br>b=CT:768<br>t=0 0<br>m=audio 2354 RTP/AVP 100 102<br>c=IN IP4 192.168.1.110<br>b=TIAS:64000<br>a=rtpmap:100 G7221/16000<br>a=fmtp:100 bitrate=32000<br>a=rtpmap:102 telephone-event/8000<br>a=fmtp:102 0-15<br>
a=sendrecv<br>m=video 2356 RTP/AVP 97<br>b=TIAS:768000<br>a=rtpmap:97 H264/90000<br>a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500<br>a=sendrecv<br>a=content:main<br>a=label:11<br><br>========================<br>
2010-04-27 14:45:49<br>udp:<opensips_ip>:5060 -> udp:<home_public_ip>:5069<br><br>UPDATE sip:2021@<home_public_ip>:5069 SIP/2.0<br>Record-Route: <sip:<opensips_ip>;lr;transport=tcp><br>Via: SIP/2.0/UDP <opensips_ip>;branch=z9hG4bK7e7f.ef3c6013.0;i=9<br>
Via: SIP/2.0/TCP 192.168.1.110:5060;received=<home_public_ip>;branch=z9hG4bKc5744895b5e0bbaaff08043324b99dc5.1;rport=33774<br>Call-ID: <a href="mailto:4fdbf3351f21733c@192.168.1.110">4fdbf3351f21733c@192.168.1.110</a><br>
CSeq: 104 UPDATE<br>Contact: <sip:6502734101@<home_public_ip>:33774;transport=tcp><br>From: <<a href="mailto:sip%3A6502734101@mydomain.com">sip:6502734101@mydomain.com</a>>;tag=7ad977f50f0f9d94<br>To: "Daniel Goepp" <<a href="mailto:sip%3A2021@mydomain.com">sip:2021@mydomain.com</a>>;tag=DC151CA5-80A23EC4<br>
Max-Forwards: 69<br>Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY<br>User-Agent: TANDBERG/257 (TE2.2.0.213935Beta5)<br>Proxy-Authorization: Digest nonce="*****", realm="<a href="http://mydomain.com">mydomain.com</a>", username="6502734101", uri="sip:<a href="http://mydomain.com">mydomain.com</a>", response="****", algorithm=MD5<br>
Supported: replaces,100rel,timer,gruu,path,outbound<br>Session-Expires: 500;refresher=uac<br>Min-SE: 90<br>Content-Type: application/sdp<br>Content-Length: 455<br><br>v=0<br>o=tandberg 17 2 IN IP4 192.168.1.110<br>s=-<br>
c=IN IP4 192.168.1.110<br>b=CT:768<br>t=0 0<br>m=audio 2354 RTP/AVP 100 102<br>c=IN IP4 192.168.1.110<br>b=TIAS:64000<br>a=rtpmap:100 G7221/16000<br>a=fmtp:100 bitrate=32000<br>a=rtpmap:102 telephone-event/8000<br>a=fmtp:102 0-15<br>
a=sendrecv<br>m=video 2356 RTP/AVP 97<br>b=TIAS:768000<br>a=rtpmap:97 H264/90000<br>a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500<br>a=sendrecv<br>a=content:main<br>a=label:11<br><br>-dg<br>