That's weird, because I'm using exactly the same way of phone number substitution and this works to me. Ok, I'll investigate this problem as soon as possible. Thanks for report!


2014-07-16 14:39 GMT+04:00 Örn Arnarson <orn@arnarson.net>:
If you mean the python code, then here's an example:

divheader = "Diversion: <sip:%s@%s>;reason=unconditional\r\n" % (1234567, "10.11.12.13")
msg.call_function("insert_hf", divheader, "Diversion")

Regards,
Örn



On Wed, Jul 16, 2014 at 10:32 AM, Konstantin M. <evilzluk@gmail.com> wrote:
Hi,
Could you please tell me the chunk of code that illustrates this problem?
Thanks!



2014-07-16 14:10 GMT+04:00 Örn Arnarson <orn@arnarson.net>:
Resent after signing up, due to original message being held for review for a week:

Kamailio terminates (Signal 15) after app_python crashes (signal 7) when using call_function("append_hf") with more than 1 parameter.

Jul  9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: ALERT: <core> [main.c:788]: handle_sigs(): child process 2707 exited by a signal 7
Jul  9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: ALERT: <core> [main.c:791]: handle_sigs(): core was generated
Jul  9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: INFO: <core> [main.c:803]: handle_sigs(): INFO: terminating due to SIGCHLD
Jul  9 13:53:18 vcr01 /usr/sbin/kamailio[2706]: INFO: <core> [main.c:854]: sig_usr(): INFO: signal 15 received

Actually, calling "remove_hf" with call_function seems to do exactly the same thing, though that is just with 1 param.

My problem is that I need to manipulate the Diversion headers (or rather, add a new Diversion header in the correct place (i.e. above the other Diversion header), as append_hf will always add it at the bottom.)

I've identified what part of the code makes it crash (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio:
    if (fexport->fixup != NULL) {
        if (i >= 3) {
            rval = fexport->fixup(&(act->val[3].u.data), 2);
            if (rval < 0) {
                PyErr_SetString(PyExc_RuntimeError, "Error in fixup (2)");
                Py_INCREF(Py_None);
                return Py_None;
            }
            act->val[3].type = MODFIXUP_ST;
        }
        if (i >= 2) {
            rval = fexport->fixup(&(act->val[2].u.data), 1);
            if (rval < 0) {
                PyErr_SetString(PyExc_RuntimeError, "Error in fixup (1)");
                Py_INCREF(Py_None);
                return Py_None;
            }
            act->val[2].type = MODFIXUP_ST;
        }
        if (i == 1) {
            rval = fexport->fixup(0, 0);
            if (rval < 0) {
                PyErr_SetString(PyExc_RuntimeError, "Error in fixup (0)");
                Py_INCREF(Py_None);
                return Py_None;
            }
        }
    }

I have very little experience with programming in C, and even less debugging with gdb or something similar, but from comparing this code with the way the Perl module does this, I couldn't see any obvious problems. I'm hoping someone with familiarity with the kamailio functions, such as fixup, might be able to identify the problem.

Judging from the exit code of app_python, my (uninformed) guess would be that there's an attempt to access or manipulate something in an out-of-scope memory address.

Any suggestions would be greatly appreciated. I've written a quite large routing function in python and I'd like to avoid rewriting it in a different scripting language if possible.

The kamailio version I'm running is 4.0.4

Regards,
Örn

_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev