sr-dev September 2020

sr-dev@lists.kamailio.org

12 participants
270 discussions

[kamailio/kamailio] Branch ordering behavior changed since v5.3.4 (#2449)

by Cindy Leung

### Description I'm appending two contacts / branches upon receiving a call. This is a snippet of the config I'm using to debug: ``` xlog ("=== branch 0: $(branch(uri)[0]), $(branch(q)[0])\n"); xlog ("=== branch 1: $(branch(uri)[1]), $(branch(q)[1])\n"); revert_uri(); t_load_contacts(); while (t_next_contacts()) { xlog ("==== $ru\n"); } ``` We expect that the branches are rearranged by weight. When t_next_contacts() is called, the $ru is being rewritten with the branch having the highest q value. This behavior changed after upgrading to v5.4.0. The order of the branches is now being reversed. ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages In v5.4.0, this is what we're seeing in the logs ``` ERROR: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: tm [t_serial.c:526]: t_load_contacts(): load_contact mode not selected, using: 0 DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: tm [t_serial.c:340]: ki_t_load_contacts_mode(): nr_branches is 2 DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7fcbe3103e20 DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: tm [t_serial.c:890]: ki_t_next_contacts(): Appending branch uri-'sip:1001@gateway1.carrierB.com;transport=tcp' dst-'' path-'' inst-'' ruid-'' location_ua-'' DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7fcbe3103b68 ERROR: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: ==== sip:1001@carrierB DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: <core> [core/xavp.c:539]: xavp_destroy_list(): destroying xavp list 0x7fcbe3103890 ERROR: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: ==== sip:1001@gateway2.carrierB.com;transport=udp DEBUG: IBG_LOG: sipp-ci1-20200819163846-1-22(a)172.18.1.21: tm [t_serial.c:627]: ki_t_next_contacts(): no contacts in contacts_avp - we are done! ``` This was the behavior in v.5.3.4 ``` ERROR: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: === branch 0: sip:1001@gateway2.carrierB.com;transport=udp, 200 ERROR: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: === branch 1: sip:1001@gateway1.carrierB.com;transport=tcp, 300 DEBUG: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: tm [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 2 DEBUG: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7f55bdf0c1d8 ERROR: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: ==== sip:1001@gateway1.carrierB.com;transport=tcp DEBUG: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7f55bdf0bf00 ERROR: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: ==== sip:1001@gateway2.carrierB.com;transport=udp DEBUG: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: <core> [core/xavp.c:529]: xavp_destroy_list(): destroying xavp list 0x7f55bdf0bc28 ERROR: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: ==== sip:1001@carrierB DEBUG: IBG_LOG: sipp-ci1-20200819172941-1-22(a)172.18.1.21: tm [t_serial.c:460]: ki_t_next_contacts(): no contacts in contacts_avp - we are done! ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- 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/2449

4 years, 1 month

[kamailio/kamailio] topos module seems to break re-SUBSCRIBE routing to downstream destinations (#1724)

by George Diamantopoulos

4 years, 1 month

[kamailio/kamailio] uri_restore_rcv_alias() tried twice for local request (#2014)

by Alex Hermann

### Description While debugging an issue with locally generated in-dialog requests I stumbled upon some weirdness with the alias functionality from the nathelper module. The dialog modules tries to handle an alias parameter when sending an in-dialog request by calling ```uri_restore_rcv_alias()``` in the function ```build_dlg_t()```. A few instructions later, the same is attempted by the tm module in the function ```req_within()```. It seems to me that the attempt by the dialog module is redundant and can be removed. And while at it, IMHO it should be removed from the tm module too. This is functionality introduced by the nathelper module. Nowhere in the documentation it is mentioned there is some automatic handling of the alias parameter. If handling is needed for local requests, the script writer can call ```handle_uri_alias()``` from within local_route. If the functionality has to stay, may I suggest that the code in the nathelper module makes use of the ```uri_restore_rcv_alias()``` function instead of having its own duplicate implementation. Less maintenance, easier debugging. -- 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/2014

4 years, 1 month

[kamailio/kamailio] rtpengine: stats for rtpengine command and reply from rtpengine (#1699)

by Surendra Tiwari

4 years, 1 month

[kamailio/kamailio] 100% CPU usage after NTP date update (#2046)

by Benjamin Marty

#### Reproduction Install newest Kamailio 5.2. Change date e.g. 2 Years into the future. (Make sure you have no daemon running which prohibits those operations): ``` sudo date -s "2014-12-25 $(date +%H:%M:%S)" ``` ``` sudo date -s "2016-12-25 $(date +%H:%M:%S)" ``` Kamailio now uses the whole CPU to do stuff: ``` top - 08:10:35 up 14 days, 1:29, 2 users, load average: 3.77, 1.83, 1.05 Tasks: 212 total, 11 running, 201 sleeping, 0 stopped, 0 zombie %Cpu(s): 95.9 us, 1.5 sy, 2.2 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st MiB Mem : 926.1 total, 116.3 free, 382.5 used, 427.3 buff/cache MiB Swap: 100.0 total, 40.4 free, 59.6 used. 423.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13264 root 20 0 89720 3944 2676 R 44.9 0.4 0:05.15 kamailio 13266 root 20 0 89720 4000 2736 R 37.3 0.4 0:04.63 kamailio 13267 root 20 0 89720 4912 3488 R 36.0 0.5 0:04.37 kamailio 13270 root 20 0 89720 4540 3240 R 36.0 0.5 0:05.85 kamailio 13269 root 20 0 89720 4000 2736 R 34.7 0.4 0:04.81 kamailio 13265 root 20 0 89720 3944 2680 R 34.4 0.4 0:04.61 kamailio 13261 root 20 0 89720 3952 2676 R 32.2 0.4 0:04.44 kamailio 13262 root 20 0 89720 3944 2676 R 31.8 0.4 0:04.72 kamailio 13256 root 20 0 89720 4752 3540 R 30.3 0.5 0:07.04 kamailio 13268 root 20 0 89720 4000 2736 R 30.3 0.4 0:04.49 kamailio 18021 root 20 0 40116 11884 5728 D 13.7 1.3 0:01.11 apt-get ``` There are multiple mailing list entries regarding this issue: https://lists.kamailio.org/pipermail/sr-users/2015-October/090465.html https://lists.kamailio.org/pipermail/sr-users/2015-November/090487.html https://lists.kamailio.org/pipermail/sr-users/2019-June/105967.html https://lists.kamailio.org/pipermail/sr-users/2019-August/106428.html I was able to get rid of the issue with uncommenting the mentioned part of the code. But I'm quite sure that's not a fix :) ![image](https://user-images.githubusercontent.com/11159719/63680341-b6d67880-c7f3-11e9-825b-529e7ec26b2e.png) -- 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/2046

4 years, 1 month

[kamailio/kamailio] commit 0436af5abd8b73e breaks startup for jsonrpcs module (#2391)

by Henning Westerholt

The commit 0436af5abd8b73e breaks startup for jsonrpcs module. Logs: ``` Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:358]: jsonrpc_dgram_init_server(): failed to change the owner/group for /var/run/kamailio/kamailio_rpc.sock to 33.0;Operation not permitted[1] Jul 5 10:04:41 kam01 kamailio[4951]: CRITICAL: jsonrpcs [jsonrpcs_sock.c:423]: jsonrpc_dgram_init_socks(): initializing datagram server function returned error Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:246]: jsonrpc_dgram_mod_init(): init datagram sockets function failed Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_mod.c:1150]: mod_init(): cannot initialize datagram transport Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: <core> [core/sr_module.c:849]: init_mod(): Error while initializing module jsonrpcs (/usr/lib/x86_64-linux-gnu/kamailio/modules/jsonrpcs.so) ``` Relevant cfg: ``` loadmodule "jsonrpcs.so" modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "dgram_user", "www-data") modparam("jsonrpcs", "dgram_group", "root") modparam("jsonrpcs", "transport", 7) ``` Previously Kamailio was started as root, and then configured with -u $USER and -g $GROUP to drop privileges to the lower user/group. During startup Kamailio could create the socket with the correct permissions. The mentioned commit changes this to: start Kamailio directly as user Kamailio and group Kamailio, which don't have privileges create the sockets with the correct permissions. Not sure about the motivation about this change, so I don't want to simple revert it. Maybe @sergey-safarov or other developers can comment. -- 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/2391

4 years, 1 month

[kamailio/kamailio] RR param static buffer not emptied, when using record_route_advertised_address() (#2486)

by thomas-lentz

### Description When specifying a _record_route_advertised_address()_ before using the uac_replace function (for changing the FROM and TO Header field URIs), the rr param static buffer doesn't get emptied and a fallowing CALL (not a request in the same call) contains the rr params of the first call placed after restarting kamailio (to get the buffer resetted). ### Troubleshooting Restarting kamailio will reset the wrong buffer pointer and gets you another functioning call. Alternatively place the _record_route_advertised_address()_ after using uac_replace function. #### Reproduction use record_route_advertised_address() before doing a uac_replace. This will get the vst and vsf parameters doubled in the rr of the second call after kamailio is restarted. When you place a call the first call proxied will carry only one set of vsf & vst parameters in the RR. The second call will carry the vst & vsf of the first call and a set of vst & vsf of the second call. If the uac_replace is replacing the same URIs the contents of the two sets of vsf and vst parameters in the RR Header will be identical. uac.so config: loadmodule "uac.so" modparam("uac", "restore_mode","auto"); #### Analysis record_route() empties the RR param static buffer as follows, if it contains other message's params: if (rr_param_buf.len && rr_param_msg!=_m->id) { /* rr_params were set for a different message -> reset buffer */ rr_param_buf.len = 0; } But unfortunately, record_route_advertised_address() / record_route_preset() does not do this – it does NOT check/clean the buffer before adding RR. So if the static buffer contains old entries (e.g. from an old call's subsequent request), wrong rr parameters are added. This happens with uac module: restore_uri() is called for subsequent requests (via callback). restore_uri() calls (unnecessarily): if ( uac_rrb.add_rr_param(msg, &add_to_rr)!=0 ) { LM_ERR("add rr param failed\n"); goto failed; } So, if record_route has not yet been performed at this stage, add_rr_param() adds an entry to the static rr param buffer. (for subsequent request, record_route won't be performed) If, for a following call, record_route_advertised_address() / record_route_preset() is called, the buffer is not checked/emptied, and old/wrong rr params are added.--> ``` #### SIP Traffic ``` Record-Route URI [truncated]: sip:my.node.com;transport=tls;r2=on;ftag=2ccb63ad;lr;vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU-;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ- Record-Route Host Part: my.node.com Record-Route URI parameter: transport=tls Record-Route URI parameter: r2=on Record-Route URI parameter: ftag=2ccb63ad Record-Route URI parameter: lr Record-Route URI parameter: vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU- Record-Route URI parameter: vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ-- Record-Route URI parameter: vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ-- Record-Route URI parameter: vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU- Record-Route URI parameter: did=4a8.56a2 URI, vsf & vst anonymised ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.7 (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, 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 8.3.0 ``` * **Operating System**: ``` 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) 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/2486

4 years, 1 month

[kamailio/kamailio] NATHELPER: fix_nated_sdp does not support a=rtcp headers (#2459)

by Olle E. Johansson

### Description fix_nated_sdp() function with an IP address as argument supports modifying the media line and the connection line but not a=rtcp. It would be helpful if it did that line too. ### Expected behavior a=rtcp:<port> IN ip4 <new IP> #### Actual observed behavior No modification -- 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/2459

4 years, 1 month

[kamailio/kamailio] add rtpproxy in kamailio/kamailio-ci:master-alpine (#2109)

by Gaurav Bmotra

hi can any one help me to add rtpproxy in kamailio/kamailio-ci:master-alpine thank you -- 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/2109

4 years, 1 month

[kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)

by pwakano

kamailio-sipcapture-daemon-config can't be installed because it depends on the kamailio-sipcapture package, which can't be found...  Use the http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentO… repo and try to install the kamailio-sipcapture-daemon-config. The dependency can't be resolved and so the package does not install. It is not clear if the dependency is missing or if it is not valid. ``` # yum install kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au Resolving Dependencies --> Running transaction check ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.1-1.el7.centos will be installed --> Processing Dependency: kamailio-sipcapture = 5.2.1 for package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 (home_kamailio_v5.2.x-rpms) Requires: kamailio-sipcapture = 5.2.1 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # yum deplist kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au package: kamailio-sipcapture-daemon-config.x86_64 5.2.1-1.el7.centos dependency: /bin/sh provider: bash.x86_64 4.2.46-31.el7 dependency: kamailio-sipcapture = 5.2.1 Unsatisfied dependency ```      * **Operating System**:  ``` # uname -a Linux voice-conn-kamailio-1 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ``` -- 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/1861

4 years, 2 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev September 2020