<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><tt>Hi Julian,</tt></p>
    <p><tt>This asymmetry of the OPTIONS R-URI + To header field when
        pinging either normal contacts (includes "username@" part) or
        NAT'ed  contacts (skips the "username@" part) actually looks
        like a bug -- I will look into a fix in the background.</tt></p>
    <p><tt>For the time being, you should be able to circumvent the bug
        using the following technique:</tt></p>
    <p><tt><u>edge script</u><br>
      </tt></p>
    <p><tt>no need to change anything here, using add_path_received() is
        correct.</tt></p>
    <p><tt><u>core script</u></tt></p>
    <p><tt>* define the "received_avp" modparam for both registrar and
        nathelper -- they must be set to the same AVP, say "$avp(rcv)"<br>
        * using the script transformations [1] and/or other magic,
        extract the value of the ";received=" Path header parameter into
        two convenient variables: $var(rcv_host) and $var(rcv_port).<br>
        * prepare the exact content of the future R-URI / To header
        pings for this contact by populating $avp(rcv):</tt></p>
    <p><tt>    $avp(rcv) = "sip:" + $(ct.fields(uri){uri.user}) + "@" +
        $var(rcv_host) + ":" + $var(rcv_port);</tt></p>
    <p><tt>* save("p1"); # notice we skip the "v" (Path ";received="
        param) logic, as the received URI is already set</tt></p>
    <p><tt>Best regards,</tt></p>
    <p><tt>[1]: <a class="moz-txt-link-freetext" href="https://www.opensips.org/Documentation/Script-Tran-2-2">https://www.opensips.org/Documentation/Script-Tran-2-2</a><br>
      </tt></p>
    <pre class="moz-signature" cols="72">Liviu Chircu
