Hi Bogdan,
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...
- 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? :))))
At least we have some progress ;)
Much more than I expected.
Thanks, best regards --Joachim