sr-dev October 2020

sr-dev@lists.kamailio.org

19 participants
526 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

3 years, 5 months

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

by George Diamantopoulos

3 years, 6 months

[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

3 years, 6 months

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

by Surendra Tiwari

3 years, 6 months

[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

3 years, 6 months

[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

3 years, 6 months

[kamailio/kamailio] [RFE]: Allow NULL for acc db_extra and multi_leg_info (#2531)

by Anthony Messina

### Description  Just as in #1378, allowing nullable entries for SQL would be appreciated in acc `db_extra` and acc `multi_leg_info`. ### Expected behavior Empty/NULL values should be inserted with `NULL`. For example, I can't create a `timestamp without time zone` to be used with multi-leg-accounting as follows. ``` modparam("acc", "multi_leg_info", "leg_dst_user=$avp(leg_dst_user);" "leg_dst_domain=$avp(leg_dst_domain);" "leg_sip_code=$avp(leg_sip_code);" "leg_time=$avp(leg_time);" "leg_to_tag=$avp(leg_to_tag)") $avp(leg_time)=$timef(%F %T) ``` #### Actual observed behavior Emplty/NULL values are inserted with `''` which fails as `''` is invalid input for a `timestamp without time zone` column. #### Log Messages  ``` db_postgres [km_dbase.c:266]: db_postgres_submit_query(): 0x7f26f7fb6cc8 PQsendQuery Error: ERROR: invalid input syntax for type timestamp: "" ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` ersion: kamailio 5.4.1-8.gitd43872c11e.fc32.2 (x86_64/linux) 09fd6a 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, 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: 09fd6a compiled on 00:00:00 Oct 22 2020 with gcc 10.2.1 ``` * **Operating System**:  ``` Linux host 5.8.15-201.fc32.x86_64 #1 SMP Thu Oct 15 15:56:44 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/2531

3 years, 6 months

[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

3 years, 6 months

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

by Olle E. Johansson

3 years, 6 months

[kamailio/kamailio] auth_radius + freeradius-client error (#2496)

by Paris

### Description I've been trying to setup kamailio with the latest freeradius-client. I've been using the docker image `kamailio/kamailio:5.3.1-jessie` adding the freeradius-client (latest github pool). However it seems that kamailio cannot create a proper radius request and fails with error `3(9) ERROR: auth_radius [sterman.c:264]: radius_authorize_sterman(): unable to add User-Name attribute` ### Troubleshooting #### Reproduction Install freeradius-client ``` git clone https://github.com/FreeRADIUS/freeradius-client.git \ && cd freeradius-client/ \ && ./configure \ && make \ && make install ``` Modify the `/usr/local/etc/radiusclient/dictionary` and append the following lines ``` $INCLUDE /etc/radiusclient/dictionary.sip $INCLUDE /etc/radiusclient/dictionary.kamailio # https://github.com/kamailio/kamailio/blob/master/src/modules/auth_radius/cf… ``` Configure auth_radius ``` loadmodule "auth_radius.so" loadmodule "misc_radius.so" modparam("auth_radius|misc_radius", "radius_config", "/usr/local/etc/radiusclient/radiusclient.conf") ``` #### Debugging Data I've went on the tried to debug the issue from the freeradius-client's point of view since it was easier to compile and iterate, and I've added various logs here and there to try and figure out what was wrong. From what I've seen, kamailio invokes `INIT_AV` to setup the `attrs` dictionary containing the dictionary attributes and matching values. https://github.com/kamailio/kamailio/blob/360e012d9d93c80b62b6e75bfac6e3340… I've traced the `rc_dict_findattr` and it seems that the library properly returns `User-Name` attribute with value `1`. However in the `radius_authorize_sterman` function https://github.com/kamailio/kamailio/blob/360e012d9d93c80b62b6e75bfac6e3340… the application tries to add the AVPs by invoking `rc_avpair_add` and passing `attr[...].v` value. I've logged the `rc_avpair_add` parameters passed and it seems that `attr[...].v` is not 1 as expected but 0, thus failing since 0 is an invalid attribute code. I modified freeradius-client to replace `attrid` with 1 if it were a 0 as a test, and it seems that all calls to `rc_avpair_add` by sterman.c are passing 0 as attribute value leading to a radius message like: ``` (0) User-Name = "test@localhost" (0) User-Name = "test" (0) User-Name = "localhost" (0) User-Name = "X3q5AV96t9WlJ5ZnoFFQQq/ftg7u+Mx5KRxYYIA=" (0) User-Name = "sip:localhost" (0) User-Name = "REGISTER" (0) User-Name = "bc6c2152d2e068e16f76188d69e66340" (0) User-Name = "\017" (0) User-Name = "test" (0) NAS-Port = 5060 (0) NAS-IP-Address = 10.10.10.4 ``` (As you can see pretty much all attributes are replaced by User-Name) It looks like `attrs` dictionary although initialized at `mod_init`, at a later stage is somehow corrupted or reset. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.1 (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_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 ``` * **Operating System**:  ``` Linux bea2be591c38 4.19.76-linuxkit #1 SMP Tue May 26 11:42:35 UTC 2020 x86_64 GNU/Linux ``` This is tested on a docker installation using `kamailio/kamailio:5.3.1-jessie` -- 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/2496

3 years, 6 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev October 2020