14 Dec
2008
14 Dec
'08
7:59 a.m.
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