sr-users October 2021

sr-users@lists.kamailio.org

65 participants
58 discussions

by Hayden Ryan

Hi all, I have Kamailio and Asterisk set up in a realtime configuration, like this: https://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb In my setup, Kamailio forwards all REGISTER requests to Asterisk, and Asterisk authenticates them. I have a single peer in sip.conf pointing towards the Kamailio server, as type=peer Each user in the Asterisk database is set to type=user, as when they are set to anything else (or blank), incoming calls from Kamailio to Asterisk display the name of the most recent extension to register. Is there something wrong with my setup here? What I am trying to do is to get MWI working. SUBSCRIBEs for MWI are forwarded to and handled by Asterisk correctly. Yet the MWI state on the handset is incorrect, as I believe it is sending the latest MWI update to the most recently registered extension. Any suggestions would be much appreciated. I assume I'm doing this the wrong way and shouldn't be forwarding any REGISTERs to Asterisk and should be handling authentication in Kamailio itself? But that seems incompatible with the realtime configuration guides I've seen. Thank you, Hayden

2 years, 6 months

Please reivew the issue about diameter_request_async

by BOEINGNG

Hello! Please review the issue I mentioned here:https://github.com/kamailio/kamailio/issues/2900 <https://github.com/kamailio/kamailio/issues/2900> Could you provide some advice to me? Regrads HANG LI

2 years, 6 months

Info: risk of failure by upgrading to MariaDB 10.3.31

by Daniel-Constantin Mierla

Hello, not strictly related to Kamailio, but I know a large number of its deployments run with MariaDB. Be aware of a (pretty high) risk of failure after upgrading MariaDB server to v10.3.31, which comes now on Debian 10 via the usual apt update+upgrade. I was hit on one the servers I upgraded recently, first one worked fine, the 2nd failed to start MariaDB service after upgrade - there is a bug report about it: * https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1823336.h… Downgrading MariaDB seems to be the right solution for now, specially if you didn't do a backup just before upgrade. Don't try other tricks without a fresh backup, data files can be damaged. If you have a fresh backup, there seems to be a solution by deleting database files to start with a clean set and then restore from backup with sql statements. FreeBSD has a similar bug report, so doesn't seem to be only Debian, could be other Linux distros as well. Even with fresh backups, plan for a longer maintenance time frame than usual. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - Online Nov 08-11, 2021 (Europe Timezone) - Nov 22-25, 2021 (America Timezone) * https://www.asipto.com/sw/kamailio-advanced-training-online/

2 years, 6 months

T_req(pv) not accessible in dialog event route in v5.5.2

by Joel Serrano

Hello, I'm in the process of updating some servers that are running Kam v5.1.4 to v5.5.2. After the upgrade I've noticed that I've lost some custom metrics that we have defined via config-script. Snippet of the relevant config: event_route[dialog:start] { # Gather metrics regarding source IP xlog("L_WARN", "[DLG] - Checking country for ($si | $T_req($si)) - START\n"); if (geoip2_match("$T_req($si)", "src")) { # Country found ... } xlog("L_WARN", "[DLG] - Checking country for ($si | $T_req($si)) - END\n"); } NOTE: xlog lines added for debugging, they normally are not there. In version 5.1.4 in the logs I see: Oct 21 15:55:47 13cn3 sbc[22606]: WARNING: <script>: [DLG] - Checking country for (A.B.C.D | 186.185.186.7) - START Oct 21 15:55:47 13cn3 sbc[22606]: WARNING: <script>: [DLG] - Checking country for (A.B.C.D | 186.185.186.7) - END The same config, on v5.5.2 is returning: Oct 21 15:57:08 sbc0504 sbc[22606]: WARNING: <script>: [DLG] - Checking country for (A.B.C.D | <null>) - START Oct 21 15:57:08 sbc0504 sbc[22606]: WARNING: <script>: [DLG] - Checking country for (A.B.C.D | <null>) - END After enabling debug logs I see: WARNING: <script>: [DLG] - Checking country for (198.1.55.124 | <null>) - START *DEBUG: tmx [t_var.c:309]: pv_get_t_var_req(): used in unsupported route block - type 64*DEBUG: geoip2 [geoip2_pv.c:488]: geoip2_update_pv(): attempt to match: <null> DEBUG: geoip2 [geoip2_pv.c:491]: geoip2_update_pv(): no match for: <null> Did something change in the tmx module that could affect $T_req(pv) being accessible in the dialog:start event_route? Any alternatives to get the source IP of the request (not the reply) in the dialog:start event_route? Let me know if you prefer that I open a ticket for this in GH. Thanks, Joel.

