<!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 text="#000000" bgcolor="#ffffff">
    Hi Kennard,<br>
    <br>
    Would you be so kind as to post what you did in regards to the reply
    handler? Also do you set the bflag if check_route_param succeeds and
    then let your reply handler check for a bflag?<br>
    <br>
    In regards to the private IP address, thats handled easily with the
    following:<br>
    <br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if(nat_uac_test("1"))<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fix_nated_contact();<br>
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
    <br>
    I also modded the code of nathelper.c to include a 64 check for
    nat_uac_test that checks the port number in the contact header
    against the source port of the packet (not sure if this breaks
    RFC's?), as I had an issue with a dumb ALG device stuffing up the
    port in the contact header on the 180 Ringing. It was suppose to be
    something like:<br>
    <br>
    <a class="moz-txt-link-freetext" href="sip:xxxx@1.2.3.4:17319">sip:xxxx@1.2.3.4:17319</a><br>
    <br>
    but instead, came through as:<br>
    <br>
    <a class="moz-txt-link-freetext" href="sip:xxxx@1.2.3.4:17319319">sip:xxxx@1.2.3.4:17319319</a><br>
    <br>
    which just broke everything else, so I added my check and if the
    contact header port and source port did not match, I simply called
    fix_nated_contact() to resolve it - this fixed the ALG issue, but
    still left the re-INVITE issue.<br>
    <br>
    I look forward to your assistance.<br>
    <br>
    Thanks<br>
    Doug<br>
    <br>
    <br>
    On 2010/10/12 8:02 PM, <a class="moz-txt-link-abbreviated" href="mailto:Kennard_White@logitech.com">Kennard_White@logitech.com</a> wrote:
    <blockquote
cite="mid:OF1C8B61E3.426CE30F-ON882577BA.00622A0F-882577BA.00630F70@logitech.com"
      type="cite">
      <p>Hi Doug,<br>
        <br>
        I had similar problem. My solution is to use record-route
        variable: add_rr_param("mr=1") on initial INVITE at same time as
        first call to use_media_relay(). The later within loose_route
        block, I use check_route_param("mr=1") for re-INVITES and then
        re-invoke media relay if found. In that case I also install a
        reply handler for the reinvite and set the bflag. The reinvite
        reply handler then checks the bflag and invokes use_media_proxy
        on the reply. That solves the media problem for me.<br>
        <br>
        How are you handling the private IP in the Contact address in
        B's 200 response to A's re-INVITE? This contact address will
        become the R-URI of all subsequent in-dialog messages from A
        (e.g., INFO, MESSAGE, BYE).<br>
        <br>
        Regards,<br>
        Kennard<br>
        <br>
        <img src="cid:part1.00090702.02090008@wd.co.za" alt="Inactive
          hide details for Doug ---10/12/2010 08:47:39 AM--- Hi All,
          I've got a problem I'm not 100% sure how to resolve."
          width="16" border="0" height="16"><font color="#424282">Doug
          ---10/12/2010 08:47:39 AM--- Hi All, I've got a problem I'm
          not 100% sure how to resolve.</font><br>
        <br>
        <font color="#5f5f5f" size="2">From: </font><font size="2">Doug
          <a class="moz-txt-link-rfc2396E" href="mailto:doug@wd.co.za">&lt;doug@wd.co.za&gt;</a></font><br>
        <font color="#5f5f5f" size="2">To: </font><font size="2">OpenSIPS
          users mailling list <a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org">&lt;users@lists.opensips.org&gt;</a></font><br>
        <font color="#5f5f5f" size="2">Date: </font><font size="2">10/12/2010
          08:47 AM</font><br>
        <font color="#5f5f5f" size="2">Subject: </font><font size="2">[OpenSIPS-Users]
          NAT and Re-INVITE</font><br>
        <font color="#5f5f5f" size="2">Sent by: </font><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:users-bounces@lists.opensips.org">users-bounces@lists.opensips.org</a></font><br>
      </p>
      <hr style="color: rgb(128, 145, 165);" width="100%" align="left"
        noshade="noshade" size="2"><br>
      <br>
      <br>
      <tt>&nbsp; Hi All,<br>
        <br>
        I've got a problem I'm not 100% sure how to resolve.<br>
        <br>
        Ok the scenario is, client A is on a public interface, Client B
        is on a <br>
        private IP address and has cflag 6 set in the location table.<br>
        <br>
        Client A calls Client B via Opensips.<br>
        <br>
        Now during the initial INVITE, opensips locates Client B, loads
        the <br>
        information, and naturally bflag is set to 6 (my NAT flag). This
        then <br>
        triggers mediaproxy to get involved, and the call is established
        <br>
        correctly, media passes from Client A ----&gt; Mediaproxy
        ----&gt; Client B.<br>
        <br>
        Now the problem is, the Client A device (Audiocodes ATA) sends a
        <br>
        Re-INVITE to switchover to T.38. The process works pretty much
        the same, <br>
        but follows the loose_route path due the call already being in a
        dialog <br>
        (i think thats the right terminology).<br>
        <br>
        Client B receives the Re-INVITE, however, because loose_route
        doesn't <br>
        know about the bflag (I've check with xlog and its not set
        during this <br>
        phase), mediaproxy is not engaged (as the INVITE is coming form
        Client A <br>
        who is not behind NAT). So when Client B responds, the SDP is a
        private <br>
        IP address, and the call falls apart.<br>
        <br>
        Now I suppose what I could do is call "use_media_proxy()" from
        the <br>
        onreply_route if the SDP is RFC1918 (nat_uac_test("8")),
        however, this <br>
        would engage mediaproxy for only one leg of the call and not the
        Client <br>
        A leg.<br>
        <br>
        The other option is I can force mediaproxy on all calls, which
        works, <br>
        but now I have to have RTP flowing through my links for devices
        that <br>
        could be speaking directly to each other.<br>
        <br>
        Has anyone had experience with this, or an idea of how to check
        during <br>
        the loose_route phase if the Client B sisde is behind nat, or
        set a flag <br>
        that remains consistent throughout the entire call flow (INVITE,
        200Ok, <br>
        Re-INVITE, 200OK, BYE).<br>
        <br>
        I look forward to your assistance.<br>
        <br>
        Many thanks<br>
        Doug<br>
        <br>
        <br>
        _______________________________________________<br>
        Users mailing list<br>
        <a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
      </tt><tt><a moz-do-not-send="true"
          href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></tt><tt><br>
      </tt><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>