according to s domain module documentation
In addition to that domain-level attributes, if any, will be available as either $fd.<name> or $td.<name>.
i tried like this:
if (lookup_domain("$fd", "$var(from_uri_domain)")) {
xlog("L_INFO", "Got lcr_id <$fd.lcr_id>\n");
but got error at startup:
Aug 26 10:39:10 localhost /usr/sbin/sip-router[9075]: ERROR: <core> [pvapi.c:500]: error searching pvar "fd.lcr_id"
why?
-- juha
Hello,
On 26.08.2009 10:42 Uhr, Juha Heinanen wrote:
according to s domain module documentation
In addition to that domain-level attributes, if any, will be available as either $fd.<name> or $td.<name>.
i tried like this:
if (lookup_domain("$fd", "$var(from_uri_domain)")) {
xlog("L_INFO", "Got lcr_id <$fd.lcr_id>\n");
but got error at startup:
Aug 26 10:39:10 localhost /usr/sbin/sip-router[9075]: ERROR: <core> [pvapi.c:500]: error searching pvar "fd.lcr_id"
why?
xlog from modules_k supports only Kamailio PVs, try:
xlog("L_INFO", "Got lcr_id <$avp(fd.lcr_id)>\n");
Should be the same - avps in K are referenced with $avp(name).
Probably after sl, xlog modules should me integrated to support all available styles of cfg variables.
Cheers, Daniel
Daniel-Constantin Mierla writes:
xlog from modules_k supports only Kamailio PVs, try:
xlog("L_INFO", "Got lcr_id <$avp(fd.lcr_id)>\n");
that worked.
Probably after sl, xlog modules should me integrated to support all available styles of cfg variables.
yes, it would be a good idea in order to avoid this kind of confusion.
-- juha