February 2019 - sr-users

Kamailio behind NAT or With Public IP - Which one is highly recommended
by Pintu Lohar 28 Feb '19

28 Feb '19

Hi Everyone, Which one among the below option is highly recommended for setting up Kamailio (for production) 1. Kamailio behind NAT *or* 2. Setting up Kamailio using public IP? are there any disadvantages if we setup Kamailio behind NAT and use advertise option in listen parameters? We have tested both the options, and both the options work great for us( a. Kamailio behind NAT with advertising in listen parameters b.Kamailio setup with public IP). So wondering which one is best and highly recommended? Some extra info : 1. We use TLS 2. Using coturn for media Thanks Pintu

7 11

Problem with ghost dialogs
by Cyrille Demaret 28 Feb '19

28 Feb '19

Hi, I'm running Kamailio 5.1.4 and I have some problem with some random dialogs sometimes staying in early state and never ends until I restart Kamailio. According to the init_ts, this dialog is there since 11/01/2019. * Do you have an idea how I can diagnose this problem? * Is there a way to kill these dialogs? I have tried with "dlg.end_dlg" but It seems it's not possible to kill dialogs in early states. { h_entry: 3382 h_id: 4069 call-id: d6e6de79-7d55-486f-889f-01b05c003411 from_uri: sip:0037xxxxxxxxxxx@mydomain.com to_uri: sip:1234@mydomain.com state: 2 start_ts: 0 init_ts: 1547195739 timeout: 0 lifetime: 43200 dflags: 1536 sflags: 0 iflags: 0 caller: { tag: a909d6fa-cee9-44ac-ad76-3697fcd5cb0e contact: sip:asterisk@192.168.102.20:5080;alias=192.168.102.20~5080~1 cseq: 7362 route_set: socket: udp:192.168.102.10:5060 } callee: { tag: contact: cseq: route_set: socket: } profiles: { { caller: sip:0037xxxxxxxxxxx@mydomain.com } { callee: sip:1234@mydomain.com } } variables: { } } Thank you for your help. Best regards, Cyrille

4 7

Dispatcher problem $avp(dsattrs) is null
by jaflong jaflong 28 Feb '19

28 Feb '19

I am doing a ds_select_dst call. I think dispatcher did run because $du gets updated The problem is $(avp(dsattrs)) value is null. Any ideas why?

2 2

Masking Contact Header
by Duarte Rocha 28 Feb '19

28 Feb '19

Greetings, Is there an automated way of masking\encoding\encrypting the Contact header once it goes through a Kamailio proxy and have it restored? I'm using uac_replace_from() and uac_replace_to() for changing these values and having them restored automatically. Is there any tool like this for Contact Header? Cheers

6 9

Local Route blocks
by Grant Bagdasarian 28 Feb '19

28 Feb '19

