Differences
This shows you the differences between two versions of the page.
| 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:// | + | 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: " | ||
| + | (the list of global AVPs, loaded independent of any message attribute). If the AVP list is not specified, the " | ||
| + | |||
| + | 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: " | ||
| + | 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 " | ||
| + | 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:// | ||
| 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 | ||
| </ | </ | ||
| + | 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: | ||
| + | |||
| + | < | ||
| + | | ||
| + | </ | ||
| + | |||
| + | 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 " | ||
| + | < | ||
| + | $foo | ||
| + | </ | ||
| + | the following fully qualified AVPs will be tried (stopping at the first that exists): $fr.foo (URI-level AVP, from/caller track), | ||
| + | | ||
| + | |||
| + | For AVPs with a specified list/track (" | ||
| + | < | ||
| + | | ||
| + | </ | ||
| + | the following fully qualified AVPs will be tried: $tr.foo, $tu.foo, $td.foo, $g.foo. | ||
| + | < | ||
| + | $f.foo | ||
| + | </ | ||
| + | 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 | ||
| + | < | ||
| + | | ||
| + | </ | ||
| + | only the " | ||
| + | |||
| + | Note that the global AVP list/track does not have any levels/ | ||
| + | |||
| + | ==== Accessing AVPs via Kamailio PVs ==== | ||
| + | |||
| + | In Kamailio the AVPs are available through pseudovariable class $avp(name) - the ' | ||
| + | |||
| + | * $avp(foo) | ||
| + | * $avp(fd.foo) | ||
| + | * $avp(t.foo) | ||
| + | |||
