sr-dev November 2020

sr-dev@lists.kamailio.org

22 participants
312 discussions

[kamailio/kamailio] Deadlocks after ungracefully terminated TLS connections (#2395)

by Laszlo

This bug report concerns a Kamailio instance that's functioning as an edge proxy, accepting requests from clients over TLS and forwarding them to internal components over UDP. I've observed occasional "deadlocks" that all take place after there were connectivity issues between Kamailio and one or more of the clients (logging messages such as "tcp_send failed", "handle_tcpconn_ev(): connect x failed", "tcp_read_data(): error reading: Connection reset by peer"). Environment: * Ubuntu 16.04 * Kamailio 5.2.7 (5.2.7+ubuntu16.04) Relevant config: ``` # for TLS clients socket_workers=10 listen=tls:wan.ip:TLS_PORT # to be able to forward incoming TCP requests to UDP destinations socket_workers=10 listen=udp:wan.ip:TLS_PORT # for RPC commands socket_workers=2 listen=tcp:127.0.0.1:HTTP_PORT ``` ## Reproduction After a lot of trial and error, I've found a way to somewhat reproducibly trigger the problem using sipp. It involves setting up a large amount of simultaneous calls dialing into the edge proxy using TLS, to a destination UA that will answer the call and keep it open for a few seconds, then using `ctrl-c` to suddenly quit sipp which will ungracefully terminate the TCP/TLS connections. It takes me a couple of iterations to trigger the problem, e.g repeat until Kamailio starts failing: * start sipp * terminate sipp with ctrl-c * (quickly) restart sipp * terminate sipp * etc The amount of simultaneous calls has to be sufficiently large. In my environment I'm unable to reproduce the problem at all with 10-20 calls, while 50 calls always triggers the problem after a couple of iterations. Example sipp commandline: `sipp -nd -sf caller.xml -d 2000 -r 50 -l 500 -m 5000 -max_socket 1000 -t ln -tls_cert cert.crt -tls_key key.key kamailio.edge.proxy:5061` ## Failure mode 1 In one of the failure modes, it appears that all available TCP/TLS workers are permanently bricked; sipp's calls will simply timeout and not trigger any dialplan handling. Interestingly, even though I have dedicated workers for TLS (SIP client) and TCP (RPC commands), and my reproduction scenario doesn't connect to the HTTP_PORT at all, this failure scenario bricks the TCP (RPC) listeners as well; any curl requests to it will simply timeout as well. Kamailio will hang for a while on (systemd) restart. ## Failure mode 2 In another failure mode, it looks like the TCP workers are unaffected but the UDP perform forwarding to UDP destinations are broken. Sipp's calls will enter Kamailio, but forwarding (`relay()`) to the next hop will timeout even though the destination is functioning just fine. Since this failure mode doesn't break RPC I was able to enable debug logging: ``` 2020-07-07T17:26:58.770411+02:00 kamailio[24056]: INFO: From Customer 2020-07-07T17:26:58.770697+02:00 kamailio[24056]: DEBUG: pv [pv_trans.c:590]: tr_eval_string(): i=0 j=2 2020-07-07T17:26:58.770971+02:00 kamailio[24056]: DEBUG: dispatcher [dispatch.c:2055]: ds_manage_routes(): set [4] 2020-07-07T17:26:58.771248+02:00 kamailio[24056]: DEBUG: dispatcher [dispatch.c:2161]: ds_manage_routes(): using alg [0] hash [250849449] 2020-07-07T17:26:58.771535+02:00 kamailio[24056]: DEBUG: dispatcher [dispatch.c:2205]: ds_manage_routes(): selected [0-4-0/1] <sip:wan.ip:8065> 2020-07-07T17:26:58.771817+02:00 kamailio[24056]: DEBUG: dispatcher [dispatch.c:2226]: ds_manage_routes(): using first entry [4/1] 2020-07-07T17:26:58.772090+02:00 kamailio[24056]: DEBUG: dispatcher [dispatch.c:2269]: ds_manage_routes(): using entry [4/0] 2020-07-07T17:26:58.772362+02:00 kamailio[24056]: DEBUG: dispatcher [dispatch.c:2016]: ds_select_dst_limit(): selected target destinations: 2 2020-07-07T17:26:58.773001+02:00 kamailio[24056]: DEBUG: pv [pv_core.c:2611]: pv_set_force_sock(): trying to set send-socket to [udp:wan.ip:5061] 2020-07-07T17:26:58.773353+02:00 kamailio[24056]: DEBUG: <core> [core/socket_info.c:559]: grep_sock_info(): checking if host==us: 13==13 && [wan.ip] == [wan.ip] 2020-07-07T17:26:58.773829+02:00 kamailio[24056]: DEBUG: <core> [core/socket_info.c:566]: grep_sock_info(): checking if port 5061 (advertise 0) matches port 5061 2020-07-07T17:26:58.774122+02:00 kamailio[24056]: NOTICE: Relaying (cid: 1-9151(a)sipp.ip). 2020-07-07T17:26:58.774417+02:00 kamailio[24056]: DEBUG: siputils [checks.c:120]: has_totag(): no totag 2020-07-07T17:26:58.774708+02:00 kamailio[24056]: DEBUG: tm [t_lookup.c:1344]: t_newtran(): msg (0x7f69d1cc4980) id=1265/24056 global id=1265/24056 T start=(nil) 2020-07-07T17:26:58.774989+02:00 kamailio[24056]: DEBUG: tm [t_lookup.c:499]: t_lookup_request(): start searching: hash=43232, isACK=0 2020-07-07T17:26:58.775315+02:00 kamailio[24056]: DEBUG: tm [t_lookup.c:457]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK-9151-1-1] 2020-07-07T17:26:58.775612+02:00 kamailio[24056]: DEBUG: tm [t_lookup.c:682]: t_lookup_request(): no transaction found 2020-07-07T17:26:58.775908+02:00 kamailio[24056]: DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 0a5d4a8d13f9606523da9c4d193b2261 2020-07-07T17:26:58.776270+02:00 kamailio[24056]: DEBUG: <core> [core/dns_cache.c:3197]: dns_srv_sip_resolve(): (wan.ip, 0, 0), ip, ret=0 2020-07-07T17:26:58.776701+02:00 kamailio[24056]: DEBUG: <core> [core/msg_translator.c:1765]: check_boundaries(): no multi-part body 2020-07-07T17:26:58.777012+02:00 kamailio[24056]: DEBUG: <core> [core/msg_translator.c:2935]: create_via_hf(): id added: <;i=a701>, rcv proto=3 2020-07-07T17:26:58.777596+02:00 kamailio[24056]: DEBUG: tm [t_funcs.c:375]: t_relay_to(): new transaction forwarded 2020-07-07T17:26:58.777948+02:00 kamailio[24056]: DEBUG: <core> [core/receive.c:354]: receive_msg(): request-route executed in: 1927 usec 2020-07-07T17:26:58.778243+02:00 kamailio[24056]: DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 2020-07-07T17:26:58.779265+02:00 kamailio[24056]: message repeated 5 times: [ DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil)] 2020-07-07T17:26:58.779431+02:00 kamailio[24056]: DEBUG: <core> [core/xavp.c:507]: xavp_destroy_list(): destroying xavp list (nil) 2020-07-07T17:26:58.779753+02:00 kamailio[24056]: DEBUG: <core> [core/receive.c:458]: receive_msg(): cleaning up 2020-07-07T17:27:00.705303+02:00 kamailio[24053]: DEBUG: tm [t_reply.c:1266]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408 2020-07-07T17:27:00.705917+02:00 kamailio[24053]: DEBUG: tm [t_lookup.c:1041]: t_check_msg(): msg (0x7f69b1017e80) id=1264/24056 global id=1264/24056 T start=0x7f69b10167c0 2020-07-07T17:27:00.706187+02:00 kamailio[24053]: DEBUG: tm [t_lookup.c:1116]: t_check_msg(): T (0x7f69b10167c0) already found for msg (0x7f69b1017e80)! 2020-07-07T17:27:00.706533+02:00 kamailio[24053]: DEBUG: tmx [t_var.c:539]: pv_get_tm_reply_code(): reply code is <408> 2020-07-07T17:27:00.706879+02:00 kamailio[24053]: DEBUG: tm [t_lookup.c:1041]: t_check_msg(): msg (0x7f69b1017e80) id=1264/24056 global id=1264/24056 T start=0x7f69b10167c0 2020-07-07T17:27:00.707198+02:00 kamailio[24053]: DEBUG: tm [t_lookup.c:1116]: t_check_msg(): T (0x7f69b10167c0) already found for msg (0x7f69b1017e80)! 2020-07-07T17:27:00.707522+02:00 kamailio[24053]: DEBUG: tmx [t_var.c:594]: pv_get_tm_reply_reason(): reply reason is [Request Timeout] { "DSC": "tcp receiver (tls:wan.ip:5061) child=0", "IDX": 14, "PID": 24056 }, { "DSC": "slow timer", "IDX": 11, "PID": 24053 }, ``` Kamailio will restart (systemd) normally and everything will function normally again afterwards. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2395

4 years, 1 month

[kamailio/kamailio] dlgs v5.4.* dlgs_count wrong number (#2568)

by 狐狐

### Description Recently I upgraded kamailio to 5.4.2 using the dlgs module. No matter how many calls I make, the dlgs_count() and dlgs_tags_count() always return 1. After viewing the source code, I found the following bugs ### Troubleshooting #### Reproduction dlgs_init($fu,$tu,"data"); dlgs_update(); dlgs_count("any","eq","1"); and then make several calls, the dlgs_count always return 1. #### Debugging Data #### Log Messages ![image](https://user-images.githubusercontent.com/26111722/100606180-033c2c80-3344-11eb-9653-ebeefbeb70a7.png) nn ![image](https://user-images.githubusercontent.com/26111722/100606206-0c2cfe00-3344-11eb-98ba-1773046ec951.png) #### SIP Traffic ### Possible Solutions I find the `ki_dlgs_count` functions always return 1; ![image](https://user-images.githubusercontent.com/26111722/100605735-55308280-3343-11eb-9908-aa8f55e60f63.png) I modified the retrun value = 10086, then the `dlgs_count` always return 10086 ! ! I modified the return value = dlgs_count(msg, vfield, vop, vdata); then I found the dlgs_count always return 0; obviously there is still something wrong. then I run the dlgs_ht_dbg() in the dlgs_count (dlgs_records.c) and get some useful dbg log as above. as the picture shows，the slots[i].astats.c_init is always 0 or -1. I think maybe c_init is not initialized to 1 when dlgs_init . and I add the c_init's initial logic in the dlgs_add_items() then everything is fine ! ### Additional Information ``` Linux localhost.localdomain 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux kamailio version: kamailio 5.4.2 (x86_64/linux compiled on 20:13:39 Nov 9 2020 with gcc 4.8.5 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2568

4 years, 1 month

[kamailio/kamailio] lost: do not parse locationURI with indention spaces (#2569)

by sergey-safarov

### Description Examples of [RFC7840](https://tools.ietf.org/html/rfc7840#section-7) contains this response: ```xml <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationUriSet expires="2006-01-01T13:00:00.0Z"> <locationURI> https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o </locationURI> <locationURI> sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com </locationURI> </locationUriSet> <routingInformation xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"> <service serviceUri="urn:service:sos"> <dest>sip:112@example.com</dest> <dest>sips:112@example.com</dest> <dest>xmpp:112@example.com</dest> </service> </routingInformation> </locationResponse> ``` When the `lost` module receives such a response, then generate this message ``` http_client [functions.c:299]: curL_query_url(): Malformed URL used in http client (url: https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o ) lost [functions.c:325]: lost_held_function(): dereferencing location failed: 3 ``` This error is fixed when if I strip spaces in a string of `locationURI` element. ### Troubleshooting #### Reproduction Send xml eample from RFC as responce for `lost_held_query` function call. ### Possible Solutions Strip leading and trailing spaces of `locationURI` element. Maybe the required changes here https://github.com/kamailio/kamailio/blob/master/src/modules/lost/functions… ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` [root@ip-100-86-47-115 ~]# kamailio -v version: kamailio 5.5.0-dev3 (x86_64/linux) 0f572c 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: 0f572c compiled on 04:01:25 Nov 29 2020 with gcc 8.3.1 ``` * **Operating System**: ``` [root@ip-100-86-47-115 ~]# cat /etc/os-release NAME="CentOS Linux" VERSION="8 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="8" PLATFORM_ID="platform:el8" PRETTY_NAME="CentOS Linux 8 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:8" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-8" CENTOS_MANTISBT_PROJECT_VERSION="8" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="8" ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2569

4 years, 1 month

[kamailio/kamailio] dialog/dmq access dialog table by reference (#2570)

by pwakano

- Access to the d_table entries should be done by reference so there is no risk of race conditions to get and release the lock   #### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ x ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue #2547 #### Description  It was seen the access to the d_table was not being made by reference on the function dmq_send_all_dlgs. It was then leading to race conditions where the same entry could have its lock changed elsewhere and then a dead lock would occur. By checking the code in other places where the d_table is used, everywhere it is accessed by reference, this function was the only one not following this logic. Changes were done to have "entry" as a reference to d_table and not a copy. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2570 -- Commit Summary -- * dialog/dmq access dialog table by reference -- File Changes -- M src/modules/dialog/dlg_dmq.c (10) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2570.patch https://github.com/kamailio/kamailio/pull/2570.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2570

4 years, 1 month

[kamailio/kamailio] core: main - Protect async-signal-unsafe code in sig_usr() with SIG_DEBUG (#2127)

by Guillem Jover

#### Pre-Submission Checklist - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description The sig_usr() signal handler contains debug code to print memory usage and statistics that is not async-signal-safe, which can cause crashes or misbehavior. This code which only affects explicit SIGUSR1 signals on children processes, and is not guarded with the SIG_DEBUG macro. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2127 -- Commit Summary -- * core: main - Protect async-signal-unsafe code in sig_usr() with SIG_DEBUG -- File Changes -- M src/main.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2127.patch https://github.com/kamailio/kamailio/pull/2127.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2127

4 years, 1 month

[kamailio/kamailio] keep-alive refactoring: use case front-end proxy with backend registrar (#2565)

by sergey-safarov

### Description In my use case exists 1. pool of front-end proxies (all share some IPv4 address via AWS network load-balancer); 2. pool of backend registrars. I must: 1. send keepalive messages to endpoints when used INVITE, REGISTRAR, SUBSCRIBE methods via all possible transports (UDP/TSP/TLS/WS/WSS/SCTP) (like nat_keepalive function of nat_traversal module). Internally store record for this SIP URI with flag `ka_dynamic` and `Record-Route` headers from `180, 183, 200` responses as `Route`; 2. send keepalive messages on predefined SIP URI (like ka_add_destination of keepalive module). Internally store record for this SIP URI with flag `ka_static` and manually defined `Route` value; 3. when keepalive for cases above is failed, then added record into arrays: a. ka_invite_failed; b. ka_registrar_failed; c. ka_supscribe_failed; d. ka_invite_succcess; e. ka_registrar_success; f. ka_supscribe_success; 4. need to trigger `even route` function with initialized `xavp` params of a. of SIP URI endpoints; b. relevant array ID; c. dynamic or static flag of SIP URI record; d. `Record-Route` of SIP URI record; 5.If we have arrays for multiple arrays, then the `event router` function called multiple times. 6. the time period for `event route` calls must be configurable via module settings; 7. when executed `event route` I want to have abbility a. send a new registration message to the registrar node using saved `Route` header when OPTION is successful for the statically defined SIP URI; a. send registration expiration message to the registrar node from received `200` response; b. send the clear subscription message to the node from received `200` response; #### Actual observed behavior In current implementation `OPTIONS` keepalive messages send from different modules 1. usrloc; 2. keepalive; 3. nat_traversal; 4. nathelper All the above have limitations like: 1. no TCP/TLS/WS/WSS transport support (nat_traversal, nathelper); 2. no ability to define call `event-route` on failed (success) OPTIONS message (think all modules do not have such feature); 3. no ability to check response code before enabling keepalive (nat_traversal); 4. no ability to notify backend REGISTRAR/SUBSCRIPTION server (think all modules do not have such feature) about failed keepalive messages; #### What is expected >From my of view required: 1. some refactor of keepalive feature; 2. merge code from different modules into one and make other modules dependent; 3. implement the ability to notify backend REGISTRAR/SUBSCRIPTION servers of failed keepalive messages; 4. implement the ability to emulate registration when OPTION message success to SIP URI. Required on SBC to emulate customer PBX registration. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2565

4 years, 1 month

[kamailio/kamailio] DMQ workers stops processing msgs and consume all shmmem (#2547)

by pwakano

### Description Kamailio is configured to use the DMQ replication for dialog. When running a load test Kamailio DMQ workers eventually becomes unresponsive and stops processing DMQ messages. As a side effect the shm memory is fully consumed then SIP processing stops happening properly and everything else stops working due to that. ### Troubleshooting Investigation showed that the DMQ workers are locked in the dmq_send_all_dlgs. Debugging and studying the function it was identified that it is prone to data inconsistency because it uses a copy of the (d_table->entries)[index] and not a pointer to it. This gives a small window where a change in the d_table for that entry can occur and changing the lock information before the copy can actually get the lock making the process to get stuck in the lock get. There is a need for some expert to validate this conclusion. #### Reproduction Run a simple load test making calls at a rate of ~5 cps and keep around ~2000 calls connected all the time. A higher cps seems to make it easier to reproduce the problem. Adding network degradation to the environment makes the problem happens, but when running a tool such as SIPp for the load test, the retransmission can be forced by simply killing the SIPp instance receiving calls which will then force Kamailio to retransmit. #### Debugging Data ``` 7236 # DMQ WORKER #0 0x00007fa7bd760bf9 in syscall () from /lib64/libc.so.6 #1 0x00007fa793395484 in futex_get (lock=0x7ffd072acaa4) at ../../core/futexlock.h:121 #2 0x00007fa7933a123b in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657 (gdb) p entry $1 = {first = 0x7fa79f8540d0, last = 0x7fa79f8540d0, next_id = 86622, lock = {val = 2}, locker_pid = {val = 7211}, rec_lock_level = 0} (gdb) p &entry->lock $2 = (gen_lock_t *) 0x7ffd072acaa4 (gdb) p index $3 = 187 (gdb) p (d_table->entries)[index] $1 = {first = 0x0, last = 0x0, next_id = 86652, lock = {val = 0}, locker_pid = {val = 0}, rec_lock_level = 0} (gdb) p entry $2 = {first = 0x7fa79f8540d0, last = 0x7fa79f8540d0, next_id = 86622, lock = {val = 2}, locker_pid = {val = 7211}, rec_lock_level = 0} #3 0x00007fa79339cfa3 in dlg_dmq_handle_msg (msg=0x7fa79fca15c8, resp=0x7ffd072aceb0, node=0x7fa79ee93cb8) at dlg_dmq.c:391 #4 0x00007fa793f3bb98 in worker_loop (id=0) at worker.c:113 #5 0x00007fa793f39314 in child_init (rank=0) at dmq.c:296 #6 0x00000000005990e8 in init_mod_child (m=0x7fa7bc735d98, rank=0) at core/sr_module.c:780 #7 0x0000000000598d5d in init_mod_child (m=0x7fa7bc736b00, rank=0) at core/sr_module.c:776 #8 0x0000000000598d5d in init_mod_child (m=0x7fa7bc737038, rank=0) at core/sr_module.c:776 #9 0x0000000000598d5d in init_mod_child (m=0x7fa7bc738eb8, rank=0) at core/sr_module.c:776 #10 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73a0e0, rank=0) at core/sr_module.c:776 #11 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73ab70, rank=0) at core/sr_module.c:776 #12 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73d8e0, rank=0) at core/sr_module.c:776 #13 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73e720, rank=0) at core/sr_module.c:776 #14 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73f1b8, rank=0) at core/sr_module.c:776 #15 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73fd08, rank=0) at core/sr_module.c:776 #16 0x0000000000598d5d in init_mod_child (m=0x7fa7bc740128, rank=0) at core/sr_module.c:776 #17 0x0000000000598d5d in init_mod_child (m=0x7fa7bc7409d0, rank=0) at core/sr_module.c:776 #18 0x0000000000598d5d in init_mod_child (m=0x7fa7bc7414d8, rank=0) at core/sr_module.c:776 #19 0x0000000000598d5d in init_mod_child (m=0x7fa7bc742cd8, rank=0) at core/sr_module.c:776 #20 0x0000000000598d5d in init_mod_child (m=0x7fa7bc742fc8, rank=0) at core/sr_module.c:776 #21 0x0000000000598d5d in init_mod_child (m=0x7fa7bc744ed0, rank=0) at core/sr_module.c:776 #22 0x0000000000598d5d in init_mod_child (m=0x7fa7bc745920, rank=0) at core/sr_module.c:776 #23 0x0000000000598d5d in init_mod_child (m=0x7fa7bc748d60, rank=0) at core/sr_module.c:776 #24 0x0000000000598d5d in init_mod_child (m=0x7fa7bc7498f8, rank=0) at core/sr_module.c:776 #25 0x0000000000599887 in init_child (rank=0) at core/sr_module.c:825 #26 0x000000000042ab2d in main_loop () at main.c:1763 #27 0x0000000000433a96 in main (argc=12, argv=0x7ffd072aeb48) at main.c:2856 7237 # DMQ WORKER #0 0x00007fa7bd760bf9 in syscall () from /lib64/libc.so.6 #1 0x00007fa793395484 in futex_get (lock=0x7ffd072acaa4) at ../../core/futexlock.h:121 #2 0x00007fa7933a123b in dmq_send_all_dlgs (dmq_node=0x0) at dlg_dmq.c:657 (gdb) p entry $1 = {first = 0x7fa79f38bdb8, last = 0x7fa79f38bdb8, next_id = 15672, lock = {val = 2}, locker_pid = {val = 7221}, rec_lock_level = 1} (gdb) p &entry->lock $2 = (gen_lock_t *) 0x7ffd072acaa4 (gdb) p index $1 = 402 (gdb) p (d_table->entries)[index] $1 = {first = 0x0, last = 0x0, next_id = 15702, lock = {val = 0}, locker_pid = {val = 0}, rec_lock_level = 0} (gdb) p entry $4 = {first = 0x7fa79f38bdb8, last = 0x7fa79f38bdb8, next_id = 15672, lock = {val = 2}, locker_pid = {val = 7221}, rec_lock_level = 1} (gdb) p &(d_table->entries)[index]->lock $5 = (gen_lock_t *) 0x7fa79ec44e2c (gdb) p &entry->lock $6 = (gen_lock_t *) 0x7ffd072acaa4 #3 0x00007fa79339cfa3 in dlg_dmq_handle_msg (msg=0x7fa79f9e4d90, resp=0x7ffd072aceb0, node=0x7fa79ee93cb8) at dlg_dmq.c:391 #4 0x00007fa793f3bb98 in worker_loop (id=1) at worker.c:113 #5 0x00007fa793f39314 in child_init (rank=0) at dmq.c:296 #6 0x00000000005990e8 in init_mod_child (m=0x7fa7bc735d98, rank=0) at core/sr_module.c:780 #7 0x0000000000598d5d in init_mod_child (m=0x7fa7bc736b00, rank=0) at core/sr_module.c:776 #8 0x0000000000598d5d in init_mod_child (m=0x7fa7bc737038, rank=0) at core/sr_module.c:776 #9 0x0000000000598d5d in init_mod_child (m=0x7fa7bc738eb8, rank=0) at core/sr_module.c:776 #10 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73a0e0, rank=0) at core/sr_module.c:776 #11 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73ab70, rank=0) at core/sr_module.c:776 #12 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73d8e0, rank=0) at core/sr_module.c:776 #13 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73e720, rank=0) at core/sr_module.c:776 #14 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73f1b8, rank=0) at core/sr_module.c:776 #15 0x0000000000598d5d in init_mod_child (m=0x7fa7bc73fd08, rank=0) at core/sr_module.c:776 #16 0x0000000000598d5d in init_mod_child (m=0x7fa7bc740128, rank=0) at core/sr_module.c:776 #17 0x0000000000598d5d in init_mod_child (m=0x7fa7bc7409d0, rank=0) at core/sr_module.c:776 #18 0x0000000000598d5d in init_mod_child (m=0x7fa7bc7414d8, rank=0) at core/sr_module.c:776 #19 0x0000000000598d5d in init_mod_child (m=0x7fa7bc742cd8, rank=0) at core/sr_module.c:776 #20 0x0000000000598d5d in init_mod_child (m=0x7fa7bc742fc8, rank=0) at core/sr_module.c:776 #21 0x0000000000598d5d in init_mod_child (m=0x7fa7bc744ed0, rank=0) at core/sr_module.c:776 #22 0x0000000000598d5d in init_mod_child (m=0x7fa7bc745920, rank=0) at core/sr_module.c:776 #23 0x0000000000598d5d in init_mod_child (m=0x7fa7bc748d60, rank=0) at core/sr_module.c:776 #24 0x0000000000598d5d in init_mod_child (m=0x7fa7bc7498f8, rank=0) at core/sr_module.c:776 #25 0x0000000000599887 in init_child (rank=0) at core/sr_module.c:825 #26 0x000000000042ab2d in main_loop () at main.c:1763 #27 0x0000000000433a96 in main (argc=12, argv=0x7ffd072aeb48) at main.c:2856 7211 (gdb) bt #0 0x00007fa7bd7677d3 in __recvfrom_nocancel () from /lib64/libc.so.6 #1 0x00000000004d6a45 in udp_rcv_loop () at core/udp_server.c:457 #2 0x0000000000429d47 in main_loop () at main.c:1683 #3 0x0000000000433a96 in main (argc=12, argv=0x7ffd072aeb48) at main.c:2856 7221 #0 0x00007fa7bd7677d3 in __recvfrom_nocancel () from /lib64/libc.so.6 #1 0x00000000004d6a45 in udp_rcv_loop () at core/udp_server.c:457 #2 0x0000000000429d47 in main_loop () at main.c:1683 #3 0x0000000000433a96 in main (argc=12, argv=0x7ffd072aeb48) at main.c:2856 ``` ### Possible Solutions Suggested patch (was not compiled and tested yet): ``` diff --git a/src/modules/dialog/dlg_dmq.c b/src/modules/dialog/dlg_dmq.c index a5628f4..b681759 100644 --- a/src/modules/dialog/dlg_dmq.c +++ b/src/modules/dialog/dlg_dmq.c @@ -646,22 +646,22 @@ int dmq_send_all_dlgs(dmq_node_t* dmq_node) { int index; - dlg_entry_t entry; + dlg_entry_t *entry; dlg_cell_t *dlg; LM_DBG("sending all dialogs \n"); for(index = 0; index< d_table->size; index++){ /* lock the whole entry */ - entry = (d_table->entries)[index]; - dlg_lock( d_table, &entry); + entry = &(d_table->entries)[index]; + dlg_lock( d_table, entry); - for(dlg = entry.first; dlg != NULL; dlg = dlg->next){ + for(dlg = entry->first; dlg != NULL; dlg = dlg->next){ dlg->dflags |= DLG_FLAG_CHANGED_PROF; dlg_dmq_replicate_action(DLG_DMQ_UPDATE, dlg, 0, dmq_node); } - dlg_unlock( d_table, &entry); + dlg_unlock( d_table, entry); } return 0; ``` ### Additional Information kamailio 5.4.2 (x86_64/linux) 5bd72f * **Operating System**: ``` Centos 7 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 25 17:23:54 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2547

4 years, 1 month

[kamailio/kamailio] Expand the list of required default 3rd party libraries for Kamailio (#969)

by Olle E. Johansson

(from devmeeting #Fosdem) - adding new dependencies as core dependencies - Curl - libssl - uuid - libunistring - libxml2 Any other candidates? They have to be libraries that are commonly installed on most Linux/Unix system. This would mean that a lot of more modules will be built by default, like TLS, HTTP_CLIENT, WEBSOCKET. We may also look over the names of the packages/groups for the build system and linux distros -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/969

4 years, 1 month

[kamailio/kamailio] Dynamic Routing Module: SRV resolution does not work in NAPTR is turned off. (#2553)

by zvoneos

### Description >From what I experience dynamic routing (drouting) module is not supporting SRV resolution if NAPTR is turned off (dns_try_naptr=no). Is this intentional to not have SRV if NAPTR is turned off? Or some special format of entry is expected for SRV records in gateways table? I've tried with just **domain** and **_sip._udp.domain** but it it the same. #### Reproduction 1. Use Dynamic routing module 2. set dns_try_naptr=no 3. insert gateway with SRV domain name in dynamic routing gateways table. 4. execute kamcmd drouting.reload 5. in the log of the kamailio is the error: ERROR: drouting [routing.c:337]: add_dst(): cannot resolve <domainexample> ### Possible Solutions Upon reload of drouting tables, dynamic routing tries to add destinations and resolve them: https://github.com/kamailio/kamailio/blob/08a9ed3d136c861f990e4f63c2c0544e0… But, since port that is sent is NULL, SRV is being skipped later on. It seems that SRV would be executed if port would be 0 instead of NULL. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.9 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_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 4.9.2 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2553

4 years, 1 month

kamailio SIP and RTP proxy

by Patrick Leybag

Hi, Can someone help me? I self host a kamailio using my raspberry pi as a load balancer for my two asterisk servers and get a did number. when I call to my DID number it points to my kamailio and kamailio will distribute to asterisk server but the call has no audio. I tried port forwarding ports 5060 for SIP and 10000-20000 for RTP but it still does not work. Any help is much appreciated. Thank you in advance

4 years, 1 month

← Newer
1
...
6
7
8
9
10
11
12
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2020