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.
- AVP lifetime dialog
- 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