<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hello Jock,<br>
    <br>
    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.<br>
    <br>
    I guess a good question is why are you calling <br>
    &nbsp;&nbsp;&nbsp; rewritehostport("192.168.1.4:5060"); <br>
    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.<br>
    <br>
    Regards,<br>
    <br>
    <pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer</pre>
    <br>
    On 09/02/2011 06:12 PM, Jock McKechnie wrote:
    <blockquote
cite="mid:CACZoz7QfXfKxRehM4fi3nN-8AgDN8Ep_9UX2p9bfT24aFn_-_A@mail.gmail.com"
      type="cite">You bet:<br>
      <br>
      <a moz-do-not-send="true" href="http://pastebin.com/Ge7FwvRa">http://pastebin.com/Ge7FwvRa</a><br>
      <br>
      The players are:<br>
      Alice, 192.168.0.50<br>
      Bob, 192.168.1.1<br>
      Charlie, 192.168.1.4<br>
      Bandwidth.com, 72.166.217.103<br>
      <br>
      (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).<br>
      <br>
      &nbsp;- JP<br>
      <br>
      <div class="gmail_quote">On Fri, Sep 2, 2011 at 9:54 AM, Vlad Paiu
        <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:vladpaiu@opensips.org">vladpaiu@opensips.org</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div 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 cols="72">Vlad Paiu
OpenSIPS Developer</pre>
            <div>
              <div class="h5"> <br>
                On 09/02/2011 05:41 PM, Jock McKechnie wrote: </div>
            </div>
            <blockquote type="cite">
              <div>
                <div class="h5">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 -&gt;<br>
                  Charlie the OpenSIPS 1.6.4 proxy -&gt;<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"
                    target="_blank">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" target="_blank">http://pastebin.com/FTVL2VUj</a><br>
                  Charlie's config: <a moz-do-not-send="true"
                    href="http://pastebin.com/6TdwQV4a" target="_blank">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>
                  &nbsp;- Jock<br>
                </div>
              </div>
              <pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a moz-do-not-send="true" href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a moz-do-not-send="true" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
            </blockquote>
          </div>
          <br>
          _______________________________________________<br>
          Users mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
          <a moz-do-not-send="true"
            href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
            target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
          <br>
        </blockquote>
      </div>
      <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>