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 ofidentifying 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@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.
- where the AVP id kept - currently they are kept intotransactions. 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.
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.
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)
Hope I manage to bring some light ;)
Definitely, but it raised again some new questions.
Thanks again for your help, regards --Joachim