<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Shawn,<br>
<br>
If you say that the problem is with the contact in 200 OK, maybe you
should address it there : when handling replies in onreply_route, if
the contact IP is private ( use nat_uac_test() -
<a class="moz-txt-link-freetext" href="http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id294025">http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id294025</a>
, test "1") replace it with the layer 3 IP by using
fix_nated_contact() function<br>
<br>
Regards,<br>
Bogdan<br>
<br>
On 03/16/2011 07:55 PM, Shawn Smith wrote:
<blockquote
cite="mid:7D546974-893D-4065-A5B5-6C8D4BE2C04A@pinger.com"
type="cite"><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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true" 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 moz-do-not-send="true"
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><br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"</pre>
</body>
</html>