i'm thinking of extending domain module to support domain attributes. the idea is that domain_reload would also load domain's attributes to memory, where they can be accessed fast without db operations. when is_domain_local(domain) is called, attributes of the domain would get automatically loaded into avps.
if people consider this worth implementing, the next question is, where in the db domain attributes would be stored. it might be possible to use avpops usr_preferences table, but it contains fields uuid and username that are not relevant for domain attributes. perhaps a special uuid and/or username value could be used to denote that the record defines a domain attribute? if not, a new table would need to be created, which might be cleaner anyway.
any comments or better ideas on this?
-- juha
Hi Juha,
i'm thinking of extending domain module to support domain attributes. the idea is that domain_reload would also load domain's attributes to memory, where they can be accessed fast without db operations. when is_domain_local(domain) is called, attributes of the domain would get automatically loaded into avps.
if people consider this worth implementing, the next question is, where in the db domain attributes would be stored. it might be possible to use avpops usr_preferences table, but it contains fields uuid and username that are not relevant for domain attributes. perhaps a special uuid and/or username value could be used to denote that the record defines a domain attribute? if not, a new table would need to be created, which might be cleaner anyway.
any comments or better ideas on this?
I think a new table is much cleaner and clear than using usr_preferences.
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
in order to simplify implementation, i'm also planning to drop db_mode=0 (no cache).
-- juha
Juha,
On 02-07 14:33, Juha Heinanen wrote:
i'm thinking of extending domain module to support domain attributes. the idea is that domain_reload would also load domain's attributes to memory, where they can be accessed fast without db operations. when is_domain_local(domain) is called, attributes of the domain would get automatically loaded into avps.
I think that this is a good idea and also something we have already done in the ser version of domain module. What about adopting the ser version of the domain module?
if people consider this worth implementing, the next question is, where in the db domain attributes would be stored. it might be possible to use avpops usr_preferences table, but it contains fields uuid and username that are not relevant for domain attributes. perhaps a special uuid and/or username value could be used to denote that the record defines a domain attribute? if not, a new table would need to be created, which might be cleaner anyway.
In SER we introduced a new table called domain attrs. Our version of domain module has been extended this way:
1) We added column did to the domain table. did stands for "domain identifier" and it uniquely represents virtual domains within SER. Retrospectively I think "did" was a bad name, because in traditional POTS world it has a different meaning (which I didn't know when I added it).
Our domain table looks like this:
mysql> describe domain; +--------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+------------------+------+-----+---------+-------+ | did | varchar(64) | NO | MUL | NULL | | | domain | varchar(128) | NO | PRI | NULL | | | flags | int(10) unsigned | NO | | 0 | | +--------+------------------+------+-----+---------+-------+ 3 rows in set (0.00 sec)
Every virtual domain (represented by did) can have a number of domain names assigned and they are all treated equally by all other SER modules. For example, here is how the iptel.org domain can be represented in the domain table:
mysql> select * from domain where did=3; +-----+-----------------+-------+ | did | domain | flags | +-----+-----------------+-------+ | 3 | iptel.org | 33 | | 3 | sip.iptel.org | 33 | | 3 | proxy.iptel.org | 33 | +-----+-----------------+-------+ 3 rows in set (0.00 sec)
In all other tables in the SER database schema we replaced column 'domain' with 'did'. Thus, I can be reached as 'sip:jan@iptel.org', 'sip:jan@sip.iptel.org', or 'sip:jan@proxy.iptel.org'.
All extra configuration information for virtual domains is then stored in domain attributes that are stored in domain_attrs table:
mysql> describe domain_attrs; +-------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+-------+ | did | varchar(64) | YES | MUL | NULL | | | name | varchar(32) | NO | | NULL | | | type | int(11) | NO | | 0 | | | value | varchar(255) | YES | | NULL | | | flags | int(10) unsigned | NO | | 0 | | +-------+------------------+------+-----+---------+-------+ 5 rows in set (0.00 sec)
The contents of domain_attrs is loaded into the memory by domain module. Domain attrs are always cached and they can be reloaded from the database with a rpc/mi command.
For example, we store digest authentication realm for each virtual domain in that table:
mysql> select * from domain_attrs where did=3; +------+--------------+------+-----------+-------+ | did | name | type | value | flags | +------+--------------+------+-----------+-------+ | 3 | digest_realm | 2 | iptel.org | 33 | +------+--------------+------+-----------+-------+ 1 row in set (0.01 sec)
This allows us to configure the digest authentication realm separately from the domain name. This can be used, for example, to share digest authentication realm across multiple domain, we can keep the realm when we change the domain name, etc.
If this is what you are after then I would suggest to adopt the ser version of domain module.
Jan.
Jan Janak writes:
I think that this is a good idea and also something we have already done in the ser version of domain module. What about adopting the ser version of the domain module?
jan,
good if it is already done.
however, when i look at modules_s/domain/README, it only implements one function:
1.4.1. is_from_local()
and exported params section does not mention domain_attrs table and domain table section does not correspond to what you write.
the question is, it is faster to implement the attr stuff in modules_k/domain module than to update modules_s/domain readme?
The contents of domain_attrs is loaded into the memory by domain module. Domain attrs are always cached and they can be reloaded from the database with a rpc/mi command.
how can i get attributes of a domain loaded to avps?
-- juha
On 02-07 15:15, Juha Heinanen wrote:
Jan Janak writes:
I think that this is a good idea and also something we have already done in the ser version of domain module. What about adopting the ser version of the domain module?
jan,
good if it is already done.
however, when i look at modules_s/domain/README, it only implements one function:
1.4.1. is_from_local()
Unfortunately the module README hasn't been updated. The domain module also exports function lookup_domain. This is the function which lookups a domain name in the table and if it finds it, it will stored the did of that domain in an AVP.
In etc/sip-router-oob.cfg it is used like this:
route[DOMAIN] { # Check whether the caller is from a local domain. lookup_domain("$fd", "@from.uri.host");
# Check whether the callee is at a local domain lookup_domain("$td", "@ruri.host"); }
The first call will store the did of the domain in $fd.did if it finds a match. The second call will store the did in $td.did.
We then use those two AVPs to determine the type of the call, i.e. if there is no $fd.did and no $fd.did then this is a relaying attempts, if there is only $fd.did then this is an outbound call, etc...
and exported params section does not mention domain_attrs table and domain table section does not correspond to what you write.
the question is, it is faster to implement the attr stuff in modules_k/domain module than to update modules_s/domain readme?
Well, if we adopt SER version then we only have to update the README. If you want to implement your own version then you have to write the code *and* update the README.
And given that we try to merge both implementations, it would be make IMHO more sense to reuse the stuff that we already have available.
But the decision is yours, I can help update the documentation if you choose the SER version. If you decide to implement your own version, please take our implementation into account. I would like to merge such basic stuff as multi-domain support in the future and it would be great if our stuff could be transformed into your without too much hassle.
The contents of domain_attrs is loaded into the memory by domain module. Domain attrs are always cached and they can be reloaded from the database with a rpc/mi command.
how can i get attributes of a domain loaded to avps?
They are loaded automatically at startup. If you want to reload them then there is domain.reload RPC command available which can be triggered with sercmd.
Internally, domain module maintains a set of attributes in shared memory for each virtual domain. If the script calls lookup_domain and a match is found, then the function, in addition to storing the did of the domain in an AVP, also makes all the AVPs for that virtual domain available to the script.
So, domain attributes of the source domain (From) are available through the preefix $fd, thus the digest_realm attribute will be available in the AVP with the following name:
$fd.digest_realm
Similarly, for the called virtual domain (Request-URI):
$td.digest_realm
Domain attributes are read only, they cannot be modified from the script because they are stored in shared memory. The only way how one can modify the value of a domain attribute is to modify the attribute in the database and then call domain.reload.
Jan.
Jan Janak writes:
route[DOMAIN] { # Check whether the caller is from a local domain. lookup_domain("$fd", "@from.uri.host");
# Check whether the callee is at a local domain lookup_domain("$td", "@ruri.host");}
The first call will store the did of the domain in $fd.did if it finds a match. The second call will store the did in $td.did.
jan,
i start to get it, although i'm not familiar with ser's avp naming system. can each avp name be followed by .something? what does @ sign mean in front of ruri.host in above? can the same call be written as:
lookup_domain("$td", "$rd") ?
Well, if we adopt SER version then we only have to update the README. If you want to implement your own version then you have to write the code *and* update the README.
if ser's domain module does what i'm after, then it makes sense to adopt it and update the doc.
Internally, domain module maintains a set of attributes in shared memory for each virtual domain. If the script calls lookup_domain and a match is found, then the function, in addition to storing the did of the domain in an AVP, also makes all the AVPs for that virtual domain available to the script.
so if i have in domain_attrs table an attribute "foo" for a domain, i can get the value of the attribute after the above lookup_domain call as $td.foo? can the attribute name be an int or only a string?
-- juha
On 02-07 15:53, Juha Heinanen wrote:
Jan Janak writes:
route[DOMAIN] { # Check whether the caller is from a local domain. lookup_domain("$fd", "@from.uri.host");
# Check whether the callee is at a local domain lookup_domain("$td", "@ruri.host");}
The first call will store the did of the domain in $fd.did if it finds a match. The second call will store the did in $td.did.
jan,
i start to get it, although i'm not familiar with ser's avp naming system. can each avp name be followed by .something? what does @ sign mean in front of ruri.host in above? can the same call be written as:
lookup_domain("$td", "$rd") ?
Identifiers starting with $ denote AVPs. Identifiers starting with @ denote selects. Selects are similar to pseudo-variables in Kamailio.
In the example I presented, @ruri.host retrieves the host part of the Request-URI from the SIP request. For more documentation on the select framework, see
http://sip-router.org/wiki/ref_manual/selects
Regarding AVP names, we ditched integer AVP names and use string AVP identifiers exclusively. Each AVP identifiers starts with $ sign, followed by a couple letters such as fd, td, fu. These letters specify the group of AVPs you are accessing, such as: * td - to domain avp * fd - from domain avp * tu - to user avp * fu - from user avp
Then there is the delimiting '.', followed by the name of the avp.
See a more detailed description here: http://sip-router.org/wiki/devel/avps-ser
So, the following example
lookup_domain("$fd", "@from.uri.host");
reads as "take the domain part of the From URI, lookup the virtual domain and if you found it, store the resulting did in $fd.did attribute. The first parameter specifies that the virtual domain identifiers and all attributes of the virtual domain should be made available through $fd prefix.
Well, if we adopt SER version then we only have to update the README. If you want to implement your own version then you have to write the code *and* update the README.
if ser's domain module does what i'm after, then it makes sense to adopt it and update the doc.
Internally, domain module maintains a set of attributes in shared memory for each virtual domain. If the script calls lookup_domain and a match is found, then the function, in addition to storing the did of the domain in an AVP, also makes all the AVPs for that virtual domain available to the script.
so if i have in domain_attrs table an attribute "foo" for a domain, i can get the value of the attribute after the above lookup_domain call as $td.foo? can the attribute name be an int or only a string?
Exactly. The name of the attribute must be string.
Jan.
On 02-07 16:42, Juha Heinanen wrote:
Jan Janak writes:
So, the following example
lookup_domain("$fd", "@from.uri.host");
you didn't answer, can the above be also written as:
lookup_domain("$fd", "$fd");if not, why?
Yes it can. In this particular case the function will assume that the domain name to be looked up is stored in the AVP $fu.fd. If the AVP identifiers does not contain the flags before the delimiting '.' then 'fu' is assumed. So the function will try to retrieve the domain name from that AVP and if it does not exist (which is likely) then the function returns -1.
Some more examples:
lookup("$fd", "iptel.org") # lookup the iptel.org domain name lookup("$fd", "@to.uri.host") # lookup the hostname part of To header URI
# The following two are equivalent lookup("$fd", "$abcd) # lookup the domain stored in "abcd" AVP lookup("$fd", "$fu.abcd) # lookup the domain stored in "abcd" AVP
Jan.
Jan Janak writes:
you didn't answer, can the above be also written as:
lookup_domain("$fd", "$fd");if not, why?
Yes it can. In this particular case the function will assume that the domain name to be looked up is stored in the AVP $fu.fd. If the AVP identifiers does not contain the flags before the delimiting '.' then 'fu' is assumed. So the function will try to retrieve the domain name from that AVP and if it does not exist (which is likely) then the function returns -1.
i start to get lost again. i understand that i can reference avps of the above looked up domain as $fd.attribute_name. but why can't the domain that is being looked up simply be taken from the kamailio pseudo variable as it is written ($fd in the example) without assuming that it is in $fu.fd?
or is it so that second argument of lookup_domain cannot be a k pseudo variables at all? for example, can i take if from r-uri host like this:
lookup_domain("$fd", "$rd");
-- juha
Jan Janak schrieb:
On 02-07 15:53, Juha Heinanen wrote:
Jan Janak writes:
route[DOMAIN] { # Check whether the caller is from a local domain. lookup_domain("$fd", "@from.uri.host");
# Check whether the callee is at a local domain lookup_domain("$td", "@ruri.host");}
The first call will store the did of the domain in $fd.did if it finds a match. The second call will store the did in $td.did.
jan,
i start to get it, although i'm not familiar with ser's avp naming system. can each avp name be followed by .something? what does @ sign mean in front of ruri.host in above? can the same call be written as:
lookup_domain("$td", "$rd") ?
Identifiers starting with $ denote AVPs. Identifiers starting with @ denote selects. Selects are similar to pseudo-variables in Kamailio.
Hi Jan!
So, how are ser identifiers and Kamailio pseudo-variables differentiated? Both start with $.
e.g. in Kamailio $fd is the domain of the URI in the From header.
regards klaus
In the example I presented, @ruri.host retrieves the host part of the Request-URI from the SIP request. For more documentation on the select framework, see
http://sip-router.org/wiki/ref_manual/selects
Regarding AVP names, we ditched integer AVP names and use string AVP identifiers exclusively. Each AVP identifiers starts with $ sign, followed by a couple letters such as fd, td, fu. These letters specify the group of AVPs you are accessing, such as:
- td - to domain avp
- fd - from domain avp
- tu - to user avp
- fu - from user avp
Then there is the delimiting '.', followed by the name of the avp.
See a more detailed description here: http://sip-router.org/wiki/devel/avps-ser
So, the following example
lookup_domain("$fd", "@from.uri.host");
reads as "take the domain part of the From URI, lookup the virtual domain and if you found it, store the resulting did in $fd.did attribute. The first parameter specifies that the virtual domain identifiers and all attributes of the virtual domain should be made available through $fd prefix.
Well, if we adopt SER version then we only have to update the README. If you want to implement your own version then you have to write the code *and* update the README.
if ser's domain module does what i'm after, then it makes sense to adopt it and update the doc.
Internally, domain module maintains a set of attributes in shared memory for each virtual domain. If the script calls lookup_domain and a match is found, then the function, in addition to storing the did of the domain in an AVP, also makes all the AVPs for that virtual domain available to the script.
so if i have in domain_attrs table an attribute "foo" for a domain, i can get the value of the attribute after the above lookup_domain call as $td.foo? can the attribute name be an int or only a string?
Exactly. The name of the attribute must be string.
Jan.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 02-07 16:04, Klaus Darilion wrote:
Jan Janak schrieb:
On 02-07 15:53, Juha Heinanen wrote:
Jan Janak writes:
route[DOMAIN] { # Check whether the caller is from a local domain. lookup_domain("$fd", "@from.uri.host");
# Check whether the callee is at a local domainlookup_domain("$td", "@ruri.host");}
The first call will store the did of the domain in $fd.did if
it finds a
match. The second call will store the did in $td.did.
jan,
i start to get it, although i'm not familiar with ser's avp naming system. can each avp name be followed by .something? what does @ sign mean in front of ruri.host in above? can the same call be written as:
lookup_domain("$td", "$rd") ?
Identifiers starting with $ denote AVPs. Identifiers starting with @ denote selects. Selects are similar to pseudo-variables in Kamailio.
Hi Jan!
So, how are ser identifiers and Kamailio pseudo-variables differentiated? Both start with $.
e.g. in Kamailio $fd is the domain of the URI in the From header.
Ohh, that's a very good point and this is also probably the reason why Juha was asking about the lookup_domain("$fd", "$fd") example--but I didn't get it.
I am not sure now whether $fd in the second parameter of lookup_domain will be treated as an AVP or as a pseudo-variable, Andrei?
Jan.
Jan Janak schrieb:
On 02-07 16:04, Klaus Darilion wrote:
Jan Janak schrieb:
On 02-07 15:53, Juha Heinanen wrote:
Jan Janak writes:
route[DOMAIN] { # Check whether the caller is from a local domain. lookup_domain("$fd", "@from.uri.host");
# Check whether the callee is at a local domainlookup_domain("$td", "@ruri.host");}
The first call will store the did of the domain in $fd.did if
it finds a
match. The second call will store the did in $td.did.
jan,
i start to get it, although i'm not familiar with ser's avp naming system. can each avp name be followed by .something? what does @ sign mean in front of ruri.host in above? can the same call be written as:
lookup_domain("$td", "$rd") ?
Identifiers starting with $ denote AVPs. Identifiers starting with @ denote selects. Selects are similar to pseudo-variables in Kamailio.
Hi Jan!
So, how are ser identifiers and Kamailio pseudo-variables differentiated? Both start with $.
e.g. in Kamailio $fd is the domain of the URI in the From header.
Ohh, that's a very good point and this is also probably the reason why Juha was asking about the lookup_domain("$fd", "$fd") example--but I didn't get it.
I am not sure now whether $fd in the second parameter of lookup_domain will be treated as an AVP or as a pseudo-variable, Andrei?
Is the $fd identifer only in certain function parameters allowed or everywhere in the config script?
regards klaus
On Jul 02, 2009 at 16:13, Jan Janak jan@iptel.org wrote: [...]
So, how are ser identifiers and Kamailio pseudo-variables differentiated? Both start with $.
e.g. in Kamailio $fd is the domain of the URI in the From header.
Ohh, that's a very good point and this is also probably the reason why Juha was asking about the lookup_domain("$fd", "$fd") example--but I didn't get it.
I am not sure now whether $fd in the second parameter of lookup_domain will be treated as an AVP or as a pseudo-variable, Andrei?
lookup_domain works only with avps, selects and string params. It won't try to lookup its param as a pvar. In general in the script (and not in modules calls), when something starts with $ and does not have one of the avp list prefixes (fd., fu. a.s.o), first pvars will be looked up and if there is no result the avps.
To make the same thing work for most ser modules, the fixup_* functions (e.g.: fixup_var_str_12 that is used by lookup_domain) from sr_module.c should be modified either in a similar way, or they should just try fix_param(FPARAM_AVP, param) if first fix_param(FPARAM_PVS, param) failed. One might need to remove the error messages printed by fix_param() if AVP or PVAR parsing fails (to allow for retrying with AVP or PVARs without filling the log with errors).
Note that fix_param(FPARAM_PVS, param) already works. The only change needed might be removal of parse error messages and maybe a quicker check for AVP (e.g. if 2nd or 3rd char is '.' is probably an AVP => don't try PV lookup). The get_*_fparam functions also work, so only minor changes would be needed and lots of testing.
Andrei
while comparing s and k domain module, i noticed that k domain module exports is_domain_local api function for other modules. that would also need to be added and i have no clue on how to do that in s.
-- juha
On 02-07 17:53, Juha Heinanen wrote:
while comparing s and k domain module, i noticed that k domain module exports is_domain_local api function for other modules. that would also need to be added and i have no clue on how to do that in s.
OK, this is easy, we have is_domain local function in the ser version of the module, so I can export that one through an API to other modules.
Jan.
Andrei Pelinescu-Onciul writes:
To make the same thing work for most ser modules, the fixup_* functions (e.g.: fixup_var_str_12 that is used by lookup_domain) from sr_module.c should be modified either in a similar way, or they should just try fix_param(FPARAM_AVP, param) if first fix_param(FPARAM_PVS, param) failed. One might need to remove the error messages printed by fix_param() if AVP or PVAR parsing fails (to allow for retrying with AVP or PVARs without filling the log with errors).
in order to avoid unnecessary lookups, it should be possible (if not mandatory) to differentiate avps and pvars syntactically. it is very bad, if "$fd" can be either an avp with name "fd" or a pseudo variable denoting domain of from uri. in k, "fd" avp would be written as $avp("fd") and no double lookup would be needed.
-- juha
On Jul 02, 2009 at 18:06, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
To make the same thing work for most ser modules, the fixup_* functions (e.g.: fixup_var_str_12 that is used by lookup_domain) from sr_module.c should be modified either in a similar way, or they should just try fix_param(FPARAM_AVP, param) if first fix_param(FPARAM_PVS, param) failed. One might need to remove the error messages printed by fix_param() if AVP or PVAR parsing fails (to allow for retrying with AVP or PVARs without filling the log with errors).
in order to avoid unnecessary lookups, it should be possible (if not mandatory) to differentiate avps and pvars syntactically. it is very bad, if "$fd" can be either an avp with name "fd" or a pseudo variable denoting domain of from uri. in k, "fd" avp would be written as $avp("fd") and no double lookup would be needed.
They are looked twice but only at startup (fixup for the script and the modules) so there shouldn't be any runtime performance hit because of this.
I agree however that we should differentiate somehow, but for now we have to support the legacy modes (ser & kamailio) to make initial migration easier.
Andrei
Andrei Pelinescu-Onciul writes:
They are looked twice but only at startup (fixup for the script and the modules) so there shouldn't be any runtime performance hit because of this.
if i write in my script somewhere
$avp("fd") = "foo";
and in some other place reference $fd, how can double lookup during runtime be avoided?
-- juha
On Jul 02, 2009 at 18:20, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
They are looked twice but only at startup (fixup for the script and the modules) so there shouldn't be any runtime performance hit because of this.
if i write in my script somewhere
$avp("fd") = "foo";
and in some other place reference $fd, how can double lookup during runtime be avoided?
At fixup time $fd is looked-up. If it's a pvar is replaced with a pv spec. If it's not with an avp spec. At runtime whatever is already "fixed-up" is resolved. In the $fd case -> an avp ($avp("fd") is cleary a pvar, and $fd it can be a pvar or an avp: if at fixup pvar lookup($fd) fails => its avp => it's marked as avp an at runtime only avp search is used).
Andrei
Andrei Pelinescu-Onciul writes:
if i write in my script somewhere
$avp("fd") = "foo";
and in some other place reference $fd, how can double lookup during runtime be avoided?
At fixup time $fd is looked-up. If it's a pvar is replaced with a pv spec. If it's not with an avp spec.
ok. does this fixup happen also when $fd is used in an expression, like
$var(foo) = $fd;
if i write
lookup_domain("$fd", "$fd");
the first $fd must be an avp, because lookup_domain expects an avp name as first param and the second could be either a pvar or avp, but that can be determined at fixup time.
-- juha
On Jul 02, 2009 at 18:53, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
if i write in my script somewhere
$avp("fd") = "foo";
and in some other place reference $fd, how can double lookup during runtime be avoided?
At fixup time $fd is looked-up. If it's a pvar is replaced with a pv spec. If it's not with an avp spec.
ok. does this fixup happen also when $fd is used in an expression, like
$var(foo) = $fd;
Yes.
if i write
lookup_domain("$fd", "$fd");
the first $fd must be an avp, because lookup_domain expects an avp name as first param and the second could be either a pvar or avp, but that can be determined at fixup time.
That does not work right now, but it would be very easy to make it work.
Andrei
Andrei Pelinescu-Onciul writes:
lookup_domain("$fd", "$fd");
the first $fd must be an avp, because lookup_domain expects an avp name as first param and the second could be either a pvar or avp, but that can be determined at fixup time.
That does not work right now, but it would be very easy to make it work.
that and is_domain api function seem to be the conditions for adopting s domain module.
-- juha
Klaus Darilion writes:
So, how are ser identifiers and Kamailio pseudo-variables differentiated? Both start with $.
e.g. in Kamailio $fd is the domain of the URI in the From header.
that is exactly what confuses me too (see the message that i just sent out before reading this one from klaus).
-- juha
Jan Janak writes:
mysql> describe domain; +--------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+------------------+------+-----+---------+-------+ | did | varchar(64) | NO | MUL | NULL | | | domain | varchar(128) | NO | PRI | NULL | | | flags | int(10) unsigned | NO | | 0 | | +--------+------------------+------+-----+---------+-------+
mysql> describe domain_attrs; +-------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+-------+ | did | varchar(64) | YES | MUL | NULL | | | name | varchar(32) | NO | | NULL | | | type | int(11) | NO | | 0 | | | value | varchar(255) | YES | | NULL | | | flags | int(10) unsigned | NO | | 0 | | +-------+------------------+------+-----+---------+-------+
what is the meaning of "flags" column?
-- juha
On 02-07 16:04, Juha Heinanen wrote:
Jan Janak writes:
mysql> describe domain; +--------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+------------------+------+-----+---------+-------+ | did | varchar(64) | NO | MUL | NULL | | | domain | varchar(128) | NO | PRI | NULL | | | flags | int(10) unsigned | NO | | 0 | | +--------+------------------+------+-----+---------+-------+
mysql> describe domain_attrs; +-------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+-------+ | did | varchar(64) | YES | MUL | NULL | | | name | varchar(32) | NO | | NULL | | | type | int(11) | NO | | 0 | | | value | varchar(255) | YES | | NULL | | | flags | int(10) unsigned | NO | | 0 | | +-------+------------------+------+-----+---------+-------+
what is the meaning of "flags" column?
This is a generic flags column which we added to most tables that store AVPs and to some other tables too. Individual flags can be used to mark a row as disabled -- this allows us to disable a particular attribute without deleting it from the database. A disabled attribute will be ignored by SER. Another flag can be used to mark a row as deleted. Such row/attribute will be again ignored by SER. Rows with the deleted flag set are deleted by a cron job. And so on.
And there are other flags defined, they are all listed in sip-router/lib/srdb2/db.h
Jan.
Jan Janak writes:
mysql> describe domain_attrs; +-------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+------------------+------+-----+---------+-------+ | did | varchar(64) | YES | MUL | NULL | | | name | varchar(32) | NO | | NULL | | | type | int(11) | NO | | 0 | | | value | varchar(255) | YES | | NULL | | | flags | int(10) unsigned | NO | | 0 | | +-------+------------------+------+-----+---------+-------+
if domain_attrs define attributes of domains, how can did be NULL?
-- juha
On Thu, Jul 2, 2009 at 5:09 PM, Juha Heinanenjh@tutpro.com wrote:
Jan Janak writes:
> mysql> describe domain_attrs; > +-------+------------------+------+-----+---------+-------+ > | Field | Type | Null | Key | Default | Extra | > +-------+------------------+------+-----+---------+-------+ > | did | varchar(64) | YES | MUL | NULL | | > | name | varchar(32) | NO | | NULL | | > | type | int(11) | NO | | 0 | | > | value | varchar(255) | YES | | NULL | | > | flags | int(10) unsigned | NO | | 0 | | > +-------+------------------+------+-----+---------+-------+
if domain_attrs define attributes of domains, how can did be NULL?
This is a backward compatibility hack which allows to use the domain table with the old domain module. In that case you just write all domain names into the domain table and let did be NULL. In that case they will all belong to one virtual domain.
One can enable/disable the use of domain attributes, in fact they are disabled by default with load_domain_attrs domain module parameter.
Jan.
-
Andrei Pelinescu-Onciul -
Jan Janak -
Jan Janak -
Jesus Rodriguez -
jh＠tutpro.com -
Klaus Darilion