Daniel-Constantin Mierla writes:

What version are you using? Is it happening to get the right value from time to time?

this is with a few days old trunk:

version: sip-proxy 3.4.0-dev3 (x86_64/linux)

i have seen it sometimes to set attrs pvar correctly, but most times not.

If you set higher debug mode, is it printing the message that a rule was matched?

see below.

-- juha

Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: INFO: Translating <+35892345670> based on dpid 4 Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dialplan.c:240]: integer value Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dialplan.c:261]: searching 15 Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dialplan.c:348]: input is +35892345670 Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:341]: regex operator testing Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:341]: regex operator testing Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:341]: regex operator testing Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:386]: found a matching rule 0x7f7d72275fa8: pr 10, match_exp ^+358 Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:393]: the rule's attrs are fi Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:404]: the copied attributes are: fi Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dp_repl.c:151]: null replacement Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: DEBUG: dialplan [dialplan.c:357]: input +35892345670 with dpid 4 => output Aug 31 20:21:56 wheezy2 /usr/sbin/sip-proxy[7560]: INFO: Found attrs <<null>>

Daniel-Constantin Mierla writes:

Can you set $var(plan) to a static string value before dp_translate() just to see if the value is updated in the function?

i now have:

xlog("L_INFO", "Translating <$var(calling_number)> based on dpid 4\n"); $var(plan) = "something"; if (dp_translate("4", "$var(calling_number)")) { xlog("L_INFO", "Found attrs <$var(plan)>\n");

and get:

Aug 31 21:57:21 wheezy2 /usr/sbin/sip-proxy[9733]: INFO: Translating <+35892345670> based on dpid 4 Aug 31 21:57:21 wheezy2 /usr/sbin/sip-proxy[9733]: INFO: Found attrs <598400320>

so looks like something happens to the pvar, but not the right thing.

-- juha

other weird thing is that when i tried to add more debug output to dialplan module and compiled dialplan module separately on another host (the same one where the debian package installed on this test host has been built) and then copied it to the host (virtual machine) where these tests are done, i cannot start the proxy with the separately compiled dialplan.so. i get to syslog:

0(11244) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib/sip-proxy/modules/dialplan.so>: libkmi.so.1: cannot open shared object file: No such file or directory

when the file definitely exists:

/usr/lib/sip-proxy/modules# ls -ls dialplan.so 148 -rwxr-xr-x 1 jh jh 151353 Aug 31 22:10 dialplan.so

may be all this hassle is somehow related to trying to run my sip proxy on a Virtualbox virtual machine?

-- juha

Daniel-Constantin Mierla writes:

...

0(11244) ERROR: <core> [sr_module.c:572]: ERROR: load_module: could not open module </usr/lib/sip-proxy/modules/dialplan.so>: libkmi.so.1: cannot open shared object file: No such file or directory

when the file definitely exists:

/usr/lib/sip-proxy/modules# ls -ls dialplan.so 148 -rwxr-xr-x 1 jh jh 151353 Aug 31 22:10 dialplan.so

The complain seems to be regarding missing of libkmi, can you check that is installed as well?

yes, it is installed in libdir:

# ls -ls /usr/lib/sip-proxy/ ... 0 lrwxrwxrwx 1 root root 13 Aug 31 21:30 libkmi.so -> libkmi.so.1.0 0 lrwxrwxrwx 1 root root 13 Aug 31 21:30 libkmi.so.1 -> libkmi.so.1.0 52 -rw-r--r-- 1 root root 51673 Aug 31 21:30 libkmi.so.1.0

Do you have any possibility to test it where it compiles? You can even run from source tree, without a need to install, connecting to the database server where dialplan table is located -- just to avoid hunting ghost issues in the code.

the same problem appears also when i run proxy on the same real host where i built the debian package.

now i was able to put some LM_INFO statements in dp_update function of dialplan.c:

set_attr_pvar:

LM_INFO("trying to set pvar\n");

if(!attr_pvar) { LM_INFO("attr_pvar is null\n"); return 0; }

val.rs = *attrs; LM_INFO("setting pvar from attrs <%.*s>\n", val.rs.len, val.rs.s); if(attr_pvar->setf(msg, &attr_pvar->pvp, (int)EQ_T, &val)<0) { LM_ERR("setting attr pseudo-variable failed\n"); return -1; } if(attr_pvar->getf(msg, &attr_pvar->pvp, &res)<0) { LM_ERR("getting attr pseudo-variable failed\n"); return -1; } LM_INFO("got <%.*s>\n", res.rs.len, res.rs.s); this is what i get to syslog:

Sep 1 08:38:23 siika /usr/sbin/sip-proxy[15787]: INFO: Translating <+35892345670> based on dpid 4 Sep 1 08:38:23 siika /usr/sbin/sip-proxy[15787]: INFO: dialplan [dialplan.c:280]: entering dp_update Sep 1 08:38:23 siika /usr/sbin/sip-proxy[15787]: INFO: dialplan [dialplan.c:307]: trying to set pvar Sep 1 08:38:23 siika /usr/sbin/sip-proxy[15787]: INFO: dialplan [dialplan.c:315]: setting pvar from attrs <fi> Sep 1 08:38:23 siika /usr/sbin/sip-proxy[15787]: INFO: dialplan [dialplan.c:326]: got <-630238520>

i.e. the value i get from the pv is not the one i put there.

my next guess is that this has something to do with amd64 architecture of the host. perhaps the sizes of ints/pointers/etc are not what the code somewhere expects?

-- juha

i think i found the bug that causes incorrect setting of dp_translate attrs pvar value.

current code in dp_update function has this:

no_change = (dest->type == PVT_NONE) || (!repl->s) || (!repl->len);

if (no_change) goto set_attr_pvar;

memset(&val, 0, sizeof(pv_value_t)); val.flags = PV_VAL_STR; val.rs = *repl;

and then

set_attr_pvar:

if(!attr_pvar) return 0;

val.rs = *attrs;

if there is no change (like is the case in my failing test), val is not initialized and its type can be anything.

i'll commit fix to trunk. let me know if it looks ok, i'll pick it also to 3.3.

-- juha