Hi, I noticed some module functions mention "LOCAL_ROUTE", like the Domain module (http://www.kamailio.org/docs/modules/5.2.x/modules/domain.html#domain.f.loo…) I couldn't find anything related to the LOCAL_ROUTE in the docs. What are these used for and how are these declared and used? Regards, Grant CM.com

2 2

double_rr issues
by Roman Dissauer 28 Feb '19

28 Feb '19

I’m experiencing issues with kamailio 5.1 in multihomed config: two machines, latest debian stretch, latest kamailio 5.1, exactly same config (verified with diff) both machines have an internal and an external network interface. Only thing different is that they are in different datacenters. on one machine everything works perfect, on outgoning calls rr parameters are added perfectly right: Record-Route: <sip:yy.yy.yy.yy;transport=tcp;r2=on;lr;nat=yes> Record-Route: <sip:xx.xx.xx.xx;transport=tcp;r2=on;lr;nat=yes> where yy.yy.yy.yy is the external ip and xx.xx.xx.xx is the internal IP on the other machine I only get: Record-Route: <sip:xx.xx.xx.xx;transport=tcp;lr;nat=yes> even if I set enable_double_rr to 2 I get: Record-Route: <sip:xx.xx.xx.xx;transport=tcp;r2=on;lr;nat=yes> Record-Route: <sip:xx.xx.xx.xx;transport=tcp;r2=on;lr;nat=yes> I already checked with traceroute that the routing to the destination IP Adresses are going through the external interface. maybe someone has a hint for me. Thank you all in advance! Roman

3 3

TLS reload
by Patrick Wakano 27 Feb '19

27 Feb '19

Hi list, I've seen the TLS documentation ( https://www.kamailio.org/docs/modules/5.2.x/modules/tls.html#tls.known_limi…) where it states that TLS specific config reloading is not safe, so for now better don't use it, especially under heavy traffic. This note is there since version 3.0 and in 2013 there was some discussion about it but wthout anything conclusive.... What I would like to know if this is still the case. Is anyone running the TLS reload for certificate renovation for example, or is it better to restart Kamailio? Thanks, Kind regards, Patrick Wakano

4 5

SQlite in memory
by Duarte Rocha 27 Feb '19

27 Feb '19

Greetings, I'm trying to use SQlite as my engine in order to improve performance. I would like to have my Database stored in memory for faster access. I see that Kamailio can open the SQlite database as Read-Only, but i can't find a way to open it in memory. Is this possible using Kamailio? What's the best way to do this? Best Regards, Duarte Rocha

4 11

Dispatcher with parameter use_default=1
by Denys Pozniak 27 Feb '19

27 Feb '19

Hello! I use dispatcher with algorithm=1 (hashing over from URI) with module parameter use_default=1. So I am expecting that last string in dispatcher.list for specific set will be the "last hope" for call routing. dispatcher.list .. 4 sip:10.6.3.122:5060 4 sip:10.6.3.1:5060 4 sip:10.6.3.2:5060 4 sip:10.6.3.3:5060 4 sip:10.6.3.4:5060 4 sip:10.6.3.5:5060 But as I see from logs dispatcher module takes first string as the "last hope": xlog("L_WARN", "TEST-- $(avp(AVP_DST)[0]) $(avp(AVP_DST)[1]) $(avp(AVP_DST)[2]) $(avp(AVP_DST)[3]) $(avp(AVP_DST)[4]) $(avp(AVP_DST)[5]) $(avp(AVP_DST)[6]) \n"); Feb 26 16:11:39 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: <script>: TEST-- sip:10.6.3.4:5060 sip:10.6.3.3:5060 sip:10.6.3.2:5060 sip: 10.6.3.1:5060 sip:10.6.3.5:5060 sip:10.6.3.122:5060 <null> Feb 26 16:11:58 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: <script>: TEST-- sip:10.6.3.3:5060 sip:10.6.3.2:5060 sip:10.6.3.1:5060 sip: 10.6.3.5:5060 sip:10.6.3.4:5060 sip:10.6.3.122:5060 <null> Feb 26 16:11:59 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: <script>: TEST-- sip:10.6.3.2:5060 sip:10.6.3.1:5060 sip:10.6.3.5:5060 sip: 10.6.3.4:5060 sip:10.6.3.3:5060 sip:10.6.3.122:5060 <null> Feb 26 16:12:08 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: <script>: TEST-- sip:10.6.3.1:5060 sip:10.6.3.5:5060 sip:10.6.3.4:5060 sip: 10.6.3.3:5060 sip:10.6.3.2:5060 sip:10.6.3.122:5060 <null> According to the module explanation it should be "the last address in destination set is used as a final option to send the request to" version: kamailio 4.4.2 (x86_64/linux) 892ad6 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: 892ad6 compiled on 12:58:38 Aug 28 2017 with gcc 4.8.5 -- BR, Denys Pozniak

2 4

auth_ephemeral too noisy
by Juha Heinanen 27 Feb '19

27 Feb '19

I did some tests with auth_ephemeral. When timestamp has expired, I get to syslog Feb 23 03:53:05 char /usr/bin/sip-proxy[31758]: WARNING: auth_ephemeral [authorize.c:205]: autheph_verify_timestamp(): username has expired Feb 23 03:53:05 char /usr/bin/sip-proxy[31758]: ERROR: auth_ephemeral [authorize.c:260]: digest_authenticate(): invalid timestamp in username In my opinion, the WARNING is enough and the ERROR message should be removed. ERROR is when an error happens. There is no error here, just an expired timestamp. -- Juha

2 2