<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I'm looking for suggestions on how to create a server-side workaround for an issue I'm getting in the field where the ALG logic in certain customer routers is putting bad data into the contact of a 200-OK message causing the resulting ACK back to the server to have the wrong rURI on it.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">Here is an example of the content in the bad-ACK:</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "> Request-Line: ACK</span><span class="Apple-style-span" style="font-family: monospace; "> </span><span class="Apple-style-span" style="font-family: monospace; "><a href="sip:5000@192.X.X.X:45219;transport=udp">sip:5000@192.X.X.X:45219;transport=udp</a></span><span class="Apple-style-span" style="font-family: monospace; "> </span><span class="Apple-style-span" style="font-family: monospace; ">SIP/2.0</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "> To: <</span><span class="Apple-style-span" style="font-family: monospace; "><a href="sip:5000@206.Y.Y.Y">sip:5000@206.Y.Y.Y</a></span><span class="Apple-style-span" style="font-family: monospace; ">>;tag=vtK3jeZ4yQmmF</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "> From: "805ZZZZZ" <</span><span class="Apple-style-span" style="font-family: monospace; "><a href="sip:805ZZZZZ@206.Y.Y.Y">sip:805ZZZZZ@206.Y.Y.Y</a></span><span class="Apple-style-span" style="font-family: monospace; ">></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "> Route: <</span><span class="Apple-style-span" style="font-family: monospace; "><a href="sip:206.Y.Y.Y;lr=on;did=c27.9ebcc7c7">sip:206.Y.Y.Y;lr=on;did=c27.9ebcc7c7</a></span><span class="Apple-style-span" style="font-family: monospace; ">></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "> Via: SIP/2.0/UDP 96.A.B.C:45219;branch=z9hG4bKiZKdxRM8VrEaYoN8;rport</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I've sanitized the addresses. 206.Y.Y.Y is the address of the openSIPS server. 192.X.X.X is the bogus NAT'd address which the ALG modified 200-OK caused to be placed in the ACK.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">With a standard-issue openSIPS config, the above ACK is given to loose_route() and then route(1), which decides it should be forwarded to the 192.X.X.X address - it's relayed to that (bogus) IP, and since the ACK never gets processed openSIPS keeps sending retries of the 200-OK, eventually giving up and tearing down the call.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I can easily detect this problem by seeing that the To: domain doesn't match the rURI.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I've tried setting modparam("tm", "ruri_matching", 0). That has no effect.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I've modified the config to examine all ACK's for the above issue, and set $rd = $td before calling loose_route() in hopes that this would convince the dialog to accept the ACK and advance to the established state. This seems like it should work, and I see the ACC module saying the 200 request was acknowledged. But then openSIPS continues sending out 200-OK retries and the call is eventually torn down.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">I'm looking for advice. I need a server side workaround for this - I can't do it in the client. What can I do in the openSIPS config to get the dialog to accept these mangled ACK's to the 200-OK and let the call move to established.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; ">Thanks in advance for any help.</span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "><br></span><span class="Apple-style-span" style="font-family: monospace; "> -Shawn Smith</span></body></html>