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