23 Jan
2006
23 Jan
'06
6:59 p.m.
Hi,
Regarding Joachim's first post...
# This is the AVP name that is required to retrieve
# our specific, call-dependent AVP value from the
# database whenever a message that belongs to this
# call passes our OpenSER proxy.
avp_printf("s:myTmpHeaderName", "$from/username$hdr(call-id)");
# This is the value we'd like to store. Could be also
# only "$Ts", i.e., we can _not_ rely on regular
# expression search for later retrieving the AVP
# from the DBS based on its value.
avp_printf("s:myTmpHeaderValue", "$hdr(call-id)-$Ts");
# This storing of the call-dependent info in DBS does
# currently not work. OpenSER complains at start-up
# about the variable AVP name/key on both of the
# following lines. The former variant seems much more
# flexible to me than the latter one.
avp_db_store("s:myTmpHeaderName","s:myTmpHeaderValue");
avp_db_store("$hdr(call-id)","s:myTmpHeaderValue");
# This load obviously does also not work.
avp_db_load("$hdr(call-id)","s:myTmpHeaderValue");
You could do:
modparam("avpops", "avp_aliases",
"myTmpHeaderAlias=s:myTmpHeaderName")
avp_db_store("$myTmpHeaderAlias", "s:myTmpHeaderValue");
I tried something similar and it worked.
JF
On 1/19/06, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
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
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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.