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

Daniel-Constantin Mierla miconda at gmail.com
Tue Sep 17 14:23:32 CEST 2013


Hello,

On 9/17/13 1:52 PM, Steve Davies wrote:
> Hi Daniel, Olle,
>
>
> On 16 September 2013 21:30, Daniel-Constantin Mierla 
> <miconda at gmail.com <mailto: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
>     <mailto:tU at local.domain.com>");
>     append_hf("X-Runway-Trace: Runway saved registration as
>     $tU at local.domain.com <mailto: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 <http://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 <http://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).

For the received field, you should call fix_nated_register() when you 
get the REGISTER (not for the reply). Or build the value for 
received_avp 
(http://kamailio.org/docs/modules/stable/modules/registrar.html#idp84696) manually 
in config from source ip, source port and transport.

With the socket is a bit more complex in this case, with multiple 
network interfaces, it can be set via a header, but msg_apply_changes() 
works on reply only with development version. Practically is about using 
the two parameters of registrar module:

- http://kamailio.org/docs/modules/stable/modules/registrar.html#idp115832

It might me easier to make a patch to provide custom socket value via an 
avp (like for received value), instead of header (this with header was 
added long time ago for replicated registrations).

Is the subscriber having more than one phone? Or is restricted to have 
only one device? IIRC, with some (old?) versions of asterisk, only one 
phone was used. If it is only for one phone, you can try a different 
approach:

- use save() with no reply flag for REGISTER
- forward the register downstream
- in failure route, if it is a reply received from downstream, use 
unregister()

There will be a short time window that the phone is registered locally. 
You can optimize it to call save() only when Authorization header is 
present in REGISTER, as you know downstream is always authenticating.

The development version (to be 4.1.0 in aprox. 2months) works better 
with this approach, allowing even multiple phones for same subscriber. 
That because save() returns an unique id (ruid) for the contact, that 
can be passed as 3rd parameter to unregister() to remove only that 
specific contact.

>
> 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
>     <http://10.64.5.16:5060> -> x.x.x.60:5060
>     REGISTER sip:vc2.connection-telecom.com
>     <http://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
>     <mailto:sip%3A2686959 at xxxx.connection-telecom.com>>.
>     From: "vc2 2686959"<sip:2686959 at xxxx.connection-telecom.com
>     <mailto:sip%3A2686959 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
>     <http://xxxx.connection-telecom.com>",nonce="52383baf2e3b9efcb10180e2ad059ff0ae7fa675",uri="sip:vc2.connection-telecom.com
>     <http://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
>     <http://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
>     <mailto:sip%3A2686959 at xxxx.connection-telecom.com>>;tag=4bb452afea88ea368a51bf5f3eee867d.8da4.
>     From: "vc2 2686959"<sip:2686959 at xxxx.connection-telecom.com
>     <mailto:sip%3A2686959 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?

You can call unregister() if the reply for REGISTER has no contacts.

Cheers,
Daniel

>
> Thanks,
> Steve
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
   - more details about Kamailio trainings at http://www.asipto.com -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130917/930cf23e/attachment-0001.html>


More information about the sr-users mailing list