Why not forward the registration from the endpoint and let them handle authentication?

16 sep 2013 kl. 19:11 skrev Steve Davies <steve(a)connection-telecom.com>om>: Why not forward the registration from the endpoint and let them handle authentication? I need to push the registration upstream. But I also need a local location record since I have an Asterisk on the side that also needs to send calls to the phones via the Kamailio instance. save before t_relay... Just forward the reg upstream. There's a parameter to save() to not respond.

I say you're making it too complex. Let the proxy be a proxy and force the client to behave properly.

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 Cheers, Daniel

Hi Daniel, Olle, On 16 September 2013 21:30, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; 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@local.domain.com"); append_hf("X-Runway-Trace: Runway saved registration as $tU(a)local.domain.com\r\n&quot;)uot;); } } 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@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@172.16.230.1:50108;rinstance=36d56481f191d185;transport=udp>;expires=0. To: "vc2 2686959"<sip:2686959@xxxx.connection-telecom.com>. From: "vc2 2686959"<sip:2686959@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@xxxx.connection-telecom.com>;tag=4bb452afea88ea368a51bf5f3eee867d.8da4. From: "vc2 2686959"<sip:2686959@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 _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On 17 September 2013 14:02, Olle E. Johansson &lt;oej(a)edvina.net&gt; wrote: Because the REGISTER has expires=0 on the contact, so this is a DEREGISTRATION, and that's why you do not see any contacts in the 200 OK. You need to check that you have contact headers before saving based on the 200 OK. Or possibly read the response code from save(). I do understand that its a deregistration. I want my Kamailio to remove the local registration, but it is not. The registrar module save() documentation says that "The function processes a REGISTER message. It can add, remove or modify usrloc records depending on Contact and Expires HFs in the REGISTER message.". So it seems it would do the right thing if it could see the actual REGISTER message. But since I'm in the in reply_route looks like it is working off the reply. In which case it can't "see" the Contact and especially not the ;expires=0. Is that right?

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:

- 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.