domain attributes

29 messages Options
Embed this post
Permalink
1 2
Juha Heinanen

domain attributes

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jesus Rodriguez

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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.
[hidden email]
http://www.voztele.com
Tel. 902360305
-------------------------------------





_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Juha Heinanen
in order to simplify implementation, i'm also planning to drop db_mode=0
(no cache).

-- juha

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Juha Heinanen
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:[hidden email]',
'sip:[hidden email]', or 'sip:[hidden email]'.

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.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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.


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jan Janak
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Juha Heinanen
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.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Juha Heinanen
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.


_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jan Janak
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?

-- juha

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jan Janak


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
> [hidden email]
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jan Janak

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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 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.

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.

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jan Janak
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Klaus Darilion
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus Darilion

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jan Janak


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 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.
>
> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Andrei Pelinescu-Onciul

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jan Janak
On Jul 02, 2009 at 16:13, Jan Janak <[hidden email]> 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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha Heinanen

Re: domain attributes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Andrei Pelinescu-Onciul
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

_______________________________________________
sr-dev mailing list
[hidden email]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
1 2