20 Jan
2006
20 Jan
'06
12:29 a.m.
Hi Joachim,
Joachim Fabini wrote:
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.
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.
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
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.
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.
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.