[SR-Users] Third party registration help

[Code Developer]

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 at 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 at 50.170.158.149
Via: SIP/2.0/UDP 10.92.240.131:5060;branch=z9hG4bK...
To: <sip:1000 at 50.170.158.149>
From: <sip:2000 at 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 at 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 at 50.170.158.149>
From: <sip:2000 at 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 at 50.170.158.149>;tag=e6e2d70...
To: <sip:2000 at 50.170.158.149>
Contact: <sip:2000 at 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 at 50.170.158.149>;tag=dae68a...
To: <sip:2000 at 50.170.158.149>
Contact: <sip:2000 at 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 at 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. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20160505/8207b805/attachment.html>