Description

In a project, we implemented parts of our routing logic with javascript. We don't use KEMI at the moment. So most of the routing logic still happens in kamailio.cfg. We have implemented the t_relay part in JS, and after that we want to stop the execution of the routing logic. In kamailio config we would do that with return or exit. In our implementation we used KSR.x.exit(), but the execution of the kamailio config continues.

This is how our kamailio config section looks like:

                      # No Accounting special calls
                        if ( $fU =~ "^1234567$") {
                                resetflag(doAccounting);
                        }

                        if (!jsdt_run("routeSomeCallsHere")) {
                                xlog("L_ERR", "JS Call of routeSomeCallsHere route failed.\n");
                        }

                        # routing decision
                        route(makeRoutingDecision);

This is what the JS does:

function relayPacket() {
    KSR.dbg("Sending out packet " + KSR.pv.get("$rm") + " statefully.\n");
    if (KSR.tm.t_relay() < 0) {
        KSR.err("statefulForward: error to <" + KSR.pv.get("$tu") + "> from <" + KSR.pv.get("$fu") + ">\n");
        if (KSR.is_method_in("IA")) {
            KSR.rtpengine.rtpengine_delete0();
        }
        KSR.sl.sl_reply_error();
        KSR.x.exit();
        return false;
    }
    KSR.info("DONE relaying!!!");
    KSR.x.exit();
    return true;
};

Looks to us as if KSR.x.exit() does not work in our scenario. Did we miss something? In the end, Kamailio sends out two INVITEs, one from JS and one from the old routing logic.

Additional Information

• Kamailio Version - output of kamailio -v

version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled with gcc 4.7.2

• Operating System:

Debian Wheezy

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.