<div>Vlad,</div><div><br></div><div>Yes, that's it exactly!  The softswitch in this case is changing the Contact header from the original value to the received ip:port.  The strict router behavior makes sense.</div><div>
<br></div><div>The "softswitch" in this case is Opensips 1.6.  Which functions have the ability to cause that change?  The "softswitch" Opensips configuration has been active for years and I've never noticed this behavior before.</div>
<div><br></div><div><br></div><div>- Jeff</div><div><br></div><div><br></div><br><div class="gmail_quote">On Tue, Jul 10, 2012 at 4:29 AM, Vlad Paiu <span dir="ltr"><<a href="mailto:vladpaiu@opensips.org" target="_blank">vladpaiu@opensips.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
  
    
    
  
  <div bgcolor="#ffffff" text="#000000">
    Hello Jeff,<br>
    <br>
    Your OpenSIPS probably routes that ACK as a strict router, since it
    sees that in the R-URI there's an IP where it's listening on (
    opensips_WAN_public ).<br>
    The contact in the 200OK had <a href="mailto:sip:9998887777@172.21.201.1:5066" target="_blank">sip:9998887777@172.21.201.1:5066</a> , so
    this should have been in the ACK's R-URI. Try to fix the softswitch.<br>
    <br>
    Regards,<br>
    <pre cols="72">Vlad Paiu
