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é <[email protected]>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:[email protected]: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:[email protected]: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 > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
