[SR-Users] Conditional uacreg

[Daniel-Constantin Mierla]

Hello,

On 11/7/11 2:55 AM, Alex Balashov wrote:
> Daniel,
>
> Sorry for the mis-threaded reply;  I lost your original response and 
> am having to reply to my own.
>
> I haven't actually tried dropping uacreg registrations in 
> onsend_route, but the explanation of onsend_route limitations in the 
> core cookbook says:
>
>     "This route is executed only when forwarding requests - it is
>      not executed for replies, retransmissions, or locally
>      generated messages (e.g. via fifo uac)."
>
> Thus, I assumed it would not be usable for this purpose.  Am I wrong 
> to assume that?
>
> The most ideal implementation for me would be one in which the uac 
> module periodically reloads the uacreg table on a timer, or can be 
> stimulated to do so externally via an MI or RPC command.  It would 
> then unregister (send REGISTERs with an expiration of 0) every binding 
> that is no longer in the table but is present in memory.  Would you 
> accept such a patch from me?

sure, if you have the patch, you can put it on a branch or tracker and I 
will look over it.

> In the meantime, a hack like blocking certain registrations from going 
> out would suffice.
>
> Let me put it in larger context:
>
> The reason I need it is that I am building a kind of "SBC" in which 
> Kamailio accepts registrations from certain devices and then remaps 
> them to totally different AORs and credentials on the service provider 
> side.  However, having only _some_ of the devices registered upstream 
> on the service provider side--not all, not just one-to-one-- is a very 
> important requirement in this case.
>
> I would just use $uac_req(...) to generate them, except that I am 
> unable to catch failure replies (i.e. 401 challenges) to requests that 
> are locally generated that way and re-send with uac_auth() credentials.
>
> So, that is why I started using uacreg;  it handles the digest 
> authentication part seamlessly and without complications, and still 
> allows me to put in whatever upstream credentials I want.  The 
> trade-off I am facing is that uacreg is too automatic, too "managed"; 
>  it doesn't give me control over registrations going out, and only 
> loads the table once on boot.
Well, it is doing what was needed so far, that's one of the beautiful 
parts of open source, you need something new, patch it and there you are 
ready to go...

Cheers,
Daniel
>
> One compromise I considered is to use SEMS' SBC module to front the 
> registrations via its auth component, but SEMS presently only supports 
> doing this for INVITE flows, not REGISTERs or anything else.
>
> If you have any other suggestions, I am eager to hear them.
>
> Thanks!
>
> -- Alex
>

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda