Third party registration help - sr-users

5 May 2016

Hello,
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.
(Note, details like external IP addresses have been changed for security.)
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.
At some point the device (UA 2000) sends a SIP message to the processing server via
Kamailio (to sip:1000@50.170.158.149). 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.
The message flow appear as below. Only relevant header fields are shown:
Message received by the SIP server from remote device:
========
IP Src:60.250.149.198, Dst:50.170.158.149
UDP Src Port: 59177, Dst Port: 5060
--
Request-Line: MESSAGE sip:1000@50.170.158.149
Via: SIP/2.0/UDP 10.92.240.131:5060;branch=z9hG4bK...
To: <sip:1000@50.170.158.149>
From: <sip:2000@10.92.240.131>;tag=7a82c48a
========

Message forwarded from SIP server, received by processing server as shown:
========
IP Src:50.170.158.149, Dst: 192.168.0.235
UDP Src Port:5060, Dst Port:5060
--
Request-Line: MESSAGE sip:1000@50.170.158.146:5060; ob SIP/2.0
Via: SIP/2.0/UDP 50.170.158.149;branch=z9hG...
Via: SIP/2.0/UDP 10.92.240.131:5060;rport=59177;received=60.250.149.198;branch=z9hG...
To: <sip:1000@50.170.158.149>
From: <sip:2000@10.92.240.131>;tag=7a82c48a
========

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.
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.
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.
My understanding is that to perform the third party registration I should send a REGISTER
request from our processing server to the SIP server:
1) Set the 'From' field to the AOR of the UA performing the registration (which is
the processing server, 1000).
2) Set the 'To' field to the AOR of the UA being registered (i.e. the remote
device, 2000).
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).

The message flow for the register is as follows (only relevant header fields shown):
Processing server sends a register request to the SIP Server:
========
Request-Line: REGISTER sip:50.170.158.149 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.235:5060;rport;branch=z9hG...
From: <sip:1000@50.170.158.149>;tag=e6e2d70...
To: <sip:2000@50.170.158.149>
Contact: <sip:2000@60.250.149.198:59177>
========
SIP server responds to the processing server with a 401 unauthorized response containing
the auth header field (nonce challenge):
========
WWW-Authenticate: Digest realm="50.170.158.149",
nonce="VytkJ1crIvu4ekGp/M4mnRlYmJRciF3N"
========
Processing server sends a revised register request to the SIP Server, augmented with the
authorisation header for the supplied nonce:
========
Request-Line: REGISTER sip:50.170.158.149 SIP/2.0
Via: SIP/2.0/UDP 50.170.158.146:1096; rport;branch=z9hG4...
From: <sip:1000@50.170.158.149>;tag=dae68a...
To: <sip:2000@50.170.158.149>
Contact: <sip:2000@60.250.149.198:59177>
Authorization: Digest username="1000", realm="50.170.158.149",
nonce="VytkJ1crIvu4ekGp/M4mnRlYmJRciF3N" response="d4d7ffba8..."
========
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
(<sip:1000@50.170.158.149>) and there is no Contact  header.
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.
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?
I hope someone can help or point me in the right direction. 
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. 		 	   		  