Is there some way by which credentials can be loaded into the uacreg table, but not all of them used at once?
The problem I have is a need to make these registrations active and inactive periodically, whereas the registration facility that the uac module provides is fully managed/largely unattended.
Using $uac_req(...) is not an option because I need to capture the failure replies (which is not supported in TM) in order to do digest challenge authentication.
P.S.
I have tried dropping them conditionally in the tm:local-request event route and onsend_route. It doesn't work when the request is endogenously generated.
On 11/04/2011 04:44 PM, Alex Balashov wrote:
Is there some way by which credentials can be loaded into the uacreg table, but not all of them used at once?
The problem I have is a need to make these registrations active and inactive periodically, whereas the registration facility that the uac module provides is fully managed/largely unattended.
Using $uac_req(...) is not an option because I need to capture the failure replies (which is not supported in TM) in order to do digest challenge authentication.
On 11/4/11 9:45 PM, Alex Balashov wrote:
P.S.
I have tried dropping them conditionally in the tm:local-request event route and onsend_route. It doesn't work when the request is endogenously generated.
dropping in tm:local-request is not possible, afaik (being considered that the decision was made by sender code), although should be added being sometimes useful, imo.
Not sure what is the reason for onsend_route, does it get there and drop does not work? Or it does not get there?
Maybe the best would be to add an event_route specific for uacreg, just before sending the request to tm for building and sending the sip register, providing in a PV the details of that registration. That will save some processing and memory to build the local transaction.
Cheers, Daniel
On 11/04/2011 04:44 PM, Alex Balashov wrote:
Is there some way by which credentials can be loaded into the uacreg table, but not all of them used at once?
The problem I have is a need to make these registrations active and inactive periodically, whereas the registration facility that the uac module provides is fully managed/largely unattended.
Using $uac_req(...) is not an option because I need to capture the failure replies (which is not supported in TM) in order to do digest challenge authentication.
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
Hi,
sorry for semi-offtopic o Alex Balashov on 11/07/2011 02:55 AM:
One compromise I considered is to use SEMS' SBC module to front the registrations via its auth component, but SEMS presently only supports
you can have sems register, and manage (add, remove etc) registrations via e.g. xmlrpc with the db_reg_agent module
doing this for INVITE flows, not REGISTERs or anything else.
you can also set the contact in the registration when using db_reg_agent (btw afair also when using registrar_client).
Stefan
If you have any other suggestions, I am eager to hear them.
Thanks!
-- Alex
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@googlemail.com wrote:
Hi,
sorry for semi-offtopic o Alex Balashov on 11/07/2011 02:55 AM:
One compromise I considered is to use SEMS' SBC module to front the registrations via its auth component, but SEMS presently only supports
you can have sems register, and manage (add, remove etc) registrations via e.g. xmlrpc with the db_reg_agent module
doing this for INVITE flows, not REGISTERs or anything else.
you can also set the contact in the registration when using db_reg_agent (btw afair also when using registrar_client).
Stefan
If you have any other suggestions, I am eager to hear them.
Thanks!
-- Alex
-- tel:+491621366449 sip:sayer@iptel.org mailto/xmpp:stefan.sayer@gmail.com
yes, understood, just a tip for if you are lazy (btw, if you want to nevertheless try it with stable 1.4, use sayer/1.4-dbreg branch)
Stefan
o Alex Balashov on 11/07/2011 10:51 AM:
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 Sayerstefan.sayer@googlemail.com wrote:
Hi,
sorry for semi-offtopic o Alex Balashov on 11/07/2011 02:55 AM:
One compromise I considered is to use SEMS' SBC module to front the registrations via its auth component, but SEMS presently only supports
you can have sems register, and manage (add, remove etc) registrations via e.g. xmlrpc with the db_reg_agent module
doing this for INVITE flows, not REGISTERs or anything else.
you can also set the contact in the registration when using db_reg_agent (btw afair also when using registrar_client).
Stefan
If you have any other suggestions, I am eager to hear them.
Thanks!
-- Alex
-- tel:+491621366449 sip:sayer@iptel.org mailto/xmpp:stefan.sayer@gmail.com
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Stefan Sayer