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 <[EMAIL PROTECTED]> 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.
>
> >>>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? :))))
> >
> >
>
> 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
>
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
