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

[Bogdan-Andrei Iancu]

Hi Joachim,

Joachim Fabini wrote:

>Hi Bogdan, 
>
>  
>
>>First we have to make a clear distinction between whom the 
>>AVP belong to (an identification in order to find it 0 
>>this is more an abstract aspect) and where the AVP is kept:
>>    
>>
>
>  
>
>>    - identification: there are currently two ways of 
>>identifying an avp 
>>- either as belonging to a user (user and domain), either via an uid 
>>(unique ID). What is the meaning of the uid, it's a matter of 
>>interpretation for the user - it may be a domain ID, a dialog ID 
>>...whatever... I thing this identification mechanism gives 
>>full liberty. 
>>Actually identifying ans AVP based on user at domain is a 
>>special case of a UID, where the UID is the a sip uri (this 
>>just an simplification for one of the most used case).
>>    
>>
>
>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.

>  
>
>>    - where the AVP id kept - currently they are kept into 
>>transactions. 
>>So they are accessible only their transaction is currently is 
>>progress and their lifetime is the same as the transaction's 
>>one.
>>    
>>
>
>I see. Unfortunately, there are many cases when it is required
>to have AVPs available for the duration of a dialog or, even 
>more severe, for the duration of a user registration.
>
>The only way how we can store and retrieve this information 
>right now is to store the corresponding AVPs into the DBS 
>table.
>And here is the REAL problem: We can not use call-dependent
>data (e.g., the call-id) as a NAME to store and retrieve 
>data. I.e., with the current avp_db_load and avp_db_store
>interfaces we are not able to retrieve call-dependent information 
>from the DBS.
>  
>
I guess the problem is that in script you have only static avp name and 
you need dynamic name, right?

>  
>
>>Now...about improvements.....For identifications....I would say it 
>>covers all cases..no idea what can be added - any suggestions 
>>are welcome.
>>    
>>
>
>You're right, as long as the AVP is required only during the 
>transaction. 
>
>  
>
>>regarding the AVP location..this is a different story - I was 
>>thinkings about adding new support: AVP per script (the AVP 
>>belong to the script - kind of script variables and may be used 
>>for temporary ops) 
>>and global AVP ( present in all the time, in all places - no 
>>restrictions; may be used to control the overall behaviour of 
>>the proxy).
>>    
>>
>
>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.

>  
>
>>And maybe 
>>(again...maybe) in the future AVP per dialog (they belong to 
>>a dialog).
>>    
>>
>
>THIS is exactly what can solve our problem. Our call-id-based 
>name for the persistently-stored AVP is just a work-around for 
>not having dialog-scoped AVPs available.
>
>So, thinking about a short-term solution for globally-scoped 
>AVPs one question: is there a specific reason why the AVP module 
>disallows/does not implement the use of transaction-specific
>AVP _VALUES_ as key/name of the database-stored AVP?
>Like written in my initial mail, I'd like to be able to do
>something like: 
>
>avp_db_store("s:myTmpHeaderName","s:myTmpHeaderValue");
>or
>avp_db_store("$hdr(call-id)","s:myTmpHeaderValue");
>
>Afai understand your writing, the AVP concept allows 
>any unique identifier to be used as name for database-
>stored AVPs. 
>I'm considering here just avp_db_load and avp_db_store!
>Is there any specific reason why the above-mentioned
>usage for AVP names is not implemented?
>
>To summarize: Our extensions and our use of OpenSER might 
>be slightly proprietary and different from what other users
>do, but we realized the need to have AVPs at other scope 
>than transaction, too.
>Specifically, the following lifetimes are currently needed
>for our AVPs (I guess, there are other developers, too, 
>that will come into the same situation):
>
>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.

>  
>
>>Hope I manage to bring some light ;)
>>    
>>
>
>Definitely, but it raised again some new questions.
>  
>
At least we have some progress ;)

regards,
bogdan

>Thanks again for your help,
>regards
>--Joachim
>
>  
>