[OpenSIPS-Users] ACK mangling redux - OpenSIPS 1.7

[Vlad Paiu]

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 
> <http://sip:+16415551212@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 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/d66b130a/attachment-0001.htm>