[SR-Users] Conditional uacreg

[Alex Balashov]

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

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

-- 
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/