[OpenSIPS-Users] ACK mangling redux - OpenSIPS 1.7

[Jock McKechnie]

You bet:

http://pastebin.com/Ge7FwvRa

The players are:
Alice, 192.168.0.50
Bob, 192.168.1.1
Charlie, 192.168.1.4
Bandwidth.com, 72.166.217.103

(The private IP addresses above are NOT the real addresses of the systems.
They all have public IPs. While anyone can get BW's IP, I'd rather not
publish mine - which I imagine everyone appreciates. Just an FYI if anyone
gets confused as to how the priv/pub IPs talk).

 - JP

On Fri, Sep 2, 2011 at 9:54 AM, Vlad Paiu <vladpaiu at opensips.org> wrote:

> **
> Hello Jock,
>
> Is it possible that you also provide us with a SIP trace with the full
> communication between all your servers, in case of the ACK issue ?
>
> Regards,
>
> Vlad Paiu
> OpenSIPS Developer
>
>
> On 09/02/2011 05:41 PM, Jock McKechnie wrote:
>
> Hidey ho;
>
> The week before last I posted a query about mediaproxy possibly mucking up
> an ACK when chaining several OpenSIPS together... and then decided I had
> fixed it. Unfortunately upon much closer review I've found that, you know,
> pretty much all of my original assumptions were wrong. What I'm seeing has
> nothing to do with mediaproxy, I'm not even sure if it's "wrong" per se, but
> I suspect so. Further some carriers get very shirty when you send them an
> odd ACK (Bandwidth.com), and others don't give a toss (Level3 and Qwest).
>
> This is the call chain I have:
> Alice the Asterisk box sends a call to the PSTN via:
> Bob the OpenSIPS 1.7 proxy ->
> Charlie the OpenSIPS 1.6.4 proxy ->
> The carrier's SBC.
>
> If I remove Charlie and have Bob send the call direct to the carrier SBC
> the issue is non-existant. The configs for both these OpenSIPS proxies are
> as simple as can be - the usual too-many-hops check and then a
> rewritehostport() to get the call to the next machine in the chain. No
> mediaproxy, no ACC, no dialog, no DB, nada.
>
> The call progresses normally through INVITE/100 Trying/183 Ringing/200 OK.
> When Alice returns the ACK to Bob, who passes the ACK to Charlie, Charlie
> loses part of the ACK header which Bandwidth.com is getting all excited
> about. Like this:
>
> Bob to Charlie (Charlie's IP is 192.168.1.4):
> ACK sip:+16415551212 at 192.168.1.4:5060;
>
> Charlie to the SBC:
> ACK sip:192.168.1.4;lr=on;ftag=as51e99695
>
>
> Bob's config: http://pastebin.com/FTVL2VUj
> Charlie's config: http://pastebin.com/6TdwQV4a
>
>
> Charlie is removing the phone number from the ACK URI and then not updating
> the IP in the URI to repoint it to the SBC. Because it is lacking the ph#,
> at least, and possibly in part because the IP isn't right, the carrier is
> ignoring the ACK, so we go into a loop of them resending 200 OKs and,
> eventually, dropping the call with the assumption we're no longer there.
>
> The fact that the other carriers don't care is... annoying, but I'm
> unlikely to change Bandwidth.com's mind about how they're handling these
> things. I agree with them, however, I suspect Charlie is not correctly
> forwarding the ACK - presumably because I'm not treating the conversation in
> the right manner.
>
> I would greatly appreciate any illumination anyone could provide;
>
> My thanks;
>
>  - Jock
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> 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/20110902/680993e1/attachment.htm>