sr-dev November 2020

sr-dev@lists.kamailio.org

22 participants
311 discussions

[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

3 years, 5 months

[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

3 years, 5 months

[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

3 years, 5 months

[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

3 years, 5 months

[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

3 years, 5 months

[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

3 years, 5 months

[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

3 years, 5 months

[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

3 years, 5 months

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

3 years, 5 months

About VoNR

by LiuJian3 (刘俭)

Hi Thanks for your perfect project. I am a developer who want to enable a VoNR environment to evaluate our gNB product. I want to use 5GS and kamailio for this. But I don’t know whether kamailio support VoNR. Would you tell me？ Thanks a lot. Best regards. Jimmy 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到的文本。 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

3 years, 5 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2020