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/

Thanks for the tip! I am already using SEMS for digest auth handling in invite flows, so I suppose it would not be too big of a stretch. But I'd still like to find a Kamailio-based way for this specific task if possible, partly because I believe uacreg would be more useful if it were more flexible. I am, as I always have been, very appreciative of your efforts with SEMS and use it extensively for various applications. -- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness. 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/ On Nov 7, 2011, at 4:45 AM, Stefan Sayer <stefan.sayer(a)googlemail.com> wrote:

Hello, On 11/7/11 2:55 AM, Alex Balashov wrote: sure, if you have the patch, you can put it on a branch or tracker and I will look over it. 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 -- 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