Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
devel:avps-ser [2009/03/12 16:39]
86.121.128.127 created
devel:avps-ser [2011/12/05 23:42] (current)
67.107.93.2 old revision restored
Line 1: Line 1:
 ====== AVPs in SER ====== ====== AVPs in SER ======
  
-From the mailing list:+=== Summary ===
  
-[[http://lists.sip-router.org/pipermail/sr-dev/2008-December/000227.html]]+AVPs are divided in lists (also referred as tracks). The lists allow loading at the same time AVPs with the same name for both the caller and the callee. 
 +There are 3 AVPs lists: "from" (the AVPs loaded based on the caller), "to" (the AVPs loaded based on the callee) and "global" 
 + (the list of global AVPs, loaded independent of any message attribute). If the AVP list is not specified, the "from" list will be used by default. 
 + 
 +Each AVP lists, except the global one, is further divided into levels (also referred as classes). Each level has its own namespace (several levels can contain AVPs with the same name in the same time). There are 3 AVP levels: "URI", "user" and "domain"
 + The levels allow further grouping of the AVPs based on characteristics such as uri, user or domain and choosing the most specific defined AVP if the level is not explicitly specified (e.g. an user level AVP will override a domain level AVP with the same name). The levels can also reduce the number of attributes stored in the database, by having the attributes common for the entire domain (a kind of default "settings") in one table and only a low number of specific overrides per user or per uri. 
 +If the level is no specified, SER will search for the given AVP in order, through the 3 levels. 
 + 
 + 
 +=== Reasons and Long Explanation === 
 + 
 + 
 +(based on Jan's message from the mailing list [[http://lists.sip-router.org/pipermail/sr-dev/2008-December/000227.html]] )
  
 A long time ago we started using AVPs to store all kinds of configuration information. We needed some sort of general configuration mechanism because real-world scripts were getting too complex and at that time the AVPs were readily available. A long time ago we started using AVPs to store all kinds of configuration information. We needed some sort of general configuration mechanism because real-world scripts were getting too complex and at that time the AVPs were readily available.
Line 69: Line 81:
   $fr.foo   $fr.foo
 </code> </code>
 +The list of URI-level AVPs is searched first, before the the list of the user-level AVPs, if the level is not explicitly specified. For example if you write:
 +
 +<code>
 + $f.foo
 +</code>
 +
 +Then SER searches the URI-level AVPs first, then (if not found) the user-level AVPS, then domain-level and finally the global AVPs.
 +
 +
 +
 +=== More Examples ===
 +
 +
 +For AVPs with no list/track (f/from , t/to or g/global) and no level/class (r - URI, u - user, d - domain) specified, all the classes for URI ( r ), user (u) and domain (d) from the "from "(caller) list/track will be tried in order, followed by the global AVPs. For example for
 +<code>
 + $foo
 +</code>
 +the following fully qualified AVPs will be tried (stopping at the first that exists): $fr.foo (URI-level AVP, from/caller track),
 + $fu.foo (user-level AVP, from/caller track), $fd.foo (domain-level AVP, from/caller track) and $g.foo (global-level AVP).
 +
 +For AVPs with a specified list/track ("from" or "to"), all the levels/classes will be tried in order, as above, but for the specified track. As above if nothing is found, the global AVPs will be tried. For example for 
 +<code>
 + $t.foo
 +</code>
 +the following fully qualified AVPs will be tried: $tr.foo, $tu.foo, $td.foo, $g.foo.
 +<code>
 +$f.foo
 +</code>
 + is equivalent with $foo ($foo is a shorthand for it).
 +
 +If the track and class are specified, then only that fully qualified AVP will be tried. For example for
 +<code>
 + $fd.foo
 +</code>
 + only the "domain" class  from the "from" AVP list will be searched for the "foo" AVP.
 +
 +Note that the global AVP list/track does not have any levels/classes. For example only $gu.foo is invalid, because it specifies a level/class for a global AVP.
 +
 +==== Accessing AVPs via Kamailio PVs ====
 +
 +In Kamailio the AVPs are available through pseudovariable class $avp(name) - the 'name' can have the format described above, for example:
 +
 +  * $avp(foo)
 +  * $avp(fd.foo)
 +  * $avp(t.foo)
 +

Navigation

Wiki

Other

QR Code
QR Code devel:avps-ser (generated for current page)