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