[OpenSIPS-Users] OpenSIPS+MediaProxy mangling ACKs?

Jock McKechnie jock.mckechnie at gmail.com
Fri Aug 19 18:42:09 CEST 2011


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>


More information about the Users mailing list