<!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">
    Hi Bobby,<br>
    <br>
    what you could do is to store into "fixed" contact the original IP
    and port, so that you can restore he original contact in sequential
    requests.<br>
    <br>
    like you received <a class="moz-txt-link-freetext" href="sip:foo@ip_1:port_1">sip:foo@ip_1:port_1</a> -&gt; fixing to
    <a class="moz-txt-link-freetext" href="sip:foo@ip_2:port_2;xip=ip_1;xport=ip_1">sip:foo@ip_2:port_2;xip=ip_1;xport=ip_1</a> <br>
    See:
    <a class="moz-txt-link-freetext" href="http://www.opensips.org/html/docs/modules/1.7.x/nathelper.html#id250346">http://www.opensips.org/html/docs/modules/1.7.x/nathelper.html#id250346</a>&nbsp;
    (take a look at params)<br>
    <br>
    and when you receive an RURI like
    <a class="moz-txt-link-freetext" href="sip:foo@ip_2:port_2;xip=ip_1;xport=ip_1">sip:foo@ip_2:port_2;xip=ip_1;xport=ip_1</a> you move current IP and port
    into DURI and upload xip and xport into URI.<br>
    <br>
    Regards,<br>
    Bogdan<br>
    <br>
    On 08/19/2011 07:28 AM, Bobby Smith wrote:
    <blockquote
cite="mid:CAJQeEguEpBrfTQdv8iHCXfJyG8o0F8UU2JMkxfTPHkO7YrGm7w@mail.gmail.com"
      type="cite">All,
      <div><br>
      </div>
      <div>Setup is this:<br>
        <br>
      </div>
      <div>Softswitch --&gt; OpenSIPS Proxy/Registrar --&gt; UAC</div>
      <div><br>
      </div>
      <div>INVITE <a class="moz-txt-link-freetext" href="sip:username@uac_ip:port">sip:username@uac_ip:port</a> is sent to uac via lookup on
        the location table:</div>
      <div><br>
      </div>
      <div>---&gt; INVITE <a moz-do-not-send="true"
          href="http://sip:user@foo.com:5063">sip:user@foo.com:5063</a>
        (but destination port from UA's contact is really 7063).</div>
      <div>R-R us</div>
      <div>Contact: &nbsp;<a class="moz-txt-link-rfc2396E" href="sip:did@softswitchip:port">&lt;sip:did@softswitchip:port&gt;</a></div>
      <div><br>
      </div>
      <div>&lt;-------- &nbsp;200 OK</div>
      <div>via them</div>
      <div>Contact: &lt;<a moz-do-not-send="true"
          href="http://sip:user@foo.com:5063">sip:user@foo.com:5063</a>&gt;,
        which is rewritten to <a moz-do-not-send="true"
          href="http://sip:user@foh.com:7063">sip:user@foh.com:7063</a>
        because of fix_nated_contact called</div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>-----------&gt; ACK <a moz-do-not-send="true"
          href="http://sip:user@bar.com:7063">sip:user@bar.com:7063</a>
        (sent to ua at 7063).</div>
      <div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; R-R us</div>
      <div><br>
      </div>
      <div>The problem is the UAC tosses out the request because it
        doesn't match it as the RURI port is wrong, even though it was
        sent to the right place.</div>
      <div><br>
        My question is:</div>
      <div><br>
      </div>
      <div>If I call loose route on this without fixing up the IP, it
        would be relayed to the private_ip:port pair of the UA.</div>
      <div>If I do another lookup, the RURI is preserved with the port
        7063 but sent to the right place (in this case 7063, but the
        request is thrown out).</div>
      <div><br>
      </div>
      <div>What I want to achieve is on the ACK:</div>
      <div><br>
      </div>
      <div>duri = <a moz-do-not-send="true"
          href="http://sip:user@bar.com:5073">sip:user@bar.com:5073</a></div>
      <div>ruri = <a moz-do-not-send="true"
          href="http://sip:user@foo.com:5063">sip:user@foo.com:5063</a></div>
      <div><br>
      </div>
      <div><br>
      </div>
      <div>The initial INVITE packet has the correct duri/ruri combo,
        but because I call fix_nated_contact, the softswitch rewrites
        the RURI (as it's supposed to) with the Contact Header info, and
        opensips relays this back to the UAC with that information.</div>
      <div><br>
      </div>
      <div>Is there a simple convention to set the duri to be the
        correct destination via lr or via doing another location lookup
        (hackish I guess, but even this doesn't work for me), while
        preserving the RURI on the initial invite? &nbsp;If i don't rewrite
        the contact header, the packet is relayed back to the private IP
        and seems to break NAT.</div>
      <div><br>
      </div>
      <div>If I do another user lookup, the ruri is rewritten. &nbsp;This is
        a phone that doesn't exactly support RFC 3261 (a Cisco 79XX with
        SIP 8.0 firmware), and doesn't support received processing.</div>
      <div>
        <br>
      </div>
      <div><br>
      </div>
      <div>Thanks,</div>
      <div>BobbyS</div>
      <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>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 19th of September 2011
OpenSIPS solutions and "know-how"</pre>
  </body>
</html>