[OpenSIPS-Users] Trouble accepting an ACK to 200-OK with a bad rUri
shawn at pinger.com
Wed Mar 16 18:55:35 CET 2011
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: ACK sip:5000 at 192.X.X.X:45219;transport=udp SIP/2.0
To: <sip:5000 at 206.Y.Y.Y>;tag=vtK3jeZ4yQmmF
From: "805ZZZZZ" <sip:805ZZZZZ at 206.Y.Y.Y>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users