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
>
>
>