sr-users August 2018

sr-users@lists.kamailio.org

73 participants
119 discussions

kamailio rabbitmq segfault
by Sylvain Boily 10 Jan '19

10 Jan '19

Hello, I tried to test the rabbitmq module in kamailio with the debian 9 repo from kamailio.org but there is a segfault when the service is launched. Is there is people also have this issue? /etc/init.d/kamailio restart [....] Restarting kamailio (via systemctl): kamailio.serviceJun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/cfg.y:1659]: yyparse(): loading module rabbitmq.so Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/sr_module.c:575]: load_module(): trying to load </usr/lib/x86_64-linux-gnu/kamailio/modules/rabbitmq.so> Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/kemi.c:1295]: sr_kemi_modules_add(): adding module: rabbitmq Jun 9 13:02:03 siprouter kamailio: DEBUG: <core> [core/cfg.lex:1737]: pp_define(): defining id: MOD_rabbitmq Jun 9 13:02:03 siprouter kernel: [159315.610811] kamailio[13226]: segfault at 7f03b2296287 ip 00007f03b2080ca3 sp 00007fff133285c0 error 7 in librabbitmq.so.4.2.0[7f03b2074000+13000] Jun 9 13:02:03 siprouter /usr/sbin/kamailio[13226]: DEBUG: <core> [core/sr_module.c:988]: init_mod(): rabbitmq Sylvain

4 6

RTPengine: shouldn't SDP <sess-version> be incremented when SDP is updated in-dialog?
by George Diamantopoulos 20 Nov '18

20 Nov '18

Hello all, I have the following issue (I think) with RTP engine. An INVITE comes in, and rtpengine will rewrite the SDP accordingly, as configured in kamailio.cfg. After some time a reINVITE is sent out in the opposite direction, for session refresh purposes. As I use rtcp-mux-offer in kamailio.cfg for this direction, RTPengine will inject the rtcp-mux parameter, and this reINVITE is forwarded to the UAC that sent the original INVITE. However, the SDP in the reINVITE is exactly the same as the SDP in the 200 OK to the original INVITE, with the exception of the rtcp-mux parameter. Since the SDP offered from the same end has changed, shouldn't session version be incremented as well? Does this sound like something that should be reported as a bug to rtpengine? Or am I missing something here? Thanks! Best regards, George Diamantopoulos

3 4

siptrace module doesn't close db connections
by Roman Dissauer 12 Nov '18

12 Nov '18

Hi, it seems that siptrace module doesn’t close db connections. I’m on Kamailio 5.1.4 from official debian stretch repository with postgresql db module enabled. siptrace config: modparam("siptrace", "db_url", DBURL) modparam("siptrace", "duplicate_uri", "sip:193.32.51.189:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "hep_capture_id", 1001) modparam("siptrace", "trace_mode", 1) Here you can see the open connections from the kamailio host: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.101.61'; client_addr | state | query --------------+-------+---------------------------------------------------------------- 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' (31 Zeilen) another example, other installation with same kamailio version 5.1.4: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.102.1'; client_addr | state | query -------------+-------+---------------------------------------------------------------- 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' (39 Zeilen) Thanks Roman

2 2

USRLOC db_mode=4 and server_id
by Darren Williams 31 Oct '18

31 Oct '18

I am currently using multiple instances of Kamailio with a common database and using the usrloc module with db_mode=4 and server_id to filter the contacts that get loaded at startup on each server. The problem I seem to have is that using the RPC call ul.add, I cannot see any parameter to send to specify the server_id. The server_id that the contact is given is 0. If I manually go into the db and modify the server_id everything works as expected. I think I must be missing something somewhere as I'm sure you shouldn't need to do this. Can anyone help please. Thanks Daz

3 2

kamailio + rtpproxy behind NAT
by Bonjour Madame 05 Oct '18

05 Oct '18

Hello, I have kamailio and rtpproxy running on the same server located behind a router with NAT just like below. UA(internet)---public ip---router(NAT)--Kamailio+RTPproxy(private ip)--UA(private network) There are several issues like one way audio. I need users on the internet to communicate with each other, users on the private network to communicate with each other, and users on the internet and the private network to communicate with each other. What is the best approach? Best regards, Clarence

3 5

tcp Free fragment not found
by Diego Nadares 04 Oct '18

04 Oct '18

Hi guys! We have four a scripts that sends dlg.list command to kamailio through xmlrpc. They are not executed simultaneously. Sometimes, we are getting the following errors: fm_search_defrag(): fm_search_defrag(0x7f212c25a000, 5273984); Free fragment not found!2017-05-26T13:54:20.438736-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [mem/f_malloc.c:498]: fm_malloc(): fm_malloc(0x7f212c25a000, 5273984) called from core: tcp_main.c: tcpconn_new(957), module: core; Free fragment not found!2017-05-26T13:54:20.439101-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:959]: tcpconn_new(): mem. allocation failure2017-05-26T13:54:20.439344-03:00 drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:3985]: handle_new_connect(): tcpconn_new failed, closing socket I all ready increased this two variables: tcp_conn_wq_max=30000000 tcp_rd_buf_size=5273226 How can I see how much memory xmlrpc is using? Any advice will be appreciated. Thanks in advance! Diego

