Hi Shawn,
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() -
http://www.opensips.org/html/docs/modules/1.6.x/nathelper.html#id294025
, test "1") replace it with the layer 3 IP by using fix_nated_contact()
function
Regards,
Bogdan
On 03/16/2011 07:55 PM, Shawn Smith wrote:
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.
Here is an example of the content in the bad-ACK:
Request-Line: ACKsip:[email protected]:45219;transport=udpSIP/2.0
To: <sip:[email protected]>;tag=vtK3jeZ4yQmmF
From: "805ZZZZZ" <sip:[email protected]>
Route: <sip:206.Y.Y.Y;lr=on;did=c27.9ebcc7c7>
Via: SIP/2.0/UDP 96.A.B.C:45219;branch=z9hG4bKiZKdxRM8VrEaYoN8;rport
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.
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.
I can easily detect this problem by seeing that the To: domain doesn't
match the rURI.
I've tried setting modparam("tm", "ruri_matching", 0). That has no
effect.
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.
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.
Thanks in advance for any help.
-Shawn Smith
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