OpenSIPS Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a> </pre><div><div class="h5">
    <br>
    On 07/09/2012 09:28 PM, Jeff Pyle wrote:
    <blockquote type="cite">
      <div>Rudy,</div>
      <div><br>
      </div>
      <div>I don't have pcaps but I do have ngreps available here:</div>
      <div>  <a href="http://pastebin.com/EKMrhc7Z" target="_blank">http://pastebin.com/EKMrhc7Z</a></div>
      <div><br>
      </div>
      <div>You can see the ACK come in from the softswitch to Opensips's
        public interface starting at line 212.  I'd expect this to relay
        through to the private side, but instead, we see starting on
        line 228 it relays the ACK to itself on its private interface.
         I don't know why that is happening.</div>
      <div><br>
      </div>
      <div>The opensips.cfg is available here:</div>
      <div>  <a href="http://pastebin.com/UB9pPuUk" target="_blank">http://pastebin.com/UB9pPuUk</a></div>
      <div><br>
      </div>
      <div>I'm not sure what to do with it from here.</div>
      <div>
        <br>
      </div>
      <div><br>
      </div>
      <div>- Jeff</div>
      <br>
      <br>
      <br>
      <div class="gmail_quote">On Sun, Jul 8, 2012 at 11:44 AM, Rudy <span dir="ltr"><<a href="mailto:rudy@dynamicpacket.com" target="_blank">rudy@dynamicpacket.com</a>></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">
          Jeff,<br>
          <br>
          Can you post the pcap captures somewhere so I can take a look?<br>
          <br>
          Thanks in advance,<br>
          --Rudy<br>
          Dynamic Packet<br>
          Toll-Free: 888.929.VOIP ( 8647 )<br>
          <div>
            <div><br>
              <br>
              On Sun, Jul 8, 2012 at 8:21 AM, Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>>
              wrote:<br>
              > Hi Duane,<br>
              ><br>
              > I have captures now!  I also read through your
              thread.  The situation looks<br>
              > to be the same.  I also have a missing username in
              the self-relayed ACK's<br>
              > RURI.<br>
              ><br>
              > And it's also driving my crazy.<br>
              ><br>
              > I'm on 1.7 build 9142.  You?<br>
              ><br>
              ><br>
              ><br>
              > - Jeff<br>
              ><br>
              ><br>
              > On Sat, Jul 7, 2012 at 7:14 PM, <<a href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>>
              wrote:<br>
              >><br>
              >> Almost sounds like you and I are having the same
              issue.<br>
              >><br>
              >> Here's my issue<br>
              >><br>
              >> <a href="http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-td7580685.html" target="_blank">http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-td7580685.html</a><br>
              >><br>
              >> Do you have a SIP trace? I'm just wondering if we
              are having the same<br>
              >> problem. Does the ACK that gets relayed to ifself
              on the other IP have the<br>
              >> username missing in the RURI?<br>
              >><br>
              >><br>
              >><br>
              >><br>
              >> On , Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>>
              wrote:<br>
              >> > Hello,<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> > I'm attempting to write a config to perform
              near-end NAT traversal on<br>
              >> > Opensips 1.7.  I'm having a problem with the
              loose_route of the ACK after<br>
              >> > the 200 OK, and if I wait long enough, the
              BYE as well.<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> > Here's the scenario.  An INVITE comes in the
              WAN side and is t_relay'd<br>
              >> > to the LAN side.  The LAN-side UAS sends a
              200 OK, and that is relayed back<br>
              >> > to the WAN-side UAC.  So far, so good.  Then
              the WAN-side UAC sends the ACK<br>
              >> > to the 200.  Opensips relays this from its
              own WAN IP to its own LAN IP - I<br>
              >> > found it with ngrep on the lo interface.
               Eventually Opensips sends a 408<br>
              >> > back to the UAC.<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> > Here's the relevant portion of the config,
              based largely on the included<br>
              >> > sample.  This works fine with
              single-interface configurations:<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> >         if (has_totag()) {<br>
              >> >                 if (loose_route()) {<br>
              >> >                         if
              (method=="INVITE") record_route();<br>
              >> ><br>
              >> ><br>
              >> >                         if (!t_relay())
              sl_reply_error();<br>
              >> >                         exit;<br>
              >> >                 } else {<br>
              >> >                         if (method == "ACK")
              {<br>
              >> >                                 if
              (t_check_trans()) {<br>
              >> ><br>
              >> ><br>
              >> >                                         if
              (!t_relay())<br>
              >> > sl_reply_error();<br>
              >> >                                        
              exit;<br>
              >> >                                 } else {<br>
              >> >                                        
              exit;<br>
              >> ><br>
              >> ><br>
              >> >                                 }<br>
              >> >                         }<br>
              >> >                         sl_send_reply("404",
              "Not Here");<br>
              >> >                 }<br>
              >> >                 exit;<br>
              >> ><br>
              >> ><br>
              >> >         }<br>
              >> ><br>
              >> ><br>
              >> > I've verified with xlogs the ACK hits in the
              loose_route() portion of<br>
              >> > the config.  It does hit t_relay, but it
              relays the message to itself on its<br>
              >> > 'other' IP.  I've tried to look the extended
              debugs but I'm not finding<br>
              >> > anything telling.  Unfortunately I don't
              have any experience with multiple<br>
              >> > interface configurations.  I suspect it has
              something to do with the double<br>
              >> > Via lines added, one from each interface.
               Perhaps it's not detecting the<br>
              >> > second Via as its own?  (Even if that were
              the case, I can't explain why<br>
              >> > it's not responding to itself on the lo
              interface.)<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> > I do have mhomed=1 enabled.  Without it the
              initial invite doesn't<br>
              >> > arrive at the LAN-side UAS.<br>
              >> ><br>
              >> ><br>
              >> > I've experimented with check_via, aliases,
              etc.  No effect.  Any<br>
              >> > suggestions on where to go from here?<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> > - Jeff<br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >> ><br>
              >><br>
              >> _______________________________________________<br>
              >> Users mailing list<br>
              >> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
              >> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
              >><br>
              ><br>
              ><br>
              > _______________________________________________<br>
              > Users mailing list<br>
              > <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
              > <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
              ><br>
              <br>
              _______________________________________________<br>
              Users mailing list<br>
              <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
              <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
            </div>
          </div>
        </blockquote>
      </div>
      <br>
      <pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a 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></div></div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a 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>