[OpenSIPS-Users] ACK mangling redux - OpenSIPS 1.7

[Vlad Paiu]

Hello Jock,

I have taken a look at the SIP trace and seems that the proxy behind 
Charlie, 192.168.1.1, does some weird stuff to the ACK. More 
specifically, it mangles the domain part of the RURI, so that it points 
to 192.168.1.4. When Charlie ( 192.168.1.4 ) receives this ACK it sees 
itself in the domain part of the RURI, so it applies strict routing, by 
taking the last route header and putting it in the RURI. This is why you 
see the apparent stripping of the username part when forwarding the ACK.

I guess a good question is why are you calling
     rewritehostport("192.168.1.4:5060");
on the proxy behind Charlie ? Because this is the source of your 
problem. I mean why not let the ACK get routed like every other 
sequential request, via the Route header.

Regards,

Vlad Paiu
OpenSIPS Developer


On 09/02/2011 06:12 PM, Jock McKechnie wrote:
> 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 
> <mailto: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
>>     <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  <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://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/20110905/aefe0927/attachment.htm>