Jan Janak writes:
A long time ago we started using AVPs to store all kinds of configuration information. We needed some sort of general configuration mechanism because real-world scripts were getting too complex and at that time the AVPs were readily available.
jan,
i have been doing in kamailio exactly what you describe, but using radius.
a function that loads caller's attributes does not do anything to the avp name (integer) in db, but a function that loads callee's attributes adds a constant (say 100) to the name. in cfg file, i then define m4 macros, like this:
define(`CALLER_LANGUAGE_AVP', i:102) define(`CALLEE_LANGUAGE_AVP', i:202)
i too have domain level avps in a separate table and when avp's of a user (caller or callee) are loaded, domain level table is access first, then user level table. this means that reply attributes returned from radius are loaded into k avps in the same order. if there is only a domain level attribute, that gets used, but if there are both, the user level one that was loaded later overrides the domain one.
in addition to user and domain level, i have uri level, i.e., if an uri of a user has uri level attribute, it overrides the corresponding user level avp value.
all this has worked fine for a long time and for this purpose, i don't need any additions whatsoever to k's avp implementation. for other purposes (as daniel mentioned), it would be nice if avp value could be a structure.
-- juha