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.<br>
<br>Thanks<br><br>-dg<br>
<br><br><div class="gmail_quote">On Tue, Apr 27, 2010 at 2:56 PM, Daniel Goepp <span dir="ltr"><<a href="mailto:dan@goepp.net">dan@goepp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">sip:6502734101@mydomain.com</a>>;tag=7ad977f50f0f9d94<br>
To: "Daniel Goepp" <<a href="mailto:sip%3A2021@mydomain.com" target="_blank">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" target="_blank">mydomain.com</a>", username="6502734101", uri="sip:<a href="http://mydomain.com" target="_blank">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" target="_blank">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" target="_blank">sip:6502734101@mydomain.com</a>>;tag=7ad977f50f0f9d94<br>
To: "Daniel Goepp" <<a href="mailto:sip%3A2021@mydomain.com" target="_blank">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" target="_blank">mydomain.com</a>", username="6502734101", uri="sip:<a href="http://mydomain.com" target="_blank">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><font color="#888888"><br>
-dg<br>
</font></blockquote></div><br>