sr-users February 2019

sr-users@lists.kamailio.org

78 participants
99 discussions

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

Using the avp [*] index with jansson module functions
by Enrico Bandiera 26 Feb '19

26 Feb '19

Hello, I would like to use the [*] index for the avps (to overwrite instead of adding to the stack) when passing the variable to jansson module functions. When trying to do so I get this error: 9(35) ERROR: jansson [jansson_funcs.c:219]: janssonmod_set(): result has json error at line 1: end of file expected near ',' I suppose this is unsupported but maybe I'm doing something wrong, any suggestions? Thanks, Enrico.

1 0

How can I put updated sdp body to message in kemi
by Yuriy Gorlichenko 26 Feb '19

26 Feb '19

Hi. On the original config to set body with New data I used set_body() function, exported from sdpops module. But for kamailio 5.1 I can't find something same in case of using kemi Is There is some additional way to do this?

2 2

bad transport for sips uri?
by David Cunningham 26 Feb '19

26 Feb '19

Hello all, We're having an issue with Kamailio not processing an ACK and hope someone can help. A PCAP shows that Kamailio is receiving the ACK, and we believe these log messages are directly related to it: Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: tm [ut.h:279]: uri2dst2(): ERROR: uri2dst: bad transport for sips uri: 1 Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: tm [t_fwd.c:1777]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: sl [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used: Unresolvable destination (478/SL) The ACK is as follows. It's from telephone 111111 which is using TLS, which Kamailio listens for on port 5061. Does anyone know which URI has the bad transport as per the error above? Might it be the From URI "sips:111111@es8.example.com" because it doesn't specify port 5061? Thank you in advance. Session Initiation Protocol (ACK) Request-Line: ACK sips:105@70.42.xx.xx:5070 SIP/2.0 Message Header Via: SIP/2.0/TLS 50.78.yy.yy:5061;branch=z9hG4bK741961203 Route: <sips:70.42.xx.xx:5061;transport=tls;r2=on;lr=on> Route: <sips:70.42.xx.xx;r2=on;lr=on> From: ES8 Test 102 <sips:111111@es8.example.com >;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b To: <sips:105@es8.example.com:5061>;tag=as7a72b209 Call-ID: 222222(a)50.78.yy.yy CSeq: 94679 ACK Contact: <sips:111111@50.78.yy.yy:5061;transport=tls> Max-Forwards: 70 User-Agent: ewb2bua/15.3.0 Content-Length: 0 -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

3 8

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users February 2019