I found this post that is similar to the problem I'm having: <br><br><a href="http://www.openser.org/pipermail/users/2008-August/000176.html">http://www.openser.org/pipermail/users/2008-August/000176.html</a><br><br>Specifically this section:<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;"><pre>
>><i> But RFC 3581 says that:
</i>>><i> 4. Server Behavior
</i>>><i> The server behavior specified here affects the transport processing
</i>>><i> defined in Section 18.2 of SIP [1].
</i>>><i> When a server compliant to this specification (which can be a proxy
</i>>><i> or UAS) receives a request, it examines the topmost Via header field
</i>>><i> value. If this Via header field value contains an "rport" parameter
</i>>><i> with no value, it MUST set the value of the parameter to the source
</i>>><i> port of the request. This is analogous to the way in which a server
</i>>><i> will insert the "received" parameter into the topmost Via header
</i>>><i> field value. In fact, the server MUST insert a "received" parameter
</i>>><i> containing the source IP address that the request came from, even if
</i>>><i> it is identical to the value of the "sent-by" component. Note that
</i>>><i> this processing takes place independent of the transport protocol.
<br><br></i>The problem I'm experiencing is that on a Cisco 7960 IP phone, there is a nat setting that processes the value of the received parameter in the <br>via on a REGISTER response and notes that as valid for subsequent requests with the request URI's port DIFFERENT than that of the contact port. For example:<br>
</pre></span>U 2010/05/25 19:43:58.196780 <a href="http://24.30.9.224:16513">24.30.9.224:16513</a> -> <a href="http://69.61.97.113:5060">69.61.97.113:5060</a><br>REGISTER sip:1.2.3.4 SIP/2.0.<br>Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9hG4bK057bee3c.<br>
From: <<a href="mailto:sip%3Auser@1.2.3.4">sip:user@1.2.3.4</a>>;tag=001c58f1032e006c28023bfc-599bbfde.<br>To: <<a href="mailto:sip%3Auser@1.2.3.4">sip:user@1.2.3.4</a>>.<br>Call-ID: <a href="mailto:001c58f1-032e0004-19c5f689-5971526b@192.168.0.13">001c58f1-032e0004-19c5f689-5971526b@192.168.0.13</a>.<br>
Max-Forwards: 70.<br>Date: Tue, 25 May 2010 23:43:58 GMT.<br>CSeq: 119 REGISTER.<br>User-Agent: Cisco-CP7960G/8.0.<br>Contact: <sip:user@1.2.3.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001c58f1032e>";+u.sip!<a href="http://model.ccm.cisco.com">model.ccm.cisco.com</a>="7".<br>
Content-Length: 0.<br>Expires: 120.<br>.<br><br><br>U 2010/05/25 19:43:58.198578 <a href="http://69.61.97.113:5060">69.61.97.113:5060</a> -> <a href="http://24.30.9.224:16513">24.30.9.224:16513</a><br>SIP/2.0 200 OK.<br>
Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK057bee3c;rport=16513.<br>From: <<a href="mailto:sip%3Auser@1.2.3.4">sip:user@1.2.3.4</a>>;tag=001c58f1032e006c28023bfc-599bbfde.<br>To: <<a href="mailto:sip%3Auser@1.2.3.4">sip:user@1.2.3.4</a>>;tag=73928404c1df6c95e5850a715820bdcb.f5a7.<br>
Call-ID: <a href="mailto:001c58f1-032e0004-19c5f689-5971526b@192.168.0.13">001c58f1-032e0004-19c5f689-5971526b@192.168.0.13</a>.<br>CSeq: 119 REGISTER.<br>Contact: <sip:user@1.2.3.4:5060;transport=udp>;expires=45;received="sip:<a href="http://1.2.3.4:16513">1.2.3.4:16513</a>".<br>
Server: OpenSIPS (1.6.1-notls (x86_64/linux)).<br>Content-Length: 0.<br><br><br>I need that received to also be appended to the Via header. Is there a correct way, or a "quick and dirty" way of doing this?<br><br>
The problem is on an inbound INVITE, the 200 OK contact has the port 16513 (which should be correct, because we're dealing with NAT), and so the ACK RURI is formed with this port, but the Cisco UA throws the message out because the port in the RURI isn't "correct" for it.<br>
<br><br><br>Thanks for the help.<br><br>