2 Jul
2009
2 Jul
'09
2:33 p.m.
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
2 Jul
2 Jul
2:44 p.m.
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(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
2:53 p.m.
in order to simplify implementation, i'm also planning to drop db_mode=0
(no cache).
-- juha
3:03 p.m.
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.
3:15 p.m.
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
3:34 p.m.
On 02-07 15:15, Juha Heinanen wrote:
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:
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", "(a)from.uri.host")ost");
# Check whether the callee is at a local domain
lookup_domain("$td", "(a)ruri.host")ost");
}
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...
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?
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?
3:53 p.m.
Jan Janak writes:
route[DOMAIN]
{
# Check whether the caller is from a local domain.
lookup_domain("$fd", "(a)from.uri.host")ost");
# Check whether the callee is at a local domain
lookup_domain("$td", "(a)ruri.host")ost");
}
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
4:07 p.m.
On 02-07 15:53, Juha Heinanen wrote:
Exactly. The name of the attribute must be string.
Jan.
Jan Janak writes:
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", "(a)from.uri.host")ost");
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.
route[DOMAIN]
{
# Check whether the caller is from a local domain.
lookup_domain("$fd", "(a)from.uri.host")ost");
# Check whether the callee is at a local domain
lookup_domain("$td", "(a)ruri.host")ost");
}
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?
4:54 p.m.
On 02-07 16:42, Juha Heinanen wrote:
Jan Janak writes:
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", "(a)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.
So, the following example
lookup_domain("$fd", "(a)from.uri.host")ost");
you didn't answer, can the above be also written as:
lookup_domain("$fd", "$fd");
if not, why?
5:14 p.m.
Jan Janak writes:
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
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. 
5:04 p.m.
Jan Janak schrieb:
On 02-07 15:53, Juha Heinanen wrote:
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
Jan Janak writes:
Identifiers starting with $ denote AVPs. Identifiers starting with @ denote
selects. Selects are similar to pseudo-variables in Kamailio. route[DOMAIN]
{
# Check whether the caller is from a local domain.
lookup_domain("$fd", "(a)from.uri.host")ost");
# Check whether the callee is at a local domain
lookup_domain("$td", "(a)ruri.host")ost");
}
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") ?
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", "(a)from.uri.host")ost");
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.
Exactly. The name of the attribute must be string.
Jan.
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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?
5:13 p.m.
On 02-07 16:04, Klaus Darilion wrote:
Jan Janak schrieb:
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.
On 02-07 15:53, Juha Heinanen wrote:
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. Jan Janak writes:
Identifiers starting with $ denote AVPs. Identifiers starting with @ denote
selects. Selects are similar to pseudo-variables in Kamailio. route[DOMAIN]
{
# Check whether the caller is from a local domain.
lookup_domain("$fd", "(a)from.uri.host")ost");
> # Check whether the callee is at a local domain
lookup_domain("$td", "(a)ruri.host")ost");
}
> 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") ?
5:16 p.m.
Jan Janak schrieb:
On 02-07 16:04, Klaus Darilion wrote:
Is the $fd identifer only in certain function parameters allowed or
everywhere in the config script?
regards
klaus
Jan Janak schrieb:
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? On 02-07 15:53, Juha Heinanen wrote:
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. Jan Janak writes:
> route[DOMAIN]
> {
> # Check whether the caller is from a local domain.
> lookup_domain("$fd", "(a)from.uri.host")ost");
> > # Check whether the callee is at a local domain
> lookup_domain("$td", "(a)ruri.host")ost");
> }
> > 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. 
5:38 p.m.
On Jul 02, 2009 at 16:13, Jan Janak <jan(a)iptel.org> wrote:
[...]
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
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?
5:53 p.m.
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
3 Jul
3 Jul
12:19 p.m.
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.
2 Jul
2 Jul
6:06 p.m.
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
6:15 p.m.
On Jul 02, 2009 at 18:06, Juha Heinanen <jh(a)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.
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
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.
6:20 p.m.
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
6:46 p.m.
On Jul 02, 2009 at 18:20, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
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
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?
6:53 p.m.
Andrei Pelinescu-Onciul writes:
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
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.
6:58 p.m.
On Jul 02, 2009 at 18:53, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
ok. does this fixup happen also when $fd is used in an expression, like
$var(foo) = $fd;
Yes.
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.
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
7:08 p.m.
Andrei Pelinescu-Onciul writes:
that and is_domain api function seem to be the conditions for adopting s
domain module.
-- juha
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.
5:16 p.m.
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
4:04 p.m.
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
4:12 p.m.
On 02-07 16:04, Juha Heinanen wrote:
Jan Janak writes:
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.
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?
6:09 p.m.
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
3 Jul
3 Jul
4:49 p.m.
On Thu, Jul 2, 2009 at 5:09 PM, Juha Heinanen<jh(a)tutpro.com> wrote:
Jan Janak writes:
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.
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?
5628
days inactive
5629
days old
28 comments
6 participants
participants (6)
-
Andrei Pelinescu-Onciul -
Jan Janak -
Jan Janak -
Jesus Rodriguez -
jh＠tutpro.com -
Klaus Darilion