[OpenSIPS-Users] OpenSIPS+MediaProxy mangling ACKs?

[Saúl Ibarra Corretgé]

Hi,

On Aug 15, 2011, at 5:54 PM, Jock McKechnie wrote:

> Greetings all;
> 
> We've recently started rolling out MediaProxy devices at work and I've noticed when we're chaining several systems together in a call path that the MediaProxy/OpenSIPS box likes to change the ACK header in a manner which breaks the calls. When MediaProxy gets the ACK it will remove the host information from the URI of the final SBC in the chain and instead replace it with the IP of the proxy that immediately follows the MediaProxy/OpenSIPS box... which, of course, the next OpenSIPS box then sees itself on the ACK and removes the host information, producing a broken ACK that the far-end carrier throws up their hands at and ignores.
> 
> This is a little complicated, so bear with me, but the call flow looks like this (private IPs are for illustrative purposes only):
> Call source (currently an Asterisk machine) - 192.168.0.1 ->
> OpenSIPS/MediaProxy system (v.1.7.0 and latest darcs MediaProxy source) - 192.168.1.1 ->
> Local OpenSER proxy (v.1.3.2) - 192.168.2.2 ->
> Carrier proxy (Unknown type) - 10.5.5.5 ->
> Carrier SBC (Sonus) - 10.10.10.10
> 
> As I understand it, the ACK is supposed to be formatted like so:
> ACK sip:+16415551212 at 10.10.10.10:5060;transport=udp SIP/2.0
> 
> Where the ACK has the IP address of the carrier's SBC that's at the very end of the call chain in its URI. Instead the MediaProxy/OpenSIPS box produces an ACK like so:
> ACK sip:+16415551212 at 192.168.2.2:5060;transport=udp SIP/2.0
> 
> Which is the IP of the final proxy in our company that hands the calls off to the carrier. The proxy then strips its own IP out of the ACK and sends this to the carrier:
> ACK sip:10.5.5.5;lr;ftag=as6e98d5f7
> 
> Without a user in the SIP URI and the wrong IP in the ACK, the carrier completely ignores this response and continues to send '200 OK's which we don't respond to, so eventually the carrier terminates the call as it naturally assumes we went missing.
> 
> I could sure use some suggestions. The OpenSER box is using a very simple "accept and forward" stateless configuration and its only job is to aggregate calls from several boxes behind it and send it on to a single carrier address (10.5.5.5). The OpenSIPS config includes MediaProxy and also a local dispatcher file to fail-over calls between local proxies. The MediaProxy config has tested good when used directly between Asterisk and the carrier proxy. If I connect Asterisk directly to the local proxy, the call works fine as there's no funny business going on with the ACKs w/o the OpenSIPS/MediaProxy box in between to rewrite the ACK.
> 

MediaProxy only mangles the SDP, it never touches the RURI, so you can discard it as the culprit :-)

There are many hops in the scenario you described, so the best would be to look at SIP traces and see which one of the hops is mangling the data in a bogus way and why.

> The MediaProxy config can be found on PasteBin (for some goofy reason pasting directly into gmail under Opera removes all line-feeds. Haaaaandy.)
> http://pastebin.com/XruQ2rPk
> 

I get a "Unknown paste ID" :-S


Regards,

--
Saúl Ibarra Corretgé
AG Projects