sr-dev October 2020

sr-dev@lists.kamailio.org

19 participants
528 discussions

[kamailio/kamailio] dispatcher: algorithm 13 latency optimized round-robin with failover (#2493)
by Julien Chavanton 19 Nov '20

19 Nov '20

#### Type Of Change - [x] New feature (non-breaking change which adds new functionality) #### Checklist: - [x] Tested changes locally #### Description Previously discussed in the mailing list : **“13” - latency optimized routing mode, the lowest latency gets higher priority (serial forking ordered by priority, ds_ping_latency_stats is required).** - The algorithm will load balance using round-robin prioritizing the gateways with the highest priority. - The priority will be lowered by 1 point every time the latency ms is as high as the priority. Using this simple formula : ADJUSTED_PRIORITY = PRIORITY - (ESTIMATED_LATENCY/PRIORITY) GATEWAY | PRIORITY | ESTIMATED_LATENCY | ADJUSTED_PRIORITY | LOAD DISTRIBUTION -- | -- | -- | -- | -- 1 | 30 | 21 | 30 | 33% 2 | 30 | 91 | 27 | 0% 3 | 30 | 61 | 28 | 0% 4 | 30 | 19 | 30 | 33% 5 | 30 | 32 | 29 | 0% 6 | 30 | 0 | 30 | 33% 7 | 30 | 201 | 24 | 0% You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2493 -- Commit Summary -- * dispatcher: algorithm 13 -- File Changes -- M src/modules/dispatcher/dispatch.c (43) M src/modules/dispatcher/dispatch.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2493.patch https://github.com/kamailio/kamailio/pull/2493.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/2493

4 19

[kamailio/kamailio] Kamailio on RHEL/Centos 8 issue with SCTP associations created towards endpoint's primary and secondary IP addresses (#2429)
by Piotr Grabowski 19 Nov '20

19 Nov '20

### Description Kamailio is unable to create a SCTP association to IP address that is reachable normally when dispatcher.list is configured as following: ``` 760320003 sip:10.59.144.2:5063;transport=sctp 9 0 dstid=1 760320003 sip:10.59.144.130:5063;transport=sctp 9 0 dstid=1 ``` 10.59.144.2 and 10.59.144.130 are IPs of same endpoint treated as primary and secondary, Kamailio can't send probe (OPTIONS requests) as SCTP association can't be created. Issue doesn't exist on RHEL/Centos 6. ### Troubleshooting #### Reproduction Use previously mentioned dispatcher list with changed IP addresses to match local configuration. SCTP part of kamailio.cfg ``` # if not OS default is used #modparam("sctp", "sctp_socket_rcvbuf", 14096) #modparam("sctp", "sctp_socket_sndbuf", 14096) # Number of milliseconds before an unsent message/chunk is dropped. modparam("sctp", "sctp_send_ttl", 10000) modparam("sctp", "sctp_autoclose", 300) # How many times to attempt re-sending a message on a re-opened association, if the sctp stack did give up sending it (it's not related to sctp protocol level retransmission). Useful to improve reliability with peers that reboot/restart or fail over to another machine. modparam("sctp", "sctp_send_retries", 1) modparam("sctp", "sctp_srto_initial", 200) modparam("sctp", "sctp_srto_max", 250) modparam("sctp", "sctp_srto_min", 150) modparam("sctp", "sctp_asocmaxrxt", 4) modparam("sctp", "sctp_init_max_attempts", 3) modparam("sctp", "sctp_init_max_timeo", 1000) modparam("sctp", "sctp_hbinterval", 1000) modparam("sctp", "sctp_pathmaxrxt", 2) modparam("sctp", "sctp_sack_delay", 10) modparam("sctp", "sctp_sack_freq", 1) modparam("sctp", "sctp_max_burst", 4) ``` #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: dispatcher [dispatch.c:3234]: ds_ping_result_helper(): probing set, but not mode DS_PROBE_INACTIVE Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: dispatcher [dispatch.c:3268]: ds_ping_set(): probing set #760320003, URI sip:10.59.144.2:5063;transport=sctp Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: dispatcher [dispatch.c:3293]: ds_ping_set(): Default ping_from: sip:siplb@sdp.t-mobile.at Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: tm [uac.c:435]: t_uac_prepare(): next_hop=<sip:10.59.144.2:5063;transport=sctp> Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: <core> [core/resolve.c:1244]: srv_sip_resolvehost(): 10.59.144.2:5063 proto=4 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2281]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.130:5063: SCTP_ADDR_ADDED: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: <core> [core/resolve.c:1356]: srv_sip_resolvehost(): returning 0xa7c280 (10.59.144.2:5063 proto=4) Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: tm [uac.c:158]: dlg2hash(): hashid 27287 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2281]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.130:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2280]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.130:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: tm [uac.c:652]: send_prepared_request_impl(): uac: 0x7fbf4eb4e5b8 branch: 0 to 10.59.144.2:5063 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2294]: DEBUG: tm [../../core/onsend.h:69]: run_onsend(): required parameters are not available - ignoring Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2282]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.2:5063: SCTP_ADDR_ADDED: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2278]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.2:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2282]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.2:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2285]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.2:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2283]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.130:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2279]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.130:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:13 sdp-lbref02 /usr/sbin/kamailio[2279]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.2:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:14 sdp-lbref02 /usr/sbin/kamailio[2280]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.2:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:14 sdp-lbref02 /usr/sbin/kamailio[2278]: DEBUG: sctp [sctp_server.c:2317]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_PEER_ADDR_CHANGE: 10.59.144.130:5063: SCTP_ADDR_MADE_PRIM: assoc_id 0 Aug 6 18:19:15 sdp-lbref02 /usr/sbin/kamailio[2285]: DEBUG: sctp [sctp_server.c:2340]: sctp_handle_notification(): sctp notification from 10.59.144.130:5063 on sdp-lbref02-sigtran01:5060: SCTP_ASSOC_CHANGE: SCTP_CANT_STR_ASSOC: assoc_id 0, ostreams 0, istreams 0 Aug 6 18:19:15 sdp-lbref02 /usr/sbin/kamailio[2282]: DEBUG: sctp [sctp_server.c:2340]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_ASSOC_CHANGE: SCTP_CANT_STR_ASSOC: assoc_id 0, ostreams 0, istreams 0 Aug 6 18:19:15 sdp-lbref02 /usr/sbin/kamailio[2285]: DEBUG: sctp [sctp_server.c:2299]: sctp_handle_notification(): sctp notification from 10.59.144.2:5063 on sdp-lbref02-sigtran01:5060: SCTP_SEND_FAILED: error 0, assoc_id 0, flags 0 Aug 6 18:19:15 sdp-lbref02 /usr/sbin/kamailio[2285]: DEBUG: sctp [sctp_server.c:2098]: sctp_handle_send_failed(): sctp: RETRY-ing (1) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  Issue is gone when one of IP addresses is removed from dispatcher.list. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` kamailio -v version: kamailio 5.3.5 (x86_64/linux) 9e70e8 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: 9e70e8 compiled on 12:22:26 Jun 22 2020 with gcc 8.3.1 ``` Also tested latest 5.2 and 5.4 * **Operating System**:  ``` [root@sdp-lbref02 ~]# uname -a Linux sdp-lbref02 4.18.0-193.14.3.el8_2.x86_64 #1 SMP Mon Jul 20 15:02:29 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux [root@sdp-lbref02 ~]# cat /etc/redhat-release Red Hat Enterprise Linux release 8.2 (Ootpa) ``` -- 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/2429

4 6

[kamailio/kamailio] Branch ordering behavior changed since v5.3.4 (#2449)
by Cindy Leung 19 Nov '20

19 Nov '20

5 20

[kamailio/kamailio] topos module seems to break re-SUBSCRIBE routing to downstream destinations (#1724)
by George Diamantopoulos 18 Nov '20

18 Nov '20

2 4

[kamailio/kamailio] uri_restore_rcv_alias() tried twice for local request (#2014)
by Alex Hermann 18 Nov '20

18 Nov '20

### 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

2 3

[kamailio/kamailio] rtpengine: stats for rtpengine command and reply from rtpengine (#1699)
by Surendra Tiwari 18 Nov '20

18 Nov '20

2 2

[kamailio/kamailio] 100% CPU usage after NTP date update (#2046)
by Benjamin Marty 18 Nov '20

18 Nov '20

#### 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

2 3

[kamailio/kamailio] commit 0436af5abd8b73e breaks startup for jsonrpcs module (#2391)
by Henning Westerholt 18 Nov '20

18 Nov '20

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 25

[kamailio/kamailio] [RFE]: Allow NULL for acc db_extra and multi_leg_info (#2531)
by Anthony Messina 15 Nov '20

15 Nov '20

### 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 6

[kamailio/kamailio] RR param static buffer not emptied, when using record_route_advertised_address() (#2486)
by thomas-lentz 13 Nov '20

13 Nov '20

### 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

2 3

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev October 2020