2 years, 6 months

"EXTERN.h: No such file or directory" error when compiling Kamailio 5.5 on Centos 7

by AL RSM

Hi, While trying to install Kamailio 5.5 on Centos 7 I am getting the following error. Perl is already installed. I verified "EXTERN.h" does not exist on the VM. # make include_modules="tm app_perl" cfg # make prefix=/ all .... .... Can't locate ExtUtils/Embed.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .). BEGIN failed--compilation aborted. Can't locate ExtUtils/Embed.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .). BEGIN failed--compilation aborted. CC (gcc) [M app_perl.so] perlfunc.o In file included from perlfunc.c:40:0: app_perl_mod.h:37:20: fatal error: EXTERN.h: No such file or directory #include <EXTERN.h> ^ compilation terminated. make[2]: *** [perlfunc.o] Error 1 make[1]: *** [modules] Error 1 make[1]: Leaving directory `/usr/src/kamailio/src' Your help would be much appreciated. Thanks, AL

2 years, 6 months

tls connections

by Richard Robson

I'm trying in vain to get a tls connection to a carrier. ~Without too much detail we are exchanging certificates and they are saying we are triggering a reset of the connection because we are requesting to chage the tcp window size. there are requiring us to have a window size of 65535. there we are sending a smaller window size. as far as I understand this should be OK. I have tried to force out linux install to set the window size to 65535 but we are still sing the smallerwindow in the tcp packet. Is there any settings in Kamailio that could force the window size? we are using Kamailio 5.4.2 Thanks in advance Richard

2 years, 6 months

Catching websocket / TCP errors

by Marrold

Hi, We're currently implementing WebRTC (SIP over a websocket) on our Kamailio proxies and we're experiencing a minor issue after a restart. We write all USRLOC entries to a shared database to implement HA. These are then loaded on a restart, which leaves us with entries with TCP connections that no longer exist. When a call attempt is made the proxy can't find the connection ID and immediately rejects the call with a "500 No error (2/SL)" - Oct 5 15:38:24 proxy-01 /sbin/kamailio[32087]: WARNING: <core> [core/msg_translator.c:2861]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found Oct 5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: <core> [core/msg_translator.c:2038]: build_req_buf_from_sip_req(): could not create Via header Oct 5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:479]: prepare_new_uac(): could not build request Oct 5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: tm [t_fwd.c:1759]: t_forward_nonack(): failure to add branches Oct 5 15:38:24 proxy-01 /sbin/kamailio[32087]: ERROR: sl [sl_funcs.c:414]: sl_reply_error(): stateless error reply used: No error (2/SL) How can we catch this error to avoid terminating the call prematurely? Or should we flush these TCP connections on start up? Thanks Matthew

2 years, 6 months

Use constants in attrs column of the dispatcher module

by Markus Bönke

Hello all, I’ve a question regarding the dispatcher module. So far we use on every server a separate database table, where the attribute column is set to the local internal or external socket like "socket=udp:192.168.1.70:5060“ or socket=udp:80.239.xxx.xxx:5060. Is there a way to use constants here like socket=udp:IPADDR_INTERN:5060 or socket=udp:IPADDR_EXTERN:5060 which are replaced when the data is loaded from the DB? Thanks and regards Markus

