[SR-Dev] AVPs

Daniel-Constantin Mierla miconda at gmail.com
Thu Dec 11 23:25:14 CET 2008


I think we need to decide about AVPs. Although not deeply investigated, 
ser seems to have couple of AVPs lists. In kamailio/openser it is one list.

Can a ser developer describe a bit the AVP implementation as it is now 

In openser/kamailio we have more or less same architecture as for ser 
0.9.6 with couple extensions, but I will detail here so we can have full 
- avps are kept in shared memory
- they are bound to each sip message and moved to transaction if that 
message create a transaction
- avp can have two types of names
    - integer id, referred as $avp(i:number)
    - string id, referred as $avp(s:string)
- there can be aliases for avp names, defined as "alias=[is]:id", so the 
script writer can use $avp(alias)
- a value of an avp can be either integer or string
- not related to avp core part, but important to mention here -- tm, 
controlled by a parameter, can make the avps from transaction (request) 
available to onreply_route.

Also, just to have in mind, for the future we got into discussion:
- moving from linked list to a structure that allows faster search 
(e.g., hash table) as number of used avps can be big some times
- adding support for structure-like values (the value to be another list 
of (name,value) pairs). A typical use case is serial forking, where one 
needs to store data in avps. If for one destination an avp is missing, 
things get screwed. Example:

$avp(uri) = {A, B, C}
$avp(RPID) = {X, not needed, Y}

Internally will look like:
$avp(uri) = {A, B, C}
$avp(RPID) = {X, Y}

So actually, Y will be used for destination B. Workarounds are possible, 
or course, but maybe we can do it nicer. so it will be like:
$avp(dst) = {{u=A,r=Y}, {u=B},{u=C,r=Y}}

A possibility to specify the access is $avp(d:dst=>u)

Finally, as pointed in another email, it is about making possible to 
hold "value null" (a mark/flag) and differentiate that from "undefined" 
(not existing).


Daniel-Constantin Mierla

More information about the sr-dev mailing list