OpenSIPS Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a></pre>
    <div class="moz-cite-prefix">On 20.11.2018 17:01, Julian Santer
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:b85b1110-aadd-e3f6-0afa-fc1fdb0ee4b5@rolmail.net">Hi
      guys,
      <br>
      <br>
      as I see in the tcpdump:
      <br>
      <br>
      - with the received header the R-RURI in the INVITE looks like:
      <br>
      <br>
      Request-Line: INVITE
      <a class="moz-txt-link-abbreviated" href="mailto:sip:dev-lab1@192.168.44.101:40885;line=fjafxbr9">sip:dev-lab1@192.168.44.101:40885;line=fjafxbr9</a> SIP/2.0
      <br>
      <br>
      <br>
      - without the received header the R-URI in the INVITE looks like:
      <br>
      <br>
      Request-Line: INVITE
      <a class="moz-txt-link-abbreviated" href="mailto:sip:dev-lab1@212.46.162.97:40885;line=7wsv12yg">sip:dev-lab1@212.46.162.97:40885;line=7wsv12yg</a> SIP/2.0
      <br>
      <br>
      <br>
      Could the INVITE been rejeced/dropped by the UAC, if the R-RURI
      contains the public instead the private IP or another port etc.?
      <br>
      <br>
      From UAC perspective, the R-RURI (puclic IP) by incoming packets
      doesn't match the R-RURI (private IP) by outgoing packets.
      <br>
      <br>
      <br>
      Kind regards,
      <br>
      <br>
      Julian Santer
      <br>
      <br>
      Am 20.11.18 um 15:51 schrieb Julian Santer:
      <br>
      <blockquote type="cite">Hi guys,
        <br>
        <br>
        if I don't use the received column on the edge server, but I
        call fix_nated_contact instead, it seems to work.
        <br>
        <br>
        if (nat_uac_test("127"))
        <br>
        {
        <br>
            fix_nated_contact();
        <br>
        }
        <br>
        <br>
        consume_credentials();
        <br>
        <br>
        if (! add_path())
        <br>
        {
        <br>
            send_reply("500", "Internal path error, registration not
        stored");
        <br>
            xlog("L_ERR", "Adding PATH (with received) failed -
        LF_BASE");
        <br>
            exit;
        <br>
        }
        <br>
        <br>
        Is this the right way or could I break something else with this
        change?
        <br>
        <br>
        <br>
        Kind regards,
        <br>
        <br>
        Julian Santer
        <br>
        <br>
        Am 19.11.18 um 18:41 schrieb Julian Santer:
        <br>
        <blockquote type="cite">Hi guys,
          <br>
          <br>
          we need to switch from nat_traversal to nathelper.
          <br>
          The reason is the keepalive mechanism.
          <br>
          <br>
          The nat_traversal module sends OPTIONS with the following to
          header: sip:UAC_IP:UAC_PORT
          <br>
          Most of the UAC's answers with a 404 Not found.
          <br>
          On AVM Fritzbox with firmware >= 6.04, this OPTIONS may
          activate a security feature.
          <br>
          So after a certain time, the Fritzbox blocks all packages send
          from our proxy.
          <br>
          As we have ca. 80% AVM Fritzbox as UAC, we got a big problem.
          <br>
          So we deactivated the nat_keepalive vor this UAC's and we have
          to enable the keepalive Feature on the Fritzbox.
          <br>
          <br>
          The better solution would be, if we could send OPTIONS with a
          to header like: sip:username@UAC_IP:UAC_PORT.
          <br>
          As I understood the nathelper module could send OPTIONS like
          this. Because it is looking into the userloc table. Right?
          <br>
          <br>
          The nathelper module is on our edge server, the registrar on
          our core server.
          <br>
          For the "normal" UAC's (no received entry in usrloc) the
          keepalive's are now sent as expected.
          <br>
          But for the "nated" UAC's (received entry in usrloc) the
          keepalive's are like before: sip:UAC_IP:UAC_PORT (values in
          the received column from usrloc).
          <br>
          The REGISTER send to the core got the path header looking
          like:
          <br>
          Path: <sip:IP_EDGE;lr;received=sip:IP_UAC:40885>
          <br>
          <br>
          Is there a possibility to add the $fU on the received part of
          the path header (the user in the path module adds a string to
          the path part, but not to the received part)?
          <br>
          Or is there a possiblity on the registrar to store the $fU in
          the received column?
          <br>
          On the nathelper keepalive mechanism I don't see any
          possibility to add the $fU.
          <br>
          <br>
          We are using the version 2.2.6 from the official debian source
          list.
          <br>
          <br>
          The config on the edge server's looks like:
          <br>
          #### nat helper module
          <br>
          loadmodule "nathelper.so"
          <br>
          modparam("nathelper", "natping_interval", 0)
          <br>
          modparam("nathelper", "ping_nated_only", 0)
          <br>
          modparam("nathelper", "natping_partitions", 1)
          <br>
          modparam("nathelper", "natping_tcp", 0)
          <br>
          <br>
          ### REGISTER
          <br>
          <br>
          $var(nat) = null;
          <br>
          <br>
          if (nat_uac_test("127"))
          <br>
          {
          <br>
              $var(nat) = TRUE;
          <br>
          }
          <br>
          else
          <br>
          {
          <br>
              $var(nat) = FALSE;
          <br>
          }
          <br>
          <br>
          consume_credentials();
          <br>
          <br>
          if ($var(nat) == TRUE)
          <br>
          {
          <br>
              if (! add_path_received())
          <br>
              {
          <br>
                  xlog("L_ERR", "Adding PATH (with received) failed -
          LF_BASE");
          <br>
                  send_reply("500", "Internal path error, registration
          not stored");
          <br>
                  exit;
          <br>
              }
          <br>
          }
          <br>
          else
          <br>
          {
          <br>
              if (! add_path())
          <br>
              {
          <br>
                  send_reply("500", "Internal path error, registration
          not stored");
          <br>
                  xlog("L_ERR", "Adding PATH (with received) failed -
          LF_BASE");
          <br>
                  exit;
          <br>
              }
          <br>
          }
          <br>
          <br>
          route("R_RELAY_TO_REGISTRAR");
          <br>
          exit;
          <br>
          <br>
          ### OPTIONS
          <br>
          <br>
          if (method=="OPTIONS")
          <br>
          {
          <br>
              if ($si == "CORE")
          <br>
              {
          <br>
                  topology_hiding("U");
          <br>
                  if (! t_relay("0x05"))
          <br>
                  {
          <br>
                      send_reply("500", "Internal server error - failed
          to relay");
          <br>
                      xlog("L_ERR", "Unable to relay OPTIONS -
          LF_BASE");
          <br>
                  }
          <br>
              }
          <br>
          }
          <br>
          <br>
          <br>
          The config on the core server looks like:
          <br>
          loadmodule "usrloc.so"
          <br>
          modparam("usrloc", "user_column",           "username")
          <br>
          modparam("usrloc", "domain_column",         "domain")
          <br>
          modparam("usrloc", "contact_column",        "contact")
          <br>
          modparam("usrloc", "expires_column",        "expires")
          <br>
          modparam("usrloc", "q_column",              "q")
          <br>
          modparam("usrloc", "callid_column",         "callid")
          <br>
          modparam("usrloc", "cseq_column",           "cseq")
          <br>
          modparam("usrloc", "methods_column",        "methods")
          <br>
          modparam("usrloc", "flags_column",          "flags")
          <br>
          modparam("usrloc", "user_agent_column",     "user_agent")
          <br>
          modparam("usrloc", "received_column",       "received")
          <br>
          modparam("usrloc", "path_column",           "path")
          <br>
          modparam("usrloc", "socket_column",         "socket")
          <br>
          modparam("usrloc", "use_domain",            0)
          <br>
          modparam("usrloc", "desc_time_order",       0)
          <br>
          modparam("usrloc", "timer_interval",        60)
          <br>
          modparam("usrloc", "db_url",                "DBURL")
          <br>
          modparam("usrloc", "db_mode",               2)
          <br>
          modparam("usrloc", "matching_mode",         0)
          <br>
          modparam("usrloc", "cseq_delay",            20)
          <br>
          modparam("usrloc", "nat_bflag",             6)
          <br>
          <br>
          #### nat helper module
          <br>
          loadmodule "nathelper.so"
          <br>
          modparam("nathelper", "natping_interval", 56)
          <br>
          modparam("nathelper", "ping_nated_only", 0)
          <br>
          modparam("nathelper", "natping_partitions", 1)
          <br>
          modparam("nathelper", "sipping_bflag", 8)
          <br>
          modparam("nathelper", "sipping_from",
          "sip:keepalive@DEFAULT_REALM")
          <br>
          modparam("nathelper", "sipping_method", "OPTIONS")
          <br>
          <br>
          # We want to send a keepalive on each registered UAC
          <br>
          if (proto == UDP)
          <br>
          {
          <br>
              setbflag(8);
          <br>
              xlog("L_INFO", "Nat keepalive sip_ping_flag - LF_BASE");
          <br>
          }
          <br>
          <br>
          if (! save("location", "vp1"))
          <br>
          {
          <br>
              xlog("L_ERR", "Saving contact from EDGE failed -
          LF_BASE");
          <br>
              exit;
          <br>
          }
          <br>
          <br>
          Thank you for any hint.
          <br>
          <br>
          Kind regards,
          <br>
          Julian Santer
          <br>
          Raiffeisen OnLine
          <br>
          <br>
          ps: @Bogdan: this is why we have ca. 550 entry's in the
          address table (permission module). If we solve the keepalives,
          only ca. 50 entry's are remaining.
          <br>
        </blockquote>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      Users mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
      <br>
      <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>
      <br>
    </blockquote>
  </body>
</html>