[sr-dev] domain attributes

Jan Janak jan at iptel.org
Thu Jul 2 15:07:48 CEST 2009


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.



More information about the sr-dev mailing list