2 2

What is the typical network setup for kamailio?
by Kevin Olbrich 03 Oct '18

03 Oct '18

Hi! I am working successfully with Kamailio in my lab setup where Kamailio is the SBC for Asterisk. The network layout is looking like this: SIP-Phone <== PUBLIC NET ==> Kamailio (SBC) <== PRIVATE NET ==> Asterisk <== PUBLIC NET ==> Carrier Each public network is reachable from the internet and has a local firewall with IP whitelists. The internal SIP transactions are UDP-only but for external phones I would like to also listen for TCP/TLS. For this layout to work with rtpproxy (before we move on to RTPengine), we have to enable mhomed in Kamailio. We also have some routing issues with packets leaving with the wrong IP via rtpproxy (when call between carrier and external phone needs to be bridged). Most examples show that Asterisk is deployed on the same network as the external interface of Kamailio (-> Asterisk exposed to the public network). In our tests, this works much better but I have great security concerns because this Asterisk instance itself does not need to be reachable from external. How do other users deploy Kamailio in front of Asterisk or similar as SBC to secure internals? There is lot of docs for Kamailio's config but IMHO less for the setup as DMZ (SBC) proxy. Thank you very much. Kind regards Kevin

7 15

Module RTPPROXY param Timeout_Socket not Working
by Hamid Hashmi 24 Sep '18

24 Sep '18

Kamailio didn't start listening on IP mentioned in Module RTPPROXY parameter Timeout_Socket<https://kamailio.org/docs/modules/5.1.x/modules/rtpproxy.html#rtpproxy.p.ti…>. Below is my configuration file. loadmodule "rtpproxy.so" modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722") modparam("rtpproxy", "rtpproxy_tout", 1) modparam("rtpproxy", "rtpproxy_retr", 2) modparam("rtpproxy", "timeout_socket", "xmlrpc:http://127.0.0.1:8000/RPC2") loadmodule "xmlrpc.so" modparam("xmlrpc", "route", "XMLRPC"); modparam("xmlrpc", "mode", 1) modparam("xmlrpc", "url_match", "^/RPC2") when I type a command $ netstat -nlp it only shows SIP listening ports. Kamailio should also start listening on 127.0.0.1:8000. Below are the RTPproxy logs, RTPproxy is also unable to bridge the media DBUG:get_command:GLOBAL: received command "19083_4 Uc120,101 9a1060af660d4202976c419ab5300470 58.65.176.42 4000 1ea06d1eb0a8443697a08e568045598c;1" INFO:rtpp_command_ul_handle:GLOBAL: new session 9a1060af660d4202976c419ab5300470, tag 1ea06d1eb0a8443697a08e568045598c;1 requested, type strong INFO:rtpp_command_ul_handle:9a1060af660d4202976c419ab5300470: new session on a port 35012 created, tag 1ea06d1eb0a8443697a08e568045598c;1 INFO:rtpp_command_ul_handle:9a1060af660d4202976c419ab5300470: pre-filling caller's address with 58.65.176.42:4000 DBUG:rtpc_doreply:GLOBAL: sending reply "35012 51.38.201.3 " DBUG:get_command:GLOBAL: received command "19083_5 Uc120,101 9a1060af660d4202976c419ab5300470 58.65.176.42 4022 9RPsEBbcZSA23MmWAw0hfXzJ-bG1GYDq;1 1ea06d1eb0a8443697a08e568045598c;1 xmlrpc:http://127.0.0.1:8000/RPC2" INFO:rtpp_command_ul_handle:GLOBAL: new session 9a1060af660d4202976c419ab5300470, tag 9RPsEBbcZSA23MmWAw0hfXzJ-bG1GYDq;1 requested, type strong INFO:rtpp_command_ul_handle:9a1060af660d4202976c419ab5300470: new session on a port 35014 created, tag 9RPsEBbcZSA23MmWAw0hfXzJ-bG1GYDq;1 ERR:rtpp_command_ul_handle:9a1060af660d4202976c419ab5300470: invalid socket name 1ea06d1eb0a8443697a08e568045598c;1 INFO:rtpp_command_ul_handle:9a1060af660d4202976c419ab5300470: pre-filling caller's address with 58.65.176.42:4022 DBUG:rtpc_doreply:GLOBAL: sending reply "35014 51.38.201.3 " DBUG:get_command:GLOBAL: received command "19086_4 D 9a1060af660d4202976c419ab5300470 9RPsEBbcZSA23MmWAw0hfXzJ-bG1GYDq 1ea06d1eb0a8443697a08e568045598c" INFO:handle_delete:9a1060af660d4202976c419ab5300470: forcefully deleting session 1 on ports 35012/0 INFO:remove_session:9a1060af660d4202976c419ab5300470: RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped INFO:remove_session:9a1060af660d4202976c419ab5300470: RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped INFO:remove_session:9a1060af660d4202976c419ab5300470: session on ports 35012/0 is cleaned up INFO:handle_delete:9a1060af660d4202976c419ab5300470: forcefully deleting session 1 on ports 35014/0 INFO:remove_session:9a1060af660d4202976c419ab5300470: RTP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped INFO:remove_session:9a1060af660d4202976c419ab5300470: RTCP stats: 0 in from callee, 0 in from caller, 0 relayed, 0 dropped INFO:remove_session:9a1060af660d4202976c419ab5300470: session on ports 35014/0 is cleaned up DBUG:rtpc_doreply:GLOBAL: sending reply "0 " DBUG:get_command:GLOBAL: received command "19086_5 D 9a1060af660d4202976c419ab5300470 9RPsEBbcZSA23MmWAw0hfXzJ-bG1GYDq 1ea06d1eb0a8443697a08e568045598c" INFO:handle_command:GLOBAL: delete request failed: session 9a1060af660d4202976c419ab5300470, tags 9RPsEBbcZSA23MmWAw0hfXzJ-bG1GYDq/1ea06d1eb0a8443697a08e568045598c not found DBUG:rtpc_doreply:GLOBAL: sending reply "E50 But if I comment out the param "Timeout_Socket" then there is no issue in bridging the media. Regards Hamid R. Hashmi

3 6

Missing ACC record in case of canceled call forking
by Marco Capetta 12 Sep '18

12 Sep '18

Hi All, I'm facing a strange problem of missing ACC record in case of parallel call forking. The scenario is the following: - A subscriber with 1 device registered - B subscriber with 2 device registered (B1 and B2) CASE 1: - A calls B - B1 and B2 start ringing - A hangups the call before B1 or B2 answers Kamailio generates an ACC record. CASE 2: - A calls B - B1 and B2 start ringing - B1 rejects the call sending back a 486 - B2 is still ringing - A hangups the call before B2 answers Kamailio DOESN'T generate an ACC record. We have Kamailio v5.1.4 with TM module enabled. ACC configuration is the following: modparam("acc", "early_media", 0) modparam("acc", "report_ack", 0) modparam("acc", "report_cancels", 1) modparam("acc", "detect_direction", 1) modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) modparam("acc", "failed_transaction_flag", 3) I increased debug level of TM and ACC modules and I added some debug lines as well. The difference between the two calls is that, after the CANCEL sent by A is processed by Kamailio, in CASE 1 I have the following lines: Aug 28 14:21:11 spce proxy[13188]: DEBUG: tm [t_hooks.c:258]: run_trans_callbacks_internal(): DBG: trans=0x7f5a88049198, callback type 512, id 0 entered Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_logic.c:670]: tmcb_func(): acc callback called for t(0x7f5a88049198) event type 512, reply code 487 Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]: free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 0 Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]: free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 1 Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]: free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 2 Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]: free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 3 Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]: free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 4 Those debug lines are not printed for CASE 2. Is there any configuration I'm missing or is it a bug? Thank you very much for your support. Marco

2 14

Event: Kamailio Developers Meeting, Sep 27-28, 2018, in Dusseldorf, Germany
by Daniel-Constantin Mierla 07 Sep '18

07 Sep '18

Kamailio SIP Server project is organizing a meeting of its developers during September 27-28, 2018, hosted by sipgate.de in Dusseldorf, Germany. The event is intended to facilitate the interaction between Kamailio developers and to offer a convenient environment for working together on several topics of high interest for the project, including writing code for Kamailio and its tools, improving documentation, or discuss about future development. Everyone from the community is welcome to join. Please note we have a limited capacity of 20 seats in the meeting room. Also, very important to be aware that this is not an event to learn how to use Kamailio. More details about the event, the venue, how to register, are available at: - https://www.kamailio.org/w/developers-meeting/ Looking forward to those two intensive hacking Kamailio days in Dusseldorf! Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 1

2026

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 August 2018