Kamailio TLS connection lifetime

 TL;DR;

Pay attention to 

modparam("tls", "connection_timeout", 600) # Default

 A bit longer.

Usually, you don't need to use SIP OPTIONS ping over TCP connections. Because you have TCP keepalives built-in. And the default registration time is 1h, which is also generous in the case of TCP (TLS). But the default connection timeout, found in mod_tls parameters is only 10 minutes. So, if your registration time is lower than 10 minutes and there are no calls on this phone (which is ok as well), you'll have a TLS connection drop every 10 minutes with a corresponding indication on the phone itself.

 Again, defaults might not be 100% compatible.

Kamailio - change script behavoir at a realtime

For the moment, it's impossible to apply changes to Kamailio config file (not using KEMI, for sure) without restarting Kamailio.

Here is a small trick that you can use to enable/disable some parts of a script in a realtime, that is very useful for debugging. Not the whole script, but something.

kamailio.cfg

#!KAMAILIO

# REALTIME changable parameters
...
# Enable or disable test numbers function. Done as realtime not to use group (SQL) functions every call
realtime.test_destination=0 

...

 route[TEST_DESTINATION_DETECT] {
    if ($(sel(cfg_get.realtime.test_destination){s.int}) != 1) {
        return;
    }

    if (is_user_in("To", "test-dst-to")) {
        xlog("$var(debug_level)", "[TEST_DESTINATION_DETECT] $rU as a test destination TO number\n");

        setflag(FLT_TESTNUMBER);
        return;
    }

    if (is_user_in("From", "test-dst-from")) {
        xlog("$var(debug_level)", "[TEST_DESTINATION_DETECT] $fU as a test destination FROM number\n");

        setflag(FLT_TESTNUMBER);
    }
}

In this example the whole route execution is based on a value of realtime.test_destination parameter. By default it's 0 (means false), but can be easily changed with 

# kamcmd cfg.set realtime test_destination 1

And no need to restart script. Small, but useful trick for me. Only thing to keep in mind, that unlike KEMI this trick is not taking into accout transaction states, etc. Just change and that's it.

P.S:  Got some feedback, that $(set(cfg_get...)) might lead to a crashes on a high load. Htable might be a good alternative for this as well.

Asterisk PJSIP endpoint identification by To number

Recently got an interesting task.

For calls, that are made to a specific number, apply DTMF transcoding towards caller side. Means when someone (an automated system, actually) answers on this specific number, it starts send DTMF codes towards caller. But the main issue as, that callers, that are calling to this number accept DTMF only in inband mode, despite that looking on SIP traces they should accept usual RFC4733.

DTMF transcoding (in PJSIP) is handled by Asterisk via endpoint parameters. So, all calls ONLY to this number need to be put into a specific endpoint. Gladly, it's not so hard to achieve, but the documentation is lacking examples. So, here is the one:

pjsip.conf

[global]
...
# Depending on your configuration you might need to adjust the order
endpoint_identifier_order=ip,username,header,anonymous

# Actual endpoint we need call to be placed FROM
[test_endpoint]
type=endpoint
...
dtmf_mode=inband
identify_by=header

[test_endpoint]
type=identify
endpoint=test_endpoint
match_header=To:/123456789/

Now all calls made to a number, that consists sequence 123456789 will be made from test_endpoint and all DTMF towards this endpoint will be transcoded to inband.