Hidey ho;<br><br>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).<br>
<br>This is the call chain I have:<br>Alice the Asterisk box sends a call to the PSTN via:<br>Bob the OpenSIPS 1.7 proxy -><br>Charlie the OpenSIPS 1.6.4 proxy -><br>The carrier's SBC.<br><br>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.<br>
<br>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:<br>
<br>Bob to Charlie (Charlie's IP is 192.168.1.4):<br>ACK <a href="http://sip:+16415551212@192.168.1.4:5060">sip:+16415551212@192.168.1.4:5060</a>;<br><br>Charlie to the SBC:<br>ACK sip:192.168.1.4;lr=on;ftag=as51e99695<br>
<br><br>Bob's config: <a href="http://pastebin.com/FTVL2VUj">http://pastebin.com/FTVL2VUj</a><br>Charlie's config: <a href="http://pastebin.com/6TdwQV4a">http://pastebin.com/6TdwQV4a</a><br><br><br>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.<br>
<br>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.<br>
<br>I would greatly appreciate any illumination anyone could provide;<br><br>My thanks;<br><br> - Jock<br>