[OpenSIPS-Users] OpenSIPS+MediaProxy mangling ACKs?

[Jock McKechnie]

My deepest apologies. After I'd stuffed it into PasteBin an hour or so later
(honestly) it told me it was suspicious of the content and wanted
verification, which when I did, it told me the paste had been nuked already.
Helpful.

The CORRECT PasteBin URI (and working as of _now_ ;) is:
http://pastebin.com/b2FGgTRX

Thanks!

 - Jock

On Tue, Aug 16, 2011 at 2:13 AM, Saúl Ibarra Corretgé
<saul at ag-projects.com>wrote:

> 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
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110819/f6896142/attachment.htm>