Hello
When one creates a user using the cli command like this: "kamctl add 200 abc", it is my understanding that the information goes to the subscriber table and into memory. Is that right?
But if one populates the subscriber table manually [adding a record on the table w/o the /kamctlcli command], do we need to "load" those accounts into memory before a client tries to register or does kamailio looks it up when the registration request comes in at that time?
What we are trying to do is to bulk load subscribers on the subscribers table instead of using the "kamctl add" command. For example, with LCR parameters we modify the tables manually and then do a "lcr_reload" and all the changes will be in memory after the reload.
thank you in advance fborot
On 08/11/2011 12:45 PM, Fabian Borot wrote:
But if one populates the subscriber table manually [adding a record on the table w/o the /kamctlcli command], do we need to "load" those accounts into memory before a client tries to register or does kamailio looks it up when the registration request comes in at that time?
It's looked up in real-time -- if you are using auth_db as your auth authentication backend.
thank you alex
so that means that we can populate the subscribers table manually, so that when a user is going to register the first time kamailio will look the account up and get the user, passwd etc to prepare the md5 challenge. Then once the user is able to register depending on the settings for usrloc db [db_mode=0,1,2,3] the record will be in memory and/or db.
is that how it is?
and if we have a huge subscribers table, since apparently kamailio wont load those values in memory [only the AOR for the registered users] that is not a problem at all right?
Am 11.08.2011 19:39, schrieb Fabian Borot:
thank you alex
so that means that we can populate the subscribers table manually, so that when a user is going to register the first time kamailio will look the account up and get the user, passwd etc to prepare the md5 challenge.
Yes
Then once the user is able to register depending on the settings for usrloc db [db_mode=0,1,2,3] the record will be in memory and/or db.
No. The subscriber table is never cached. Every authentication request will cause a lookup in the database.
and if we have a huge subscribers table, since apparently kamailio wont load those values in memory [only the AOR for the registered users] that is not a problem at all right?
Thus, Kamailio does not care how many subscribers are in the table. Regarding load, the only thing that matters is the number of authentication requests per time interval.
You can not avoid the authentication load for INVITEs, but you can increase the "idle load" caused by REGISTER requests by increasing the expire value.
regards klaus
Hello,
On 8/12/11 9:12 AM, Klaus Darilion wrote:
Am 11.08.2011 19:39, schrieb Fabian Borot:
thank you alex
so that means that we can populate the subscribers table manually, so that when a user is going to register the first time kamailio will look the account up and get the user, passwd etc to prepare the md5 challenge.
Yes
Then once the user is able to register depending on the settings for usrloc db [db_mode=0,1,2,3] the record will be in memory and/or db.
No. The subscriber table is never cached. Every authentication request will cause a lookup in the database.
and if we have a huge subscribers table, since apparently kamailio wont load those values in memory [only the AOR for the registered users] that is not a problem at all right?
Thus, Kamailio does not care how many subscribers are in the table. Regarding load, the only thing that matters is the number of authentication requests per time interval.
You can not avoid the authentication load for INVITEs, but you can increase the "idle load" caused by REGISTER requests by increasing the expire value.
just to point some caching solution in case one wants to avoid too many DB lookup. htable module can be used to store the password after a successful authentication for a period of time. The logic will be like:
- request comes in - get from htable the password for the user - if password not in HT, do auth using database and load the password in credentials and store it in HT if auth ok - if password in HT, do auth using variables
HT has auto-expires capabilities, so cached passwords will be deleted after a while and the password value will be loaded next time when is needed. The drawback is that when the password is changed, it may take up to auto-expire interval to be effective.
Cheers, Daniel
Got it. Thank you very much Klaus and Alex.
From: fborot@hotmail.com To: sr-users@lists.sip-router.org Subject: RE: subscriber table reload Date: Thu, 11 Aug 2011 13:39:20 -0400
thank you alex
so that means that we can populate the subscribers table manually, so that when a user is going to register the first time kamailio will look the account up and get the user, passwd etc to prepare the md5 challenge. Then once the user is able to register depending on the settings for usrloc db [db_mode=0,1,2,3] the record will be in memory and/or db.
is that how it is?
and if we have a huge subscribers table, since apparently kamailio wont load those values in memory [only the AOR for the registered users] that is not a problem at all right?
-
Alex Balashov -
Daniel-Constantin Mierla -
Fabian Borot -
Klaus Darilion