[OpenSIPS-Users] ACK mangling redux - OpenSIPS 1.7

[Jock McKechnie]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110902/9e8a9a3e/attachment.htm>