[Devel] Re: [Users] Call-specific AVP DBS storage for OpenSER

[Bogdan-Andrei Iancu]

Hi Joachim,

Joachim Fabini wrote:

>>>The unique ID is the first requirement, so far everything OK.
>>>      
>>>
>>there is this feature - you can load or store an AVP based on uid 
>>instead of user/domain.
>>    
>>
>
>Yes, we're using this feature and it is imho currently 
>the only way how OpenSER users can associate a local 
>constant string name (visibility restricted to transaction) 
>with a variable value like a header field value or a 
>combination of several header field values. 
>
>We'd like to be able to write this value to the database
>using a dynamic name - typically the call-id or a combination
>of the fields that identify the SIP dialog.
>
>  
>
>>I guess the problem is that in script you have only static 
>>avp name and  you need dynamic name, right?
>>    
>>
>
>Absolutely correct, this is our problem.
>I do not see any other way how to store and retrieve data
>based on SIP message content. 
>
>  
>
>>>The global AVP seems interesting (e.g. for storing Registration-
>>>lifetime AVPs), I do not see the immediate use for script-scoped
>>>variables but might miss something.
>>> 
>>>
>>>      
>>>
>>per script AVP may be used as temporary AVPs to perform some script 
>>processing.
>>    
>>
>
>What is the difference when compared to the current per-
>transaction AVPs? Probably performance I guess...
>
>
>  
>
rights - you get rid of synchronization problems (a transaction may be 
processed from several process in parallel) and you have some mem. 
efficiency (the AVP with a temporary purpose will not stay into the 
transaction)

per script AVP will exists as long as the script is executed for a 
message. once the execution ended, the AVP will be automatically 
removed. they will be visible only in that script instance.

>>>1. AVP lifetime dialog
>>>2. AVP lifetime registration (or per-contact, or global 
>>>                             scope with ability to use
>>>                             call variables as name)
>>> 
>>>
>>>      
>>>
>>ok - so having dynamic AVP names will be a first step....sounds 
>>reasonable and useful.
>>    
>>
>
>For us it is extremly useful, we can not complete our
>tasks without.
>Btw, can your last statement can be taken as a feature 
>announcement? :))))
>  
>

take it like:  it will be done, but no timeframe is promised ;)

regards,
bogdan