All,<div><br></div><div>Setup is this:<br><br></div><div>Softswitch --> OpenSIPS Proxy/Registrar --> UAC</div><div><br></div><div>INVITE sip:username@uac_ip:port is sent to uac via lookup on the location table:</div>
<div><br></div><div>---> INVITE <a href="http://sip:user@foo.com:5063">sip:user@foo.com:5063</a> (but destination port from UA's contact is really 7063).</div><div>R-R us</div><div>Contact: <sip:did@softswitchip:port></div>
<div><br></div><div><-------- 200 OK</div><div>via them</div><div>Contact: <<a href="http://sip:user@foo.com:5063">sip:user@foo.com:5063</a>>, which is rewritten to <a href="http://sip:user@foh.com:7063">sip:user@foh.com:7063</a> because of fix_nated_contact called</div>
<div><br></div><div><br></div><div>-----------> ACK <a href="http://sip:user@bar.com:7063">sip:user@bar.com:7063</a> (sent to ua at 7063).</div><div> R-R us</div><div><br></div><div>The problem is the UAC tosses out the request because it doesn't match it as the RURI port is wrong, even though it was sent to the right place.</div>
<div><br>My question is:</div><div><br></div><div>If I call loose route on this without fixing up the IP, it would be relayed to the private_ip:port pair of the UA.</div><div>If I do another lookup, the RURI is preserved with the port 7063 but sent to the right place (in this case 7063, but the request is thrown out).</div>
<div><br></div><div>What I want to achieve is on the ACK:</div><div><br></div><div>duri = <a href="http://sip:user@bar.com:5073">sip:user@bar.com:5073</a></div><div>ruri = <a href="http://sip:user@foo.com:5063">sip:user@foo.com:5063</a></div>
<div><br></div><div><br></div><div>The initial INVITE packet has the correct duri/ruri combo, but because I call fix_nated_contact, the softswitch rewrites the RURI (as it's supposed to) with the Contact Header info, and opensips relays this back to the UAC with that information.</div>
<div><br></div><div>Is there a simple convention to set the duri to be the correct destination via lr or via doing another location lookup (hackish I guess, but even this doesn't work for me), while preserving the RURI on the initial invite? If i don't rewrite the contact header, the packet is relayed back to the private IP and seems to break NAT.</div>
<div><br></div><div>If I do another user lookup, the ruri is rewritten. This is a phone that doesn't exactly support RFC 3261 (a Cisco 79XX with SIP 8.0 firmware), and doesn't support received processing.</div><div>
<br></div><div><br></div><div>Thanks,</div><div>BobbyS</div>