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@voice-system.ro wrote:
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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users