Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
devel:avps-ser [2010/09/28 11:45] andrei more examples and short summary |
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 78: | Line 90: | ||
| - | ====== Summary ====== | ||
| - | 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. | + | === More Examples === |
| - | 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). There are 3 AVP levels: " | ||
| - | If the level is no specified, SER will search for the given AVP in order, through the 3 levels. | ||
| - | |||
| - | ====== 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 " | 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 " | ||
| Line 113: | Line 118: | ||
| Note that the global AVP list/track does not have any levels/ | 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) | ||
