[SR-Users] Registering "upstream" with the uac module, but with authentication

[Steve Davies]

Hi Daniel, Olle,


On 16 September 2013 21:30, Daniel-Constantin Mierla <miconda at gmail.com>wrote:


> you can call save() for 200ok received from downstream. In case you deal
> with nat or multiple local sockets, you need to call the functions for
> fixing the registration as well as storing the local socket.
>
> The processing can be like:
> - forward register
> - if getting 200ok, call save() for it
> - if local timeout, call save in failure route -- you will have to call it
> via a sub-route, because save() is only allowed in request route and reply
> route, although failure_route should be safe for it
> - if other reply from downstram, let it go to the phone
>


I've made a start with this but need a little more help.

In route block [SIPOUT], in the case of a request going to a foreign domain
I added:

# we need to track the reply to the REGISTER since we need to also save
> locally
> if ( is_method("REGISTER") ) {
> t_on_reply("REGISTER_REPLY");
> t_on_failure("REGISTER_FAILURE");
> }


So this "captures" the reply or failure.

Then:

onreply_route[REGISTER_REPLY] {
> # Got a reply to a register from upstream.  Save locally if its an OK
> if (t_check_status("200")) {
> save("location", "0x02", "sip:$tU at local.domain.com");
> append_hf("X-Runway-Trace: Runway saved registration as $
> tU at local.domain.com\r\n");
> }
> }


The problem I have is that the save operates based on the content of the
200 OK reply.

So what goes into my DB for a register is like so:

           id: 31
         ruid: uloc-52383743-20e9-2
     username: 2686959
       domain: NULL
      contact: sip:2686959 at 172.16.230.1:36574
;rinstance=212220b8566c4337;transport=udp
     received: sip:10.64.5.16:5060
         path: NULL
      expires: 2013-09-17 14:32:24
            q: -1.00
       callid: MDA1MzRmZDQzZmMxNzhlNWUwMGUzNmYwNGYwZTM1YTc
         cseq: 2
last_modified: 2013-09-17 13:32:24
        flags: 0
       cflags: 0
   user_agent: n/a
       socket: udp:10.64.5.16:5060
      methods: NULL
     instance: NULL
       reg_id: 0

So this is OK, but the received and socket are both wrong (they are the
"outside" interface of my proxy, where the reply came in.  The registering
phone actually talks to Kamailio on the 172.16.230.128 interface).

More of a problem is what happens for an "unregister".

Here's the REGISTER as forwarded by Kamailio and the reply that comes back
and is processed in the onreply_route:

U 2013/09/17 13:22:58.004730 10.64.5.16:5060 -> x.x.x.60:5060
> REGISTER sip:vc2.connection-telecom.com SIP/2.0.
> Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bK66a6.f18d2a5.0.
> Via: SIP/2.0/UDP 172.16.230.1:50108
> ;branch=z9hG4bK-d8754z-f3d2c8070cecc90e-1---d8754z-;rport=50108.
> Max-Forwards: 16.
> Contact: <sip:2686959 at 172.16.230.1:50108
> ;rinstance=36d56481f191d185;transport=udp>;expires=0.
> To: "vc2 2686959"<sip:2686959 at xxxx.connection-telecom.com>.
> From: "vc2 2686959"<sip:2686959 at xxxx.connection-telecom.com>;tag=114bde0a.
> Call-ID: ZmUyY2JiOWQzMWE3OTM3YTNjNTM1OGUxOTE5Njc2ZTk.
> CSeq: 4 REGISTER.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO.
> User-Agent: Bria 3 release 3.5.4 stamp 70878.
> Authorization: Digest username="2686959",realm="
> xxxx.connection-telecom.com
> ",nonce="52383baf2e3b9efcb10180e2ad059ff0ae7fa675",uri="sip:
> vc2.connection-telecom.com
> ",response="bad296f5041c869c330f015c4dcb6351",algorithm=MD5.
> Content-Length: 0.
> P-hint: outbound.

.


U 2013/09/17 13:22:58.226378 x.x.x.60:5060 -> 10.64.5.16:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bK66a6.f18d2a5.0;rport=5060.
> Via: SIP/2.0/UDP 172.16.230.1:50108
> ;branch=z9hG4bK-d8754z-f3d2c8070cecc90e-1---d8754z-;rport=50108.
> To: "vc2 2686959"<sip:2686959 at xxxx.connection-telecom.com
> >;tag=4bb452afea88ea368a51bf5f3eee867d.8da4.
> From: "vc2 2686959"<sip:2686959 at xxxx.connection-telecom.com>;tag=114bde0a.
> Call-ID: ZmUyY2JiOWQzMWE3OTM3YTNjNTM1OGUxOTE5Njc2ZTk.
> CSeq: 4 REGISTER.
> Server: Telviva SIP proxy.
> Content-Length: 0.


So the 200 OK does not have the Contact header.

On the save Kamailio does not remove the existing registration from the
location table, so the unregister isn't effective for the local location
table.

Is there a way to get the save to find the original request?  Can I pull
the original request back via tm module somehow?  Other ideas on getting
this right?

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130917/9397924d/attachment.html>