- sr-users - kamailio.org

Kamailio 5.4.3 Troubleshooting Traffic Blocking Issue After Docker and OpenSSL Update
by Pintu Lohar 27 Oct '23

27 Oct '23

Hi All, We have recently encountered a challenging issue in our environment that I wanted to bring to your attention. A few months ago, we performed updates to our Docker and OpenSSL installations, upgrading OpenSSL to version 1.1.1u. Since then, we have been experiencing intermittent traffic blocking (TLS and UDP both for around 10 minutes and getting recovered) on some of our instances. Prior to the OpenSSL upgrade, we had not observed any such issues. However, the situation has become more complex due to a substantial increase in traffic, with each instance now handling 4K-5K concurrent calls and a daily total of approximately 200,000 calls per instance. Our initial suspicion was related to a Docker iptable issue. To investigate further, we conducted a GDB trace using "kamctl pstrap" and discovered specific log entries indicating potential issues within the "pthread_rwlock_wrlock" function. This has prompted us to explore whether the problems are linked to the OpenSSL upgrade. We are considering upgrading Kamailio to the latest version, although this process typically requires a significant amount of time for proper planning and testing. Given the high volume of calls we are currently handling, we are also exploring the possibility of a temporary solution involving a rollback of the OpenSSL version to see if it resolves the issue. Curiously, during a recent load test using SIPP, which simulated 10,000 concurrent calls with a rate of 100 calls per second, we did not encounter the same problem. any hints or insights you may have that could help us pinpoint the root cause of the problem . We do have a complete GDB trace available, but its size necessitates sharing a truncated version for now. version: kamailio 5.4.3 (x86_64/linux) 0178a5 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 0178a5 compiled on 12:36:56 Oct 22 2023 with gcc 4.8.5 Operating System Host : LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: Rocky Description: Rocky Linux release 8.8 (Green Obsidian) Release: 8.8 Codename: GreenObsidian container os (Centos7) Kamctl pstraip output (truncated to last few lines) ---start 154 ----------------------------------------------------- kamailio: No such file or directory. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007fbf6f38a0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6 $1 = 82 $2 = {pid = 154, unix_sock = 182, idx = 27, status = 1, rank = 48, desc = "tcp receiver (tcp:xxx.xxx.xxx.xx:5060 <http://223.62.234.57:5060/>) child=27", '\000' <repeats 81 times>} #0 0x00007fbf6f38a0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6 No symbol table info available. #1 0x0000000000684858 in io_wait_loop_epoll (h=0xb41720 <io_w>, t=2, repeat=0) at core/io_wait.h:1039 n = 84 r = 0 fm = 0x2 revents = 8201656 __FUNCTION__ = "io_wait_loop_epoll" #2 0x0000000000699e7a in tcp_receive_loop (unix_sock=186) at core/tcp_read.c:1997 __FUNCTION__ = "tcp_receive_loop" #3 0x00000000005279e7 in tcp_init_children () at core/tcp_main.c:5134 r = 27 i = -1 reader_fd_1 = 186 pid = 0 si_desc = "tcp receiver (tcp:xxx.xx.xxx.xxx:5060 <http://223.62.234.57:5060/> )\000\000\000\355\217c\000\000\000\000\000\240\213{\001\001\000\000\000\017\000\000\000\000\000\000\000\250\a2o\276\177\000\000\200\b\231o\000\000\000\000\260\006\346\261\376\177\000\000\230\210w\000\000\000\000\000=\000\000\000>\000\000\000\270\016z\350\274\177\000\000\060;8o\002\000\000\000P\224\346\352\001\000\000" si = 0x0 __FUNCTION__ = "tcp_init_children" #4 0x000000000042ae66 in main_loop () at main.c:1771 i = 16 pid = 94 si = 0x0 si_desc = "udp receiver child=15 sock=xxxx.xxx.xxx.xx:5060\000\000\000\v\235\200", '\000' <repeats 13 times>, "P\r\346\261\376\177\000\000\270%}\000\000\000\000\000T\000\000\000\000\000\000\000\060;8o\277\177\000\000\343\207\201\000\000\000\000\000\277;8o\277\177\000\000 \271A\000\000\000\000\000@\374Ko\276\177\000" nrprocs = 16 woneinit = 1 __FUNCTION__ = "main_loop" #5 0x0000000000433ad6 in main (argc=9, argv=0x7ffeb1e60e38) at main.c:2856 cfg_stream = 0x16c9010 c = -1 r = 0 tmp = 0x7ffeb1e61f0c "" tmp_len = 2496 port = 2496 proto = 1472 ahost = 0x0 aport = 0 options = 0x7d5238 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 2208520674 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fbf6f40f3a0 <intel_02_known> p = 0xf0b5ff <Address 0xf0b5ff out of bounds> st = {st_dev = 76, st_ino = 120506675, st_nlink = 2, st_mode = 16877, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1698340416, tv_nsec = 618631009}, st_mtim = {tv_sec = 1698340416, tv_nsec = 618631009}, st_ctim = {tv_sec = 1698340416, tv_nsec = 618631009}, __unused = {0, 0, 0}} tbuf = '\000' <repeats 376 times>... option_index = 0 long_options = {{name = 0x7d742f "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7d2a34 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7d7434 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x7d743a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7d7440 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7d7449 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7d7453 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7d745d "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7d7468 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7d7471 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7d747c "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __FUNCTION__ = "main" [Inferior 1 (process 154) detached] ---end 154 ------------------------------------------------------- ---start 155 ----------------------------------------------------- kamailio: No such file or directory. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007fbe6e5bd39e in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 $1 = 83 $2 = {pid = 155, unix_sock = -1, idx = -1, status = 1, rank = -4, desc = "tcp main process", '\000' <repeats 111 times>} #0 0x00007fbe6e5bd39e in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007fbe68b745c9 in CRYPTO_THREAD_write_lock () from /lib64/libcrypto.so.1.1 No symbol table info available. #2 0x00007fbe68afe07e in CRYPTO_free_ex_data () from /lib64/libcrypto.so.1.1 No symbol table info available. #3 0x00007fbe68ea52c2 in SSL_free () from /lib64/libssl.so.1.1 No symbol table info available. #4 0x00007fbe69149480 in tls_h_tcpconn_clean_f (c=0x7fbceeae00d0) at tls_server.c:655 extra = 0x7fbceec3b898 __FUNCTION__ = "tls_h_tcpconn_clean_f" #5 0x00000000004fbf2d in _tcpconn_free (c=0x7fbceeae00d0) at core/tcp_main.c:1529 __FUNCTION__ = "_tcpconn_free" #6 0x0000000000510912 in tcpconn_put_destroy (tcpconn=0x7fbceeae00d0) at core/tcp_main.c:3284 __FUNCTION__ = "tcpconn_put_destroy" #7 0x00000000005156a5 in handle_tcp_child (tcp_c=0x7fbe6f813440, fd_i=-1) at core/tcp_main.c:3723 tcpconn = 0x7fbceeae00d0 response = {140449434960080, -2} cmd = -2 bytes = 16 n = 1865551792 t = 887186228 crt_timeout = 410 con_lifetime = 57680 __FUNCTION__ = "handle_tcp_child" #8 0x00000000005208ed in handle_io (fm=0x7fbe6f9d7c78, ev=1, idx=-1) at core/tcp_main.c:4542 ret = 1 __FUNCTION__ = "handle_io" #9 0x00000000004e93ed in io_wait_loop_epoll (h=0xad5740 <io_h>, t=5, repeat=0) at core/io_wait.h:1070 n = 1 r = 0 fm = 0x7fbe6f9d7c78 revents = 1 __FUNCTION__ = "io_wait_loop_epoll" #10 0x0000000000523c99 in tcp_main_loop () at core/tcp_main.c:4827 si = 0x0 r = 28 __FUNCTION__ = "tcp_main_loop" #11 0x000000000042b1be in main_loop () at main.c:1779 i = 16 pid = 0 si = 0x0 si_desc = "udp receiver child=15 sock=xxx.xx.xxx.xxx:5060 <http://223.62.234.76:5060/>\000\000\000\v\235\200", '\000' <repeats 13 times>, "P\r\346\261\376\177\000\000\270%}\000\000\000\000\000T\000\000\000\000\000\000\000\060;8o\277\177\000\000\343\207\201\000\000\000\000\000\277;8o\277\177\000\000 \271A\000\000\000\000\000@\374Ko\276\177\000" nrprocs = 16 woneinit = 1 __FUNCTION__ = "main_loop" #12 0x0000000000433ad6 in main (argc=9, argv=0x7ffeb1e60e38) at main.c:2856 cfg_stream = 0x16c9010 c = -1 r = 0 tmp = 0x7ffeb1e61f0c "" tmp_len = 2496 port = 2496 proto = 1472 ahost = 0x0 aport = 0 options = 0x7d5238 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 2208520674 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fbf6f40f3a0 <intel_02_known> p = 0xf0b5ff <Address 0xf0b5ff out of bounds> st = {st_dev = 76, st_ino = 120506675, st_nlink = 2, st_mode = 16877, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1698340416, tv_nsec = 618631009}, st_mtim = {tv_sec = 1698340416, tv_nsec = 618631009}, st_ctim = {tv_sec = 1698340416, tv_nsec = 618631009}, __unused = {0, 0, 0}} tbuf = '\000' <repeats 376 times>... option_index = 0 long_options = {{name = 0x7d742f "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7d2a34 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7d7434 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x7d743a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7d7440 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7d7449 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7d7453 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7d745d "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7d7468 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7d7471 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7d747c "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __FUNCTION__ = "main" [Inferior 1 (process 155) detached] ---end 155 ------------------------------------------------------- Thanks & Regards Pintu Lohar

