<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Jock,<br>
<br>
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 ?<br>
<br>
Regards,<br>
<br>
<pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer</pre>
<br>
On 09/02/2011 05:41 PM, Jock McKechnie wrote:
<blockquote
cite="mid:CACZoz7TN5LvwatjpFPABGp3ycaTpFD5f5keXprd15qahedt45A@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://pastebin.com/FTVL2VUj">http://pastebin.com/FTVL2VUj</a><br>
Charlie's config: <a moz-do-not-send="true"
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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>