[Users] AVPops question

[Joachim Fabini]

> I I got it right know, you need the following:
> 
> avp_printf("s:$hdr(call-id)", "$hdr(call-id)-$Ts");

Absolutely correct. :)

> The AVP ist string based, and the name of the AVP is the 
> Call-id. Guess AVPOPs need to be extended for this.

I'm afraid, too, that this does not work right now.
Even if the problem above can be solved. To become even 
more specific: For avp_printf it is not absolutely 
mandatory, as one could use a temporary. 
Where we _really_ need this feature is for avp_load_db
and avp_store_db. 
 
> What is the main purpose of this new AVP? Adding as header or 
> storing in the database, so that another proxy can access it?

Storing it for access by another proxy. 
It's imho a _conceptual_ extension to AVPs. Until now, 
AVPs names are static. We require a finer granularity - 
at call level. 
 
> avp_pushto("$Myheader","$hdr(call-id)");
> But this would just duplicate the Callid header.

Pushing the value into a header works already:
avp_printf("s:tmp","value=$hdr(call-id)-$Ts");
avp_pushto("$P-Header","s:tmp");

# What does _NOT_ work is the persistent storing 
# of this AVP into the database
avp_db_store("$hdr(call-id)","s:myTmpHeaderValue");


The most straight-forward solution is imho to allow 
AVP _values_ to be assigned to AVP names in any AVP
construct (Probably a "v:tmp-icid" could be used to
differentiate between name-usage (s:) and value-usage 
(v:).

i.e. 
avp_printf("s:myTmpHeaderValue", "$hdr(call-id)-$Ts");
avp_printf("s:myTmpHeaderName", "$from/username$hdr(call-id)");
# This already works
avp_pushto("P-Header", "s:myTmpHeaderValue");
# This does not currently not work
avp_db_store("s:myTmpHeaderName","s:myTmpHeaderValue");
avp_db_store("$hdr(call-id)","s:myTmpHeaderValue");

# This load obviously does also not work - it is 
# intended to be used by a remote proxy who processes
# the request or a reply to this request in order to
# remove and/or add the corresponding header.
avp_db_load("$hdr(call-id)","s:myTmpHeaderValue");

And, (seems like this is my Santa Claus wish list... ;) 
we must be able to store these values in another database 
like the one that we use (any proxy has its local database 
because of performance considerations, for this mechanism
we need a common, centralized one!).
In our case we have at least two proxies that must 
access the common database (beside their local one).

So I see two extensions that are required in order to fix
our problem:
1. db_store and db_load to support AVP values as name
2. Access to multiple databases

--Joachim