[Kamailio-Users] [sr-dev] rfc: xavp - extended avp

[Daniel-Constantin Mierla]

On 28.07.2009 13:51 Uhr, Martin Hoffmann wrote:
> Daniel-Constantin Mierla wrote:
>   
>> - possibility to store more data types - AVP allow string and integer  
>> data types. More can be handled by XAVP, including a generic data type  
>> where you can build your own structure and store it in the list. This is  
>> good for example to store custom structures for transaction lifetine --  
>> right now dialog module needs to store reference to dialog structure.  
>> Optimizations can be done for any case of serial forking -- uri, dst  
>> uri, q, etc can be stored in a structure without a need to parse and  
>> build it from an encoded value stored in one or many avps
>>     
>
> You could generalize this into only using the generic data value and
> wrap the other types into these. This requires makeing these generic
> data values in the script language somehow. For all this, you will need
> a somewhat more elaborate interface to the type than a free function.
>   

it is an option, but I wanted to have it simple for common data types in 
the same time to allow dealing with more complex structures.
This can be implemented for generic data, so it adds kind of: fromStr 
and toStr functions, making possible to set/get values from config.

> I suppose you could define a struct much like the module struct that
> contains a bunch of pointers to various functions for various things. An
> instance of this type then consists of a pair from the pointer to the
> type struct (which incidentally is uniquely identifying the type and a
> pointer into shared memory pointing to the value).
>
>   
>> - possibility to group XAVPs inside another XAVP - practically is  
>> building lists of XAVPs.
>>     
>
> If you wrap this into a generic type, you can have various types for
> lists and maps and whatnot (although this should really do). There are
> some questions around references vs. copies here, so this will probably
> go off into reference counting and stuff.
>   
with current implementation, this is a matter of what free function does 
for generic data type. For the common types, free is done automatically, 
being easier for developers.
> Although, neatly enough, this can probably made in such a way that XAVPs
> get auto-magically destroyed when their parent object (the transaction,
> dialog, etc.) is being destroyed.
>   
Now they are attached to transaction and auto-destroyed when the 
transaction terminates -- same like with AVP list. The API allow to work 
with custom xavp lists, therefore developer can attach new lists to 
different contexts -- will need to extend the interface to config, as 
the PV export is using the default list bound to sip message/transaction.

Thanks,
Daniel

-- 
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/