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

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


On 9/17/13 2:43 PM, Steve Davies wrote:
>
>
> On 17 September 2013 14:23, Daniel-Constantin Mierla 
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     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.
>
>
>
> I already have and call this route block:  (WITH_NAT is defined)
>
> # Caller NAT detection route
> route[NATDETECT] {
> #!ifdef WITH_NAT
> force_rport();
> if (nat_uac_test("19")) {
> if (is_method("REGISTER")) {
> fix_nated_register();
> } else {
> add_contact_alias();
> }
> setflag(FLT_NATS);
> }
> #!ifdef WITH_RTPBRIDGING
> if (!is_method("BYE")) {
> setflag(FLT_NATS);
> }
> #!endif
> #!endif
> return;
> }
>
>
> But there is no NAT between the phone and Kamailio, so 
> fix_nated_register isn't called.  And there is nothing to fix about 
> the incoming register.

Just call the function, don't make it optional for natted traffic only.

>
> But the register goes out on a different interface with a different 
> address.  And the reply comes back on that interface.
>
> So I presume the issue with the received/socket is that save() derived 
> them off the reply.
>
>
>     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:
>
>
> The subscriber is not restricted to only having one phone - they can 
> register more than one.  The downstream service supports that fine. 
>  Kamailio can support it and I don't want to introduce a restriction 
> since customers often have a desk phone and also want to use a soft 
> client on mobile phone or similar.
>
>     - 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.
>
>
> So apart from dealing with the multiple registrations this seems like 
> a promising approach.
>
> Another idea: can I do "append_branch" for a register?  If so, can I 
> turn a register to the downstream service into a register for both the 
> downstream service and my local registrar?
append_branch() works, but I don't think helps here, it will be like 
calling save() for register with no reply. Why forward it again to same 
instance. Anyhow, even so, should be better to use t_replicate_to() 
instead of adding a new branch.

Cheers,
Daniel

-- 
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/1aae5537/attachment.html>


More information about the sr-users mailing list