2 years, 6 months

Kamailio on AWS Kubernetes with NLB

by Cedric Thiebault

Hello, I'm trying to deploy Kamailio on Kubernetes (AWS EKS with Network Load Balancer) but I'm not able to register using TCP. I'm using official Docker image 5.5.0-buster. I did some tests with Docker Compose and it worked fine, but on K8S it does not :-( Here are my logs: Listening on udp: 127.0.0.1:5060 udp: 172.31.4.29:5060 udp: 172.31.0.221:5060 tcp: 127.0.0.1:5060 tcp: 172.31.4.29:5060 tcp: 172.31.0.221:5060 Aliases: tcp: ip-172-31-0-221.eu-central-1.compute.internal:5060 tcp: 172-31-4-29.kube-prometheus-stack-prometheus-node-exporter.infra-prometheus.svc.cluster.local:5060 tcp: localhost4.localdomain4:5060 tcp: localhost4:5060 tcp: localhost.localdomain:5060 tcp: localhost:5060 udp: ip-172-31-0-221.eu-central-1.compute.internal:5060 udp: 172-31-4-29.kube-prometheus-stack-kubelet.kube-system.svc.cluster.local:5060 udp: localhost4.localdomain4:5060 udp: localhost4:5060 udp: localhost.localdomain:5060 udp: localhost:5060 0(1) INFO: <core> [core/tcp_main.c:4983]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(1) INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded 0(1) INFO: rr [rr_mod.c:188]: mod_init(): outbound module not available 0(1) INFO: <core> [main.c:3030]: main(): processes (at least): 41 - shm size: 67108864 - pkg size: 8388608 0(1) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 0(1) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 0(1) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 0(1) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 0(1) INFO: <core> [core/udp_server.c:154]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 0(1) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 29(35) INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/35 31(37) INFO: ctl [io_listener.c:213]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) 35(41) INFO: <core> [core/parser/parse_fline.c:147]: parse_first_line(): method not followed by SP 35(41) ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): parse_first_line: bad message (offset: 0) 35(41) ERROR: <core> [core/parser/msg_parser.c:747]: parse_msg(): ERROR: parse_msg: message=<> 35(41) ERROR: <core> [core/receive.c:374]: receive_msg(): core parsing of SIP message failed (194.230.146.66:9055/2) And my service: apiVersion: v1 kind: Service metadata: name: kamailio-tcp annotations: service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*' service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing service.beta.kubernetes.io/aws-load-balancer-target-group-attributes: preserve_client_ip.enabled=true service.beta.kubernetes.io/aws-load-balancer-type: external labels: app.kubernetes.io/instance: test-sip app.kubernetes.io/name: kamailio-tcp app.kubernetes.io/version: 5.5.0-buster spec: type: LoadBalancer externalTrafficPolicy: Local ports: - name: sip-tcp nodePort: 30567 port: 5060 protocol: TCP targetPort: 5060 selector: app.kubernetes.io/instance: test-sip app.kubernetes.io/name: kamailio I have a Netwok Load Balancer create with a listener for TCP 5060 but when I try to connect with Zoiper or Linphone, it does not work :-( I used tcpdump on my pod and it received well some SIP commands. Any ideas of what could be wrong here? Thanks in advance! Cedric

2 years, 6 months

Routing dialogs (INVITE) from Lua

by Emilio Panighetti

Hello, Based on kamailio-basic-kemi.cfg and kamailio-basic-kemi-lua.lua, I’m trying to get a simple test to go through using SIPp built-in UAC and UAS scenarios, using LUA config: Commented out all the registration blocks and trying to run a simple proxy for now, but I can’t seem able to change the URI. SIPp UAC: 192.168.1.12:5060 SIPp UAS: 192.168.1.12:5062 Kamailio 5.5.2: 192.168.15.:5060 Part of the Kamailio.lua config: -- wrapper around tm relay function function ksr_route_relay() -- enable additional event routes for forwarded requests -- - serial forking, RTP relaying handling, a.s.o. if KSR.is_method_in("IBSU") then if KSR.tm.t_is_set("branch_route")<0 then KSR.dbg("EP: ksr_route_relay Set for branch_route\n"); KSR.tm.t_on_branch("ksr_branch_manage"); end end if KSR.is_method_in("ISU") then if KSR.tm.t_is_set("onreply_route")<0 then KSR.dbg("EP: ksr_route_relay Set for onreply_route\n"); KSR.tm.t_on_reply("ksr_onreply_manage"); end end if KSR.is_INVITE() then if KSR.tm.t_is_set("failure_route")<0 then KSR.dbg("EP: ksr_route_relay Set for failure\n"); KSR.tm.t_on_failure("ksr_failure_manage"); end end if KSR.tm.t_relay()<0 then KSR.dbg("EP: ksr_route_relay Set for reply_error\n"); KSR.sl.sl_reply_error(); end -- EP: Base route KSR.dbg("EP: ksr_route_relay Check for Base Route\n"); if KSR.is_INVITE() then KSR.dbg("EP: ksr_route_relay Base Route (DU)\n"); --KSR.sl.send_reply("503", "Debug"); KSR.setdsturi("sip:192.168.1.12:5062"); KSR.pv.sets("$du", "sip:192.168.1.12:5062"); end KSR.dbg("EP: ksr_route_relay exit\n"); KSR.x.exit(); end What’s happening here is that instead of forwarding the INVITE to the SIPp UAC, it creates a loop. Tried KSR.setdsturi() only (KSR.pv.sets commented out) and it’s still the same. If I comment out the 503 reply, then that’s what the UAC gets back. Here’s the log when calling ksr_route_relay: Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/msg_translator.c:162]: check_via_address(): (192.168.1.12, 192.168.1.12, 0) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:489]: sr_lua_reload_script(): No need to reload [/etc/kamailio/kamaili o.lua] is version 0 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:673]: app_lua_run_ex(): executing Lua function: [[ksr_onsend_route]] Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:675]: app_lua_run_ex(): lua top index is: 0 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: tm [t_funcs.c:376]: t_relay_to(): new transaction forwarded Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_r oute_relay Check for Base Route Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_relay Check for Base Route Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_r oute_relay Base Route (DU) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_relay Base Route (DU) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: setdsturi is str: sip :192.168.1.12:5062 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: sets is str: $du Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[1] for: sets is str: sip:192. 168.1.12:5062 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:2906]: sr_kemi_pv_sets(): pv set: $du Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/pvapi.c:371]: pv_cache_add(): pvar [$du] added in cache Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1003]: sr_kemi_lua_exec_func_ex(): param[0] for: dbg is str: EP: ksr_r oute_relay exit Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/kemi.c:85]: sr_kemi_core_dbg(): EP: ksr_route_relay exit Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:1837]: sr_kemi_lua_exit(): script exit call Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_api.c:729]: app_lua_run_ex(): ksr error call from Lua: ~~ksr~exit~~ Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: app_lua [app_lua_mod.c:167]: sr_kemi_config_engine_lua(): execution of route type 1 with no n ame returned 1 Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) INFO: LUA {INVITE}: <core> [core/receive.c:515]: receive_msg(): request-route executed in: 1335 usec Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: LUA {INVITE}: <core> [core/receive.c:606]: receive_msg(): cleaning up Oct 17 23:42:48 ol-vm1 kamailio[2416]: 3(2419) DEBUG: <core> [core/udp_server.c:493]: udp_rcv_loop(): received on udp socket: (112/100/661) [[INVITE sip:service@ 192.168.1.15:5060 SIP/2.0 0D 0A Record-Route: <sip:192.168.1.15;lr=on> 0D 0A Via: SIP/2.0/U]] Any idea how we can route this message? Thanks!

2 years, 6 months

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 October 2021