<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Hello,</p>
    <p>I haven't analyzed your message too much now -- just wanted to
      ask if you looked at uac module for uacreg feature and if that is
      suiting or not your needs?</p>
    <p>Cheers,<br>
      Daniel<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 05/05/16 14:40, Code Developer
      wrote:<br>
    </div>
    <blockquote cite="mid:DUB127-W67B1AD9EB6556DF94902EDEC7C0@phx.gbl"
      type="cite">
      <style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
      <div dir="ltr">
        <div>Hello,</div>
        <div><br>
        </div>
        <div>I'm after some help on third-party SIP registration in
          Kamailio - specifically, how to perform registration of user
          agents that don't register themselves, but only send out
          occasional messages. The UAs not registering themselves are
          devices on a GSM network that try to save band-width by not
          sending REGISTER requests for themselves. They only ever send
          out SIP messages when necessary, to which they expect a reply
          message from our processing server.</div>
        <div><br>
        </div>
        <div>(Note, details like external IP addresses have been changed
          for security.)</div>
        <div><br>
        </div>
        <div>The configuration is as follows. We have a SIP server
          running Kamailio (4.3, location db enabled, nathelper enabled)
          on a static external IP address (50.170.158.149), a processing
          server on an internal network registered with the SIP server
          (let's say with a User agent name of '1000'), and a monitoring
          device in another part of the country connected to the
          internet via a GSM network (let's say User agent name of
          '2000'). The device is effectively NAT'd on the GSM provider's
          private network.</div>
        <div><br>
        </div>
        <div>At some point the device (UA 2000) sends a SIP message to
          the processing server via Kamailio (to
          <a class="moz-txt-link-freetext" href="sip:1000@50.170.158.149">sip:1000@50.170.158.149</a>). The processing server is registered,
          so the SIP server knows where it is and forwards the
          message accordingly. 200/OK replies propagate back
          successfully to the device.</div>
        <div><br>
        </div>
        <div>The message flow appear as below. Only relevant header
          fields are shown:</div>
        <div><br>
        </div>
        <div>Message received by the SIP server from remote device:<br>
          ========<br>
          IP Src:60.250.149.198, Dst:50.170.158.149<br>
          UDP Src Port: 59177, Dst Port: 5060<br>
          --<br>
          Request-Line: MESSAGE <a class="moz-txt-link-freetext" href="sip:1000@50.170.158.149">sip:1000@50.170.158.149</a><br>
          Via: SIP/2.0/UDP 10.92.240.131:5060;branch=z9hG4bK...<br>
          To: <a class="moz-txt-link-rfc2396E" href="sip:1000@50.170.158.149"><sip:1000@50.170.158.149></a><br>
          From: <a class="moz-txt-link-rfc2396E" href="sip:2000@10.92.240.131"><sip:2000@10.92.240.131></a>;tag=7a82c48a<br>
          ========</div>
        <div><br>
        </div>
        <div><br>
          Message forwarded from SIP server, received by processing
          server as shown:<br>
          ========<br>
          IP Src:50.170.158.149, Dst: 192.168.0.235<br>
          UDP Src Port:5060, Dst Port:5060<br>
          --<br>
          Request-Line: MESSAGE <a class="moz-txt-link-freetext" href="sip:1000@50.170.158.146:5060">sip:1000@50.170.158.146:5060</a>; ob SIP/2.0<br>
          Via: SIP/2.0/UDP 50.170.158.149;branch=z9hG...<br>
          Via: SIP/2.0/UDP
          10.92.240.131:5060;rport=59177;received=60.250.149.198;branch=z9hG...<br>
          To: <a class="moz-txt-link-rfc2396E" href="sip:1000@50.170.158.149"><sip:1000@50.170.158.149></a><br>
          From: <a class="moz-txt-link-rfc2396E" href="sip:2000@10.92.240.131"><sip:2000@10.92.240.131></a>;tag=7a82c48a<br>
          ========</div>
        <div><br>
        </div>
        <div><br>
          The processing server now needs to send back a reply message
          to the remote, unregistered device which is NATd on the GSM
          internal network. We can do this by sending back a reply to
          the external IP address and rport values found in the second
          Via header of the message received by the processing server
          (60.250.149.198, port 59177). The reply can only be sent from
          the SIP server or the GSM network's router will ignore it -
          it's only a temporary reply address/port open for a minute or
          so as it's effectively just a NAT route to the internet.</div>
        <div><br>
        </div>
        <div>In the first instance, when the processing server attempts
          to send back a message to the remote device via the SIP
          server, the SIP server replies with a 404 as the remote device
          hasn't registered and the SIP server has no idea where to send
          it.</div>
        <div><br>
        </div>
        <div>After looking at RFC3261 my conclusion was that we must get
          the processing server to perform a third-party registration on
          behalf of the remote device before we can send a reply message
          back to that device.</div>
        <div><br>
        </div>
        <div>My understanding is that to perform the third party
          registration I should send a REGISTER request from our
          processing server to the SIP server:<br>
          1) Set the 'From' field to the AOR of the UA performing the
          registration (which is the processing server, 1000).<br>
          2) Set the 'To' field to the AOR of the UA being registered
          (i.e. the remote device, 2000).<br>
          3) Add a 'Contact' header field set to the IP address and port
          of the remote device (from Via = 60.250.149.198 port 59177).</div>
        <div><br>
        </div>
        <div><br>
          The message flow for the register is as follows (only relevant
          header fields shown):</div>
        <div><br>
        </div>
        <div>Processing server sends a register request to the SIP
          Server:<br>
          ========<br>
          Request-Line: REGISTER <a class="moz-txt-link-freetext" href="sip:50.170.158.149">sip:50.170.158.149</a> SIP/2.0<br>
          Via: SIP/2.0/UDP 192.168.0.235:5060;rport;branch=z9hG...<br>
          From: <a class="moz-txt-link-rfc2396E" href="sip:1000@50.170.158.149"><sip:1000@50.170.158.149></a>;tag=e6e2d70...<br>
          To: <a class="moz-txt-link-rfc2396E" href="sip:2000@50.170.158.149"><sip:2000@50.170.158.149></a><br>
          Contact: <a class="moz-txt-link-rfc2396E" href="sip:2000@60.250.149.198:59177"><sip:2000@60.250.149.198:59177></a><br>
          ========</div>
        <div><br>
        </div>
        <div>SIP server responds to the processing server with a 401
          unauthorized response containing the auth header field (nonce
          challenge):<br>
          ========<br>
          WWW-Authenticate: Digest realm="50.170.158.149",
          nonce="VytkJ1crIvu4ekGp/M4mnRlYmJRciF3N"<br>
          ========</div>
        <div><br>
        </div>
        <div>Processing server sends a revised register request to the
          SIP Server, augmented with the authorisation header for the
          supplied nonce:<br>
          ========<br>
          Request-Line: REGISTER <a class="moz-txt-link-freetext" href="sip:50.170.158.149">sip:50.170.158.149</a> SIP/2.0<br>
          Via: SIP/2.0/UDP 50.170.158.146:1096; rport;branch=z9hG4...<br>
          From: <a class="moz-txt-link-rfc2396E" href="sip:1000@50.170.158.149"><sip:1000@50.170.158.149></a>;tag=dae68a...<br>
          To: <a class="moz-txt-link-rfc2396E" href="sip:2000@50.170.158.149"><sip:2000@50.170.158.149></a><br>
          Contact: <a class="moz-txt-link-rfc2396E" href="sip:2000@60.250.149.198:59177"><sip:2000@60.250.149.198:59177></a><br>
          Authorization: Digest username="1000", realm="50.170.158.149",
          nonce="VytkJ1crIvu4ekGp/M4mnRlYmJRciF3N"
          response="d4d7ffba8..."<br>
          ========</div>
        <div><br>
        </div>
        <div>However, the SIP Server again responds with a 401 and won't
          perform the third-party registration. I haven't been able to
          determine why. I *think* the response hash the processing
          server is sending back is correct. I'm using PJSIP on our
          processing server to perform all SIP functionality. The
          processing server does obviously register
          itself, the difference being that the To and From fields are
          the same (<a class="moz-txt-link-rfc2396E" href="sip:1000@50.170.158.149"><sip:1000@50.170.158.149></a>) and there is no
          Contact  header.</div>
        <div><br>
        </div>
        <div>I'm at the point now of being unable to find any
          information or examples on how third-party registration
          requests should be performed - apart from RFC3261, which
          doesn't really describe the process very well.</div>
        <div><br>
        </div>
        <div>Can anyone tell me why the third-party registration would
          fail, despite replying with the authorisation header? Does
          Kamailio first need to be configured to allow third-party reg
          somehow? Alternatively, should I be attempting to send back
          SIP messages to unregistered devices in some other fashion?</div>
        <div><br>
        </div>
        <div>I hope someone can help or point me in the right direction.
        </div>
        <div><br>
        </div>
        <div>As an aside, when the device (UA2000) is plugged into a
          network via ethernet, it does then perform its own
          registration and everything works - messages go back and forth
          without issue.</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio World Conference, Berlin, May 18-20, 2016 - <a class="moz-txt-link-freetext" href="http://www.kamailioworld.com">http://www.kamailioworld.com</a></pre>
  </body>
</html>