1 0

Inquiry Regarding Kamailio Behavior and Drop Requests
by satyaprakash ch 26 Oct '23

26 Oct '23

Hi, We possess a code within Kamailio, which specifically handles malformed SIP responses. Below is the code snippet: *reply_routeCopy code if(!sanity_check("17604", "6")) { xlog("Malformed SIP response from $si:$sp\n"); drop;* Additionally, we have Kamailio drop request statistics as follows: Command: *kamctl stats | grep core:drop_requests* Output of the command: *core:drop_requests = 5* My queries are: 1. Is the aforementioned "reply_route" related to the drop requests we are experiencing? 2. If it is not related, what could be the cause of the drop requests?

3 8

Information about Kamailio operating as an SBC
by Alvaro Escobar 24 Oct '23

24 Oct '23

Hello, I am looking information about Kamailio operating as an SBC. I saw this video of Kamailio World 2021: Kamailio As An SBC For Network Segregation: https://www.youtube.com/watch?v=UW6l3R4OnsY&t=1381s But where I can find more detailed technical information ? Regards

3 3

How to filter out xhttp request in event_route[siptrace:msg]
by Benoit Panizzon 24 Oct '23

24 Oct '23

Hi Further trying to eliminate every possible cause of UDP drops... We use Homer as HEP server in conjunction with the siptrace module. So to prevent DQM traffic to be sent to Homer I added: event_route[siptrace:msg] { if(is_method("KDMQ")) { drop(); } } And had a closer look to the traffic sent to homer. I noticed, also xhttp:requests, as far as I see the replies, not the requests, get mirrored to homer. xhttp is not a sip method I could match I guess. The event_route[siptrace:msg] docs state only method can be filtered. So I can not filter requests on the separate http port I listen on for xhttp json-rpc requests. How can I prevent xhttp traffic to be mirrored to homer by the siptrace module? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

4 5

STIR/SHAKEN with Kamailio
by Olle E. Johansson 23 Oct '23

23 Oct '23

Hello Kamailians! As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, I’m curious on how you’ve implemented it with Kamailio. I asked on our Matrix chat and got two responses that seems to not use the Kamailio STIR/SHAKEN support but rather a 3rd party service that they’ve integrated using restful APIs. Please help me and share how you’re implementing STIR/SHAKEN with Kamailio. I’m not shaken, nor stirred. yet. Regards, /O

7 9

How to configure ndb_redis sentinel
by mayamatakeshi 21 Oct '23

21 Oct '23

Hi, regarding ndb_redis, I have 3 sentinels like this: "192.168.88.155:26379" "192.168.88.156:26379" "192.168.88.157:26379" So was thinking that I would configure ndb_redis this way: modparam("ndb_redis", "server", "name=srvZ;sentinel_group=myredis;sentinel_master=1;sentinel= 192.168.88.155:26379") modparam("ndb_redis", "server", "name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel= 192.168.88.156:26379") modparam("ndb_redis", "server", "name=srvZ;sentinel_group=myredis;sentinel_master=0;sentinel= 192.168.88.157:26379") But the samples in the documentation show an extra sentinel key in the config lines: # sentinel (for a redis slave) modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=0;sentinel=1.2.3.4:26379 ;sentinel=1.2.3.5:26379") # sentinel (for a redis master) modparam("ndb_redis", "server", "name=srvZ;sentinel_group=group_name;sentinel_master=1;sentinel=1.2.3.4:26379 ;sentinel=1.2.3.5:26379") So I am not sure if my configuration is correct. Can someone clarify?

1 0

lookup() and database
by Jawaid Bazyar 20 Oct '23

20 Oct '23

Hi, I have an application as follows: Multiple Kamailio Nodes Shared Postgres database Auth information will be stored in DB and accessed with Authdb. Here is the behavior I seek: I would like all the Kamailo nodes to cooperate in updating the database, each updating data as appropriate: When a registration comes in to any Node, and it authenticated, create or update a database record in location table. When a registration expires on that Node, delete database record in location table. When INVITE comes in on any Node, ignore local cache and always lookup() record from database. #1 and #2 are used so that a third SIP system can query the database and look up the Node a NAT’d subscriber is ‘connected’ to. #3 is to let NON-NAT’d subscribers be contacted from any Node. Now I have something close to this now – using following settings: modparam("usrloc", "db_mode", 1) # immediately write registrations to the database. modparam("usrloc", "db_timer_clean", 0) # do not expire DB records separately modparam("usrloc", "db_check_update", 1) This takes care of #1 and #2 above. However, #3 seems to still be relying purely on local cache and does not hit the database. Is there a way to do #3? I can set db_mode to 3 but that would seem to have other effects besides merely making lookup() read from database. Thanks in advance, Jawaid

3 8

TOPOS + Forcing the send socket
by Marrold 19 Oct '23

19 Oct '23

Hi all, I am using Kamailio (5.7.2, Debian 11, Python KEMI) in a mutli-homed environment with the topos module to hide the topology. I have noticed that when I use `set_send_socket` or `$fsn` to force the socket it's sent from, it breaks topos and the ACK is not proxied to the other leg of the call. I am calling record_route() *after* forcing the socket. If I disable TOPOS the ACK works as expected, and the signalling looks correct. Or, with TOPOS enabled, if I comment out set_send_socket TOPOS works as expected. If I disable enable_double_rr, TOPOS works as expected and the ACK is forwarded, but without the double RR subsequent in-dialog requests use the wrong socket. One other observation, when I change the send socket I also see these warnings in the logs: 24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1348]: dlg_onroute(): tight matching failed for ACK with callid='!!:MByLMlFAM.NfWxFAM.cAMxyfWjyLz.yAO.y6MxF1MxVZWG4ZMy**'/55, ftag='2023101714101800015'/19, ttag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 and direction=0 24(32) WARNING: PY3 {ACK}: dialog [dlg_handlers.c:1355]: dlg_onroute(): dialog identification elements are callid='2023101714101800015@2900-0601-0284-80'/37, caller tag='2023101714101800015'/19, callee tag='2f55349a-2c59-4e37-bf58-fd84fb69ece9'/36 Is anyone using TOPOS + forcing the socket, or could someone advise where I am going wrong? Thanks in advance Matthew

3 8

Kamailio SIP proxy role
by Ali Taher 18 Oct '23

18 Oct '23

Hello, I'm using Kamailio as SIP proxy between Session Manager and SBC So here is the scenario : Session Manager sends a call (Invite) to Kamailio, kamailio needs to relay it to SBC after doing some modification. (-----Session Manager-----) ----------- > (----Kamailio----) ----------- > (-----SBC-----) My routing logic is similar to the below: route{ if ((method==OPTIONS) && (! uri=~"sip:.*[@]+.*")) { options_reply(); } if (is_method("INVITE")) { sql_query("cb", "select number from pool1 order by random() limit 1", "ra"); $var(rand)=$dbr(ra=>[0,0]); uac_replace_from($var(rand),"sip:$var(rand)@192.168.1.1"); xlog("L_INFO","Random: $var(rand)"); $var(ip) = $(ct{s.select,1,(a)}{s.select,0,;}{s.replace,>,}); remove_hf("Contact"); insert_hf("Contact: $var(rand) <sip:$var(rand)@$var(ip)>\r\n"); remove_hf("P-Asserted-Identity"); remove_hf("Route"); insert_hf("Route: <sip: 192.168.1.10>\r\n","Route"); record_route(); t_relay(); $td = "192.168.1.10"; $rd = "192.168.1.10"; t_relay(); } } Where: 192.168.1.1 is Kamailio IP 192.168.1.10 is SBC IP My question here is that Kamailio handle all in dialog messages between Session Manager and SBC? For example, after forwarding the invite packet to SBC, SBC sends 183 Session Progress to Kamailio, which in its turn relay it to the session manager, knowing that this is not mentioned in my routing logic, so how Kamailio knew that it must relay it to session manager in this case? Also I need to add to the 183 Session Progress sent to session manager by Kamailio record route and Via headers , how to do it ? Regards,

1 0

Dispatcher HA:won't route headers be wrong if in-dialog request is sent to backup?
by Richard Chan 18 Oct '23

18 Oct '23

Hi sr-users, In the case of dispatcher-based HA such as the Wazo example ( https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq) won't the Route: headers be wrong for in-dialog requests if the request is sent to the backup proxy? front proxy -> proxy A, B, C, D,... -> network Suppose the INVITE goes through proxy A, then proxy A goes down. Based on the HA logic, an in-dialog request will go to a backup, say, proxy B. However, won't the Route headers be wrong (since they are placed by A) in the original transaction? How do you handle Route:, Record-Route: headers at the HA tier? 1. In the front proxy & HA tier don't use route headers at all ?? 2. Manually check and remove route headers (i.e proxy B treats route headers for proxy A as "myself") ?? I am curious as to what is your practice. Regards Shih-Ping

1 0

Restarts Kamailio after general protection fault
by Daian Conrad 17 Oct '23

17 Oct '23

Hi all, I have started using kamailio as a proxy register for asterisk's and works fine, but in some moment kamailio show WARNINGs, ALERTS and CRITICAL logs and restart. I don't no how debug correctly, but the crash show this log lines *Oct 16 21:34:26 proxy /usr/sbin/kamailio[2148]: CRITICAL: <core> [core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f14a27a5ab8 (address 0x7f14a27a5af0) beginning overwritten (7f14a27a8e58)! Memory allocator was called from uac: uac_send.c:860. Fragment marked by UH��AWAVAUATSH��:139726602009368. Exec from core/mem/q_malloc.c:511.* ------------------------------------------------------------- *Oct 16 21:39:46 proxy /usr/sbin/kamailio[2556]: CRITICAL: <core> [core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm. 0x7ff7ad456330 (address 0x7ff7ad456368) beginning overwritten (0)! Memory allocator was called from uac: uac_send.c:860. Fragment marked by (null):0. Exec from core/mem/q_malloc.c:511.Oct 16 21:39:46 proxy /usr/sbin/kamailio[2578]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 19Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]: ALERT: <core> [main.c:774]: handle_sigs(): child process 2556 exited by a signal 6Oct 16 21:39:46 proxy /usr/sbin/kamailio[2539]: ALERT: <core> [main.c:777]: handle_sigs(): core was not generatedOct 16 21:39:46 proxy systemd[1]: kamailio.service: Main process exited, code=exited, status=1/FAILUREOct 16 21:39:46 proxy systemd[1]: kamailio.service: Failed with result 'exit-code'.Oct 16 21:39:46 proxy systemd[1]: kamailio.service: Service RestartSec=100ms expired, scheduling restart.Oct 16 21:39:46 proxy systemd[1]: kamailio.service: Scheduled restart job, restart counter is at 9.Oct 16 21:39:46 proxy systemd[1]: Stopped Kamailio - the Open Source SIP Server.* any advice is apreciated -- ================ **Daian Conrad** E-mail: daian.conrad(a)gmail.com OpenS Team (DaCoD) Linux user: #248912

2 3

ERROR: run_top_route
by satyaprakash ch 17 Oct '23

17 Oct '23

Hi, We are having an error in the Kamailio logs which we need to resolve this issue, ERROR is ::* /usr/local/sbin/kamailio[10149]: ERROR: tm [t_reply.c:1081]: run_failure_handlers(): error running run_top_route for failure handler.* We are getting this error at the time of the 3xx response, Can anyone help me on this? Thank you.

3 8

Wrong RTP endpoint announced by Kamailio when forwarding calls, but looks correct from RTPEngine
by Leonardo Arena 17 Oct '23

17 Oct '23

Hi all, I have the following setup: Phone <-> private net using TCP transport <-> (172.30.0.156) Kamailio v5.6.3 + RTPEngine v9.3.1 (22.33.177.156) <-> public net using UDP transport <-> Asterisk (22.33.178.77) Phone is registered on Kamailio and forward calls on no answer or when ext is unregistered, to Asterisk's custom IVR (nodejs app + CouchDB), using failure_route() [1]. The problem is that when the none answer the phone and the call is redirected to Asterisk, Kamailio announce its private IP address in the SDP connection endpoint, hence there is no audio [2]. From RTPEngine debug logs, it seems that RTPEngine replies with the correct SDP connection endpoint IP [3]. See also RTPEngine interfaces definition [4]. What am I missing? Why Kamailio is offering its private IP address in the SDP connection, instead of its public address when forwarding the call? If comment "route(SDP_MANAGE_IN)" in route[IN], Kamailio uses the correct IP endpoint address in the SDP offer when forwarding the call to Asterisk. But of course this breaks audio when someone answer the phone. It seems that Kamailio is storing the initial SDP offer settings and does not update it upon RTPEngine's request, even though I have added "replace-session-connection" in route[SDP_OFFER_IVR]. Thanks for any help! leo [1] route[IN] { if (!lookup('location')) { t_on_reply("SDP_MANAGE"); route(TOIVR); } else { xlog("L_INFO", "Route(IN) Req $mi $rm From <$fu> To <$tu> RURI <$ru>\n"); record_route(); t_on_reply("SDP_MANAGE"); route(SDP_MANAGE_IN); t_on_failure("TOIVR"); t_relay(); exit; } } route[SDP_MANAGE] { if (has_body("application/sdp")) { rtpengine_manage(); } } route[SDP_MANAGE_IN] { if (has_body("application/sdp")) { rtpengine_manage("direction=public direction=private via-branch=1"); } } ... route[SDP_OFFER_IVR] { if (has_body("application/sdp")) { rtpengine_offer("direction=public direction=public replace-session-connection via-branch=1"); } } failure_route[TOIVR] { if (t_is_canceled()) { exit; } append_branch(); route(SDP_OFFER_IVR); # using t_relay_to so that UDP is used with the correct IP address if (!t_relay_to("xh.voip.net")) { xlog("L_INFO", "No answer - Failure Route(TOIVR) Req $mi $rm From <$fu> To <$tu> RURI <$ru> failed\n"); t_reply("500", "Unable to route"); } else { xlog("L_INFO", "No answer - Failure Route(TOIVR) Req $mi $rm From <$fu> To <$tu> RURI <$ru>\n"); } } [2] U 2023/10/11 09:05:43.797393 22.33.177.156:5060 -> 22.33.176.8:5060 #3 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 22.33.176.8;branch=z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0. Via: SIP/2.0/UDP 22.33.176.20;branch=z9hG4bK2cb2.2920561c845ee5279051359f40cb7c0f.0. Via: SIP/2.0/UDP 44.55.73.157:5060;branch=z9hG4bK0cBdccef20c0d8bfefb. Record-Route: <sip:172.30.0.156;transport=TCP;r2=on;lr=on;ftag=gK0c1bb12e>. Record-Route: <sip:22.33.177.156;r2=on;lr=on;ftag=gK0c1bb12e>. Record-Route: <sip:22.33.176.8;lr=on;ftag=gK0c1bb12e;did=7ffe.26c8>. Record-Route: <sip:22.33.176.20;lr=on;ftag=gK0c1bb12e>. From: "Unavailable" <sip:013335553222@44.55.73.157>;tag=gK0c1bb12e. To: <sip:8555000033@22.33.176.20>;tag=660096088. Call-ID: 474758100_116775912(a)44.55.73.157. CSeq: 704680 INVITE. Contact: <sip:+18555000033@172.30.96.2:11815;transport=TCP>. Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE. User-Agent: Yealink SIP-T31P 124.86.0.40. Allow-Events: talk,hold,conference,refer,check-sync. Content-Length: 0. . U 2023/10/11 09:06:03.751585 22.33.177.156:5060 -> 22.33.178.77:5060 #4 INVITE sip:+18555000033@172.30.96.2:11815;transport=TCP SIP/2.0. Record-Route: <sip:22.33.177.156;lr=on;ftag=gK0c1bb12e>. Record-Route: <sip:22.33.176.8;lr=on;ftag=gK0c1bb12e;did=7ffe.26c8>. Record-Route: <sip:22.33.176.20;lr=on;ftag=gK0c1bb12e>. Via: SIP/2.0/UDP 22.33.177.156;branch=z9hG4bK2cb2.afb825e30e294872c72c5e21ef26f3f3.1. Via: SIP/2.0/UDP 22.33.176.8;branch=z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0. Via: SIP/2.0/UDP 22.33.176.20;branch=z9hG4bK2cb2.2920561c845ee5279051359f40cb7c0f.0. Via: SIP/2.0/UDP 44.55.73.157:5060;branch=z9hG4bK0cBdccef20c0d8bfefb. f: "Unavailable" <sip:013335553222@44.55.73.157>;tag=gK0c1bb12e. t: <sip:8555000033@22.33.176.20>. i: 474758100_116775912(a)44.55.73.157. CSeq: 704680 INVITE. Max-Forwards: 32. Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH. Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed. m: "Unavailable" <sip:013335553222@44.55.73.157:5060>. Remote-Party-ID: "Unavailable" <sip:013335553222@44.55.73.157:5060>;privacy=off. k: timer,100rel,precondition. Session-Expires: 1800. Min-SE: 90. l: 604. Content-Disposition: session; handling=required. c: application/sdp. . v=0. o=Sonus_UAC 525653 764118 IN IP4 44.55.73.157. s=SIP Media Capabilities. c=IN IP4 172.30.0.156. t=0 0. m=audio 30030 RTP/AVP 0 18 101. a=maxptime:20. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=n [3] Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO: [474758100_116775912(a)44.55.73.157]: [control] Received command 'offer' from 127.0.0.1:39942 Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: [control] Dump for 'offer' from 127.0.0.1:39942: { "supports": [ "load limit" ], "sdp": "v=0^M o=Sonus_UAC 5 25653 764118 IN IP4 44.55.73.157^M s=SIP Media Capabilities^M c=IN IP4 44.55.78.60^M t=0 0^M m=audio 61610 RTP/AVP 0 18 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=no^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M a=maxptime:20^M ", "direction": [ "public", "public" ], "replace": [ "session-connection" ], "call-id": "474758100_116775912(a)44.55.73.157 ... Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: ... ", "via-branch": "z9hG4bK2cb2.e559c4a326678f69ae9b4656be7bc36c.0", "received-from": [ "IP4", "22.33.176 .8" ], "from-tag": "gK0c1bb12e", "command": "offer" } ... Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO: [474758100_116775912(a)44.55.73.157]: [control] Replying to 'offer' from 127.0.0.1:39942 (elapsed time 0.000638 sec) Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: [control] Response dump for 'offer' to 127.0.0.1:39942: { "sdp": "v=0^M o=Sonus_UAC 525653 764118 IN IP4 207 .223.73.157^M s=SIP Media Capabilities^M c=IN IP4 22.33.177.156^M t=0 0^M m=audio 30068 RTP/AVP 0 18 101^M a=maxptime:20^M a=rtpmap:0 PCMU/8000^M a=rtpmap:18 G729/8000^M a=fmtp:18 annexb=no^M a=rtpmap:101 teleph one-event/8000^M a=fmtp:101 0-15^M a=sendrecv^M a=rtcp:30069^M ", "result": "ok" } Oct 11 09:06:03 voipsipr7 daemon.info /usr/sbin/kamailio[35261]: INFO: <script>: No answer - Failure Route(TOIVR) Req 4 INVITE From <sip:013335553222@44.55.73.157> To <sip:8555000033@22.33.176.20> RURI <sip: +18555000033@172.30.96.2:11815;transport=TCP> Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO: [474758100_116775912(a)44.55.73.157]: [control] Received command 'answer' from 127.0.0.1:53245 Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: [control] Dump for 'answer' from 127.0.0.1:53245: { "supports": [ "load limit" ], "sdp": "v=0^M o=- 525653 7 64120 IN IP4 22.33.178.77^M s=Asterisk^M c=IN IP4 22.33.178.77^M t=0 0^M m=audio 11264 RTP/AVP 0 101^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-16^M a=ptime:20^M a=maxptime:150^M a=sendrecv^M m=audio 0 RTP/AVP 0 18 101^M ", "call-id": "474758100_116775912(a)44.55.73.157", "received-from": [ "IP4", "22.33.178.77" ], "from-tag": "gK0c1bb12e", "to-tag": "a21c53b6-ca33-43b ... Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: ... 4-a585-af9b568a5ecb", "command": "answer" } ... Oct 11 09:06:03 voipsipr7 daemon.info rtpengine[35061]: INFO: [474758100_116775912(a)44.55.73.157]: [control] Replying to 'answer' from 127.0.0.1:53245 (elapsed time 0.000915 sec) Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: [control] Response dump for 'answer' to 127.0.0.1:53245: { "sdp": "v=0^M o=- 525653 764120 IN IP4 22.33.178 .77^M s=Asterisk^M c=IN IP4 22.33.177.156^M t=0 0^M m=audio 30056 RTP/AVP 0 101^M a=maxptime:150^M a=rtpmap:0 PCMU/8000^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-16^M a=sendrecv^M a=rtcp:30057^M a=ptime :20^M m=audio 0 RTP/AVP 0 18 101^M ", "result": "ok" } Oct 11 09:06:03 voipsipr7 daemon.debug rtpengine[35061]: DEBUG: [474758100_116775912(a)44.55.73.157]: [core] Forward to sink endpoint: 22.33.178.77:11264 (RTP seq 0 TS 0) [4] Interface definition in RTPEngine: interface = public/22.33.177.156;public/22:33:201:105::156;private/172.30.0.156

3 3

Switching DMQ transport to TCP?
by Benoit Panizzon 17 Oct '23

17 Oct '23

Hi Gang While still hunting DMQ issues, I noticed that the OS is reporting UDP drops. Maybe DMQ packets? Would DMQ re-send a lost packet? I increased OS UDP RX buffers times 10 and monitoring counters. I also found that DMQ can use tcp or tls as transport. Could this help to prevent loosing DMQ messages? Or is this prone to cause new issues? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

UDP Fragmentation webRTC/UDP Call
by Social Boh 16 Oct '23

16 Oct '23

Hello, I'm trying to solve a problem with calls WebRTC/UDP. I think is a fragmentation problem because udp/webRTC calls works without problem. The INVITE from Kamailio to the UDP device not receive any type of answer. I'm trying to reduce the SDP annex size using: |sdp_remove_line_by_prefix| for some lines unsuccessfully. Maybe I don't know where put this function in the script. Or, is there another way to solve this issue? Thank you in advance Regards -- --- I'm SoCIaL, MayBe

5 10

Dialog Module: enable_dmq and multiple nodes update SAME profiles_with_value counter?
by Benoit Panizzon 16 Oct '23

16 Oct '23

Hi Team I'm still hunting down DMQ dialog issues. https://www.kamailio.org/docs/modules/devel/modules/dialog.html#dialog.p.en… Quote: "Notably, it is not possible to send in-dialog requests on any but the original proxy instance." I make sure, that if a procied call (with same callID) is being redirected from anywhere, it is send to the came dialog aware kamailio instance it originated from. This seems to have fixed a lot of issues with dialogues getting corrupted. The two main purposed we use dialog is: * CDR * Channel Counting / Limiting modparam("dialog", "profiles_with_value", "custprofilecounter"); Can a such profile WITH value be written from any node sharing dialog via DMQ or is this bound to cause troubes? Example. Two call get to same customer, but over two different nodes. Node A is getting a call: set_dlg_profile("custprofilecounter","Customer7664"); get_profile_size("custprofilecounter","Customer7664","$var(busy_count)"); => $var(busy_count) is now 1. The profile is replicated to Node B and the value can be accessed there. While Call on Node A is running, Node B is getting a call to same customer: set_dlg_profile("custprofilecounter","Customer7664"); get_profile_size("custprofilecounter","Customer7664","$var(busy_count)"); => $var(busy_count) is now 2 on Node B. Is this value being replicated BACK to Node A where the profile counter originally was created? As far as I have experienced, this is the case. But what happens if the call on Node B is ending before the Call on Node A? Will the counter being decreased also correctly be replicated to Node A? What happens the other way round? What happens if both call end at the same time? Is a race condition possible, or is there some sort of locking to prevent this? Can I use profiles_with_value the way I use them? Or is this bound to fail because it's not supported? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

Discrepancy between RPC stats and real data from the UAC module
by Denys Pozniak 16 Oct '23

16 Oct '23

Hello! We use the UAC module for outbound registrations and when we try to get RPC statistics we see that the data does not match, what could be the reason? # kamcmd stats.get_statistics uac: uac:regactive = 14 uac:regdisabled = 0 uac:regtotal = 0 # kamctl rpc uac.reg_dump | grep flag | grep 20 -c 745 # kamailio -v version: kamailio 5.6.4 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, 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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 10.2.1 -- BR, Denys Pozniak

1 0

Re: Crypto module AES algorithm details
by Henning Westerholt 16 Oct '23

16 Oct '23

(Please keep the list in CC) Hello, The web tools might use another logic internally. I had some success with a java library use case and also with PostgreSQL, I think. A usual use-case is to have an encrypted password value in a DB, for data at rest encryption. The password is encrypted from something else. Then inside the Kamailio cfg you want to encrypt it on the fly, to use it for example for challenging a phone with username/password. Maybe you can give it a try with some python or other script languages, where you can play with the different crypto system parameter more easily. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Jayesh Nambiar <jayesh1017(a)gmail.com> Sent: Donnerstag, 5. Oktober 2023 06:41 To: Henning Westerholt <hw(a)gilawa.com> Subject: Re: [SR-Users] Crypto module AES algorithm details Hello Henning, Thanks for the super fast reply. I tested this within kamailio 5.3.4 and I can successfully encrypt a header value and also the same encrypted value decrypts to proper plain text when. But when I compare the encrypted text with online resources like https://www.devglan.com/online-tools/aes-encryption-decryption and https://www.javainuse.com/aesgenerator, their encrypted text value is different from what I see from kamailio. Both these resources produce the same encrypted text while the encrypted text from kamailio is different. How do I validate this? My use case is as follows: -- I get an encrypted text in a SIP Header -- I decrypt it and validate it against some DB -- If valid proceed or else exit Now if the algorithm doesnt match exactly, there are chances of error, hence asking question on how to validate it. On Wed, Oct 4, 2023 at 1:43 PM Henning Westerholt <hw(a)gilawa.com<mailto:hw@gilawa.com>> wrote: Hello Jayesh, AFAIK its uses AES 256 with CBC mode. The IV is generated from OpenSSL, e.g. https://www.openssl.org/docs/man3.0/man3/EVP_BytesToKey.html For newer versions I have added the init_vector functionality to enable interoperability with other crypto functions, e.g. some databases, java frameworks etc. If you want to use this functionality, I’d suggest to update, as the 5.3. is also end of life since some time. Otherwise you can of course also backport this feature. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Jayesh Nambiar via sr-users <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Sent: Mittwoch, 4. Oktober 2023 08:54 To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org>> Cc: Jayesh Nambiar <jayesh1017(a)gmail.com<mailto:jayesh1017@gmail.com>> Subject: [SR-Users] Crypto module AES algorithm details Hello, I am running kamailio-5.3.4 on one of my setup and I intend to use the crypto module in the same. I wanted to understand the following details when the module is used: I understand it uses the AES algorithm, is that correct? Does it use AES 128, 192 or 256 bit algorithms? Does it use CBC or ECB mode for AES? The 5.3 version does not have an parameter for init-vector, so does kamailio use any init vector internally in this case? When i compared the encrypted text that kamailio produces and the ones available online, they were producing different outputs even when same shared secret was used. Hence asking for more clarification PS: Upgrading kamailio is my very last option as this is one af an old setup which only needs this feature without much changes. Thanks for any valuable response. -- Jayesh

2 2

503(service unavailable)
by masoud96＠mail.ru 16 Oct '23

16 Oct '23

Hello! It often happens to me that the service begins to refuse service (503) and so far I have not been able to understand the exact reason. Typically, before clients start receiving 503, many before them receive a 408 code. As soon as the service starts responding with 503, it does not recover on its own, you have to restart. There is no way to understand from the logs what led to this (nothing unusual). My server is powerful enough for the number of users of my service (what I mean is that there is no problem with resources). For example, 64 cores, 125GB of DDR4 RAM, 2TB of disk, of which 1TB SSD for the database, 10Gigabit channel, this is only a server for Kamailio for Rtpengines separate servers. Please help me figure out what causes a service failure!? OS: Debian 11, 64 cores, 125GB of DDR4 RAM; DB: MariaDB 10.5.15; kamailio -v version: kamailio 5.5.3 (x86_64/linux) 473cef flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, 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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. udp_children: 30; tcp_children: 34; TLS: YES; async_workers: 64. Incoming calls are sent via push notifications( Federico Cabiddu method: https://www.voztovoice.org/sites/default/files/KamilioWorld2015%20-Federico…). NetBridging(for SIP and RTPEngine). ims_charging for billing (integration with our billing system using the Diameter protocol). In the logs exactly at the moment when the service began to refuse, the recording disappears completely for 7 minutes, absolutely no entries, after which the recording of the TCP queue full begins. Oct 3 18:38:07 sip1-life3 kamailio[3380553]: CRITICAL: {2 3691 INVITE 672699d1-c76b-4153-b72a-fe647913a9e9} tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed Oct 3 18:38:09 sip1-life3 kamailio[3380539]: CRITICAL: {2 3691 INVITE 672699d1-c76b-4153-b72a-fe647913a9e9} tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed Oct 3 18:38:12 sip1-life3 kamailio[3380534]: CRITICAL: {2 30106 INVITE 032f8650-1d90-49ed-82f1-c50ccbef191d} tm [../../core/forward.h:292]: msg_send_buffer(): tcp_send failed Oct 3 18:45:14 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 11, socket 224: queue full, 285 requests queued (total handled 2899418) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 1, socket 204: queue full, 286 requests queued (total handled 2964063) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 4, socket 210: queue full, 286 requests queued (total handled 2923484) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 6, socket 214: queue full, 286 requests queued (total handled 2911633) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 7, socket 216: queue full, 286 requests queued (total handled 2907132) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 8, socket 218: queue full, 286 requests queued (total handled 2903281) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 9, socket 220: queue full, 286 requests queued (total handled 2903438) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 11, socket 224: queue full, 286 requests queued (total handled 2899419) Oct 3 18:45:15 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 12, socket 226: queue full, 286 requests queued (total handled 2897842) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 16, socket 234: queue full, 286 requests queued (total handled 2895429) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 17, socket 236: queue full, 286 requests queued (total handled 2895303) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 22, socket 246: queue full, 286 requests queued (total handled 2891873) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 26, socket 254: queue full, 286 requests queued (total handled 2892619) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 27, socket 256: queue full, 286 requests queued (total handled 2891769) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 224 , queue entry 0, retries 98, connection 0x7f0b6d974348, tcp so Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 30, socket 262: queue full, 286 requests queued (total handled 2891614) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 31, socket 264: queue full, 286 requests queued (total handled 2890778) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 33, socket 268: queue full, 286 requests queued (total handled 2890852) Oct 3 18:45:16 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 0, socket 202: queue full, 287 requests queued (total handled 3071438) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 1, socket 204: queue full, 287 requests queued (total handled 2964064) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 2, socket 206: queue full, 287 requests queued (total handled 2944928) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 4, socket 210: queue full, 287 requests queued (total handled 2923485) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 5, socket 212: queue full, 287 requests queued (total handled 2915778) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 6, socket 214: queue full, 287 requests queued (total handled 2911634) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 7, socket 216: queue full, 287 requests queued (total handled 2907133) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 8, socket 218: queue full, 287 requests queued (total handled 2903282) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 9, socket 220: queue full, 287 requests queued (total handled 2903439) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 10, socket 222: queue full, 287 requests queued (total handled 2900227) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 11, socket 224: queue full, 287 requests queued (total handled 2899420) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 12, socket 226: queue full, 287 requests queued (total handled 2897843) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 204 , queue entry 0, retries 88, connection 0x7f0b742a1968, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 13, socket 228: queue full, 287 requests queued (total handled 2896210) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 210 , queue entry 0, retries 86, connection 0x7f0b74ffaa08, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 16, socket 234: queue full, 287 requests queued (total handled 2895430) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 214 , queue entry 0, retries 88, connection 0x7f0b75003218, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 216 , queue entry 1, retries 86, connection 0x7f0b75007620, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 218 , queue entry 2, retries 84, connection 0x7f0b74772f70, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 17, socket 236: queue full, 287 requests queued (total handled 2895304) Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 220 , queue entry 0, retries 87, connection 0x7f0b74777378, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: ERROR: [core/tcp_main.c:3458]: send_fd_queue_run(): send_fd failed on socket 224 , queue entry 1, retries 83, connection 0x7f0b7477fb88, tcp so Oct 3 18:45:17 sip1-life3 /usr/local/sbin/kamailio[3380778]: CRITICAL: [core/tcp_main.c:4170]: send2child(): tcp child 21, socket 244: queue full, 287 requests queued (total handled 2893042)

4 7

183 Session Progress Acknowledgment
by Ali Taher 14 Oct '23

14 Oct '23

Hello, Is there a way to send PRACK as reply to a 183 Session Progress (with Require: 100rel) sent to Kamailio sip proxy? Regards,

2 3

Kamailio as SIP proxy
by Ali Taher 12 Oct '23

12 Oct '23

Hello, I'm using Kamailio as SIP proxy between Session Manager and SBC So here is the scenario : Session Manager sends a call (Invite) to Kamailio, kamailio needs to relay it to SBC after doing some modification. (-----Session Manager-----) ----------- > (----Kamailio----) ----------- > (-----SBC-----) My routing logic is similar to the below: route{ if ((method==OPTIONS) && (! uri=~"sip:.*[@]+.*")) { options_reply(); } if (is_method("INVITE")) { sql_query("cb", "select number from pool1 order by random() limit 1", "ra"); $var(rand)=$dbr(ra=>[0,0]); uac_replace_from($var(rand),"sip:$var(rand)@192.168.1.1"); xlog("L_INFO","Random: $var(rand)"); $td = "192.168.1.10"; $rd = "192.168.1.10"; t_relay(); } } Where: 192.168.1.1 is Kamailio IP 192.168.1.10 is SBC IP The issue is that I'm not sure to handle the other SIP packets like 183,CANCEL, BYE etc that can be received from both SBC and session Manager? What to add to my configuration to handle it properly? Regards,

2 1

Using DMQ to sync the TM module.
by Michel Pelletier 11 Oct '23

11 Oct '23

Hi, I have 2 kamailio instances behind a load balancer. The problem I have is that the load balancer can only track TCP connections, but not UDP. So one Kamailio instance might send a request using UDP, while the corresponding UDP reply arrives on the other. This doesn't play well with the (stateful) TM module. Is there a way to synchronize the TM module accross Kamailio instances using DMQ? Cheers, Michel Pelletier

4 8

rtpproxy -- timeout_socket
by James Lipski 11 Oct '23

11 Oct '23

Hello, I'm a bit confused about a piece of the documentation. I'm using rtpproxy 3.0.1 + rtpproxy module on kamailio 5.6.4. On the rtpproxy module, I'm trying to get the "timeout_socket" param working. From the documentation, I have modparam("rtpproxy", "timeout_socket", "xmlrpc:http://192.168.155.64:8888/XMLRPC") modparam("xmlrpc", "route", "XMLRPC_ROUTE") modparam("xmlrpc", "mode", 1) modparam("xmlrpc", "url_match", "^/XMLRPC") /usr/bin/rtpproxy -i -u rtpproxy -n tcp:192.168.155.64:8888 -l 192.168.155.64 -s udp:127.0.0.1:7333 -m 29152 -M 49150 -d DBUG However when purposely trying to timeout RTP, I'm seeing the following in my rtpproxy logs: Oct 10 00:31:22 localhost rtpproxy[3802129]: DBUG:GLOBAL:rtpp_command_split:401: received command "3801518_4 USc9,0,8,18,101 219b2465decc-n7al36xva4lw 192.168.155.168 2266 C60D788E-8E14A9FA;1 w6p2ke9ttk;1 xmlrpc:http://192.168.155.64:8888/XMLHTTP" Oct 10 00:31:22 localhost rtpproxy[3802129]: ERR:219b2465decc-n7al36xva4lw:rtpp_command_ul_handle:603: invalid socket name w6p2ke9ttk;1 I'm just wondering if I'm missing anything, do I need to define "listen=tcp:192.168.155.64:8888" in my configs? I know that rtpengine is recommended/ I would like to experiement with rtpproxy. Do I need a specific version of rtpproxy in order for this to work -- I did try it with 2.1.1 however that didn't work. Thanks.

2 2

Kamailio Developers Meeting, Nov 7-8, 2023, in Dusseldorf
by Daniel-Constantin Mierla 11 Oct '23

11 Oct '23

Hello, Kamailio SIP Server project is organizing another meeting of its developers and community members during November 7-8, 2023, hosted again by sipgate.de in Dusseldorf, Germany. The event is intended to facilitate the interaction between Kamailio developers and contributors in order 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, developer or user interested in helping the project. Please note we have a limited capacity of seats in the meeting room, the main policy for accepting participants being first come first server. 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 (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy and Development Services Kamailio Advanced Training - Online - Nov 14-16, 2023 -- asipto.com

1 0

Error reporting when developing a custom module to link to a third-party library
by bikq＠163.com 11 Oct '23

11 Oct '23

Dear friends, I have a question: When adding a custom module in kamailio, I referenced a third-party library. There was no problem with compilation, but when I ran it, it reported that the third-party library could not be found. What is the reason? The current Makefile is as follows： ``` # WARNING: do not run this directly, it should be run by the main Makefile include ../../Makefile.defs auto_gen= NAME=rocketmq.so THIRDPARTY=/mnt/vdd/kqbi2/3rdparty ROCKETMQ_ROOT_PATH=${THIRDPARTY}/rocketmq CXX?=g++ LD?=g++ LIBS+=-L$(LOCALBASE)/lib -L$(ROCKETMQ_ROOT_PATH)/lib/linux/x64 crocketmq.o -lstdc++ -lrocketmq DEFS+=-I$(LOCALBASE)/include -I${ROCKETMQ_ROOT_PATH}/include CXXFLAGS=$(CFLAGS:-Wno-deprecated option=) CXXFLAGS+=-Wno-write-strings -Wno-deprecated -Wno-unused-function -Wno-sign-compare -Wno-strict-aliasing include ../../Makefile.modules crocketmq.o: crocketmq.cpp crocketmq.h @echo "Compiling $<" $(CXX) -std=c++11 $(CXXFLAGS) $(CFLAGS) $(C_DEFS) $(DEFS) -c $< -o $@ rocketmq.so: crocketmq.o modclean: -@rm -f crocketmq.o crocketmq.d rocketmq_mod.o rocketmq_mod.d clean clean-modules: modclean proper realclean distclean maintainer-clean: modclean ``` There is no problem in compiling, but when running, the third-party librocketmq.so library cannot be found, and various export LD_LIBRARY_LIBRARY also does not work. ``` 0(13229) DEBUG: <core> [core/cfg.y:2053]: yyparse(): loading module rocketmq.so 0(13229) DEBUG: <core> [core/sr_module.c:516]: ksr_locate_module(): found module to load <lib64/kamailio/modules/rocketmq.so> 0(13229) DEBUG: <core> [core/sr_module.c:573]: ksr_load_module(): trying to load <lib64/kamailio/modules/rocketmq.so> 0(13229) ERROR: <core> [core/sr_module.c:591]: ksr_load_module(): could not open module <lib64/kamailio/modules/rocketmq.so>: librocketmq.so: cannot open shared object file: No such file or directory 0(13229) CRITICAL: <core> [core/cfg.y:3900]: yyerror_at(): parse error in config file /mnt/vdd/kqbi2/install/kamailio/etc/kamailio/kamailio.cfg, line 380, column 12-24: failed to load module ```

1 2

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