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

[Olle E. Johansson]

16 sep 2013 kl. 20:54 skrev Steve Davies <steve-lists-srusers at connection-telecom.com>:

> 
> 
> 
> On 16 September 2013 19:49, Olle E. Johansson <oej at edvina.net> wrote:
> 
> 16 sep 2013 kl. 19:11 skrev Steve Davies <steve at connection-telecom.com>:
> 
>>> 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.
> 
> 
> Thanks for the reply.
> 
> It doesn't matter if the upstream isn't reachable?  I suppose not since if we just save the registration from the original REGISTER it doesn't matter what happens after that.
If so you can save and respond in the failure route. 

> 
> But I don't want the phone to show not-registered.  So I need to return an OK to the phone if (and only if) there is no response from the upstream.  Since If the registration actively fails upstream then I want the phone to show that, but if the registration fails because the upstream link is down then I want the registration to succeed from the pov of the phone since the phone is at least locally registered.
Yep. You need to consider what happens when upstream comes back. From that pov the phon ewill be unregistred.
> 
> My reasoning is that I conceptually I have a local registration backed up by a corresponding upstream registration.  But reading between the lines you are saying Kamailio can't easily do that if the upstream requires authentication?
I say you're making it too complex. Let the proxy be a proxy and force the client to behave properly.

/O


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