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