sr-dev July 2020

sr-dev@lists.kamailio.org

26 participants
391 discussions

[kamailio/kamailio] support for a kamailio-dev package for external modules (#1752)
by Victor Seva 23 Nov '23

23 Nov '23

>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902944 > Hi! > > We've got several local kamailio modules, and it would be nice to be > able to build them separately and not have to hook them into the > kamailio source and build systems. I suppose others might find this > useful too. > > I started pondering what adding support for this would imply, and I > think the first step is whether this is something you think upstream > and you'd be happy … [View More]

5 7

[kamailio/kamailio] TLS: Consider what's new and what's supported in OpenSSL (#1878)
by Olle E. Johansson 23 Nov '23

23 Nov '23

<!-- Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for feature requests. If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list: * http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list: * http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev … [View More]

3 7

[kamailio/kamailio] OpenSUSE warning cleanup (#1714)
by sergey-safarov 23 Nov '23

23 Nov '23

### Description During kamailio packaging on OpenSUSE in log exist this warnings ``` [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/acc_diameter.so [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/auth_diameter.so [ 860s] kamailio-json.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/jsonrpcc.so [ 860s] kamailio.i586: I: binary-or-shlib-calls-gethostbyname /usr/lib/kamailio/modules/pdb.so [… [View More]

3 3

[kamailio/kamailio] tls connection terminated frequently when mongodb cluster member becomes unavailable (#1599)
by flo-eyeson-team 23 Nov '23

23 Nov '23

### Description Kamailio frequently terminates tls connections to sip clients, if db_mongodb database driver is used and one mongodb cluster member becomes unavailable. If one mongodb secondary is shutdown (or the primary and a promotion takes place) kamailio will terminate the tls connection to a sip-client (sends a FIN/ACK) after a short period of time (differs 20s to 180s). If a sip client reconnects, registration will succeed (so mongodb access is fine) but kamailio will terminate the tls connection shortly after. This situation happens as well if only the connection between kamailio and a secondary is blocked (the cluster members can still communicate with each other). I assume that the mongo-c's server discovery might be the culprit. Mongoc iteratively tries to connect to all servers in the mongoc-uri to update their status (`mongodb://mongodb-cluster2:27017,mongodb-cluster1:27017,mongodb-cluster0:27017/kamailio?authMechanism=MONGODB-X509&replicaSet=rs1&ssl=true&sslcertificateauthorityfile=mongo.ca&sslclientcertificatekeyfile=mongo.certkey`). Nonethless, mongoc's server discovery should be transparent to the kamailio client as long as a primary exists (and this is the case). No reason to terminate tls client connections.  ### Troubleshooting #### Reproduction  1. Setup a mongodb cluster with 3 members. 2. Setup kamailio with tls using db-mongodb via tls. Note: The mongodb-uri must contain all three members, e.g. `mongodb://mongodb-cluster2:27017,mongodb-cluster1:27017,mongodb-cluster0:27017/kamailio?ssl=true`) 3. Connect/register a sip client via tls. 4. Stop one member. 5. Clients will receive a ready error on its tls connection. #### Log Messages  The db_mongodb kamailio logs don't reveal any errors. Operations are normal. The only thing which is shown in the logs is TLS read:error. As seen below. ``` Jul 23 14:22:09 bda3e8fce481 /usr/local/sbin/kamailio[318]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS read:error:140E0197:SSL routines:SSL_shutdown:shutdown while in init Jul 23 14:22:09 bda3e8fce481 /usr/local/sbin/kamailio[318]: ERROR: <core> [core/tcp_read.c:1485]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fa9b6343210 r: 0x7fa9b6343290 ``` A wireshark trace reveals that kamailio closes the tcp connection (FIN/ACK). The client receives a "stream truncated". ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.1.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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_LISTEN 16, 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 on 13:39:15 Jul 23 2018 with gcc 6.3.0 ``` * **mongoc-version** ``` mongoc-1.11.0 (built with cmake ../ -DENABLE_AUTOMATIC_INIT_AND_CLEANUP=OFF) ``` * **Operating System**:  ``` Debian 9.5 docker image running on CentOS 7 (kernel 3.10.0-514.6.1.el7.x86_64) ``` -- 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/1599 [View Less]

3 9

[kamailio/kamailio] core: use standard c atomic code from stdatomic.h instead of providing assembly routines (#1430)
by Victor Seva 23 Nov '23

23 Nov '23

>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886111 ``` Source: kamailio Version: 5.1.0-1 Severity: wishlist Hi, I noticed from the build log on mips64el a lot of warnings like this: > In file included from ../../core/parser/../mem/../atomic/atomic_native.h:50:0, > from ../../core/parser/../mem/../futexlock.h:42, > from ../../core/parser/../mem/../lock_ops.h:75, > from ../../core/parser/../mem/shm.h:39, > … [View More]

4 4

[kamailio/kamailio] tmx: t_reuse_branch() doesn't copy $du into new branch (#1264)
by Sebastian Damm 23 Nov '23

23 Nov '23

### Description When using the t_reuse_branch() function after a branch failure, Kamailio doesn't send out the call again if $du was filled and differed from $ru. Instead, Kamailio tries to send the call directly to $ru. I would expect that the call gets sent out the same way as the original call. ### Troubleshooting #### Reproduction You need a setup like this: UAC1 K(LB) <=> K(Proxy/Registrar) <=> K(LB) => UAC2 When a UAC registers, the Path module is used to save the LB … [View More](Loadbalancer) for outbound calls. When UAC1 calls UAC2, the original call gets sent through K(LB) to UAC2. However, if the first call gets rejected and the call gets retried through branch failure route, K(Proxy/Registrar) tries to send the call directly to the request URI. In your branch_route add a reference to a branch failure route: ```t_on_branch_failure("samplename");``` Then add a branch failure route like this: ```event_route[tm:branch-failure:handle_tls_branch] { if(t_check_status("488")) { if (isbflagset(0) && !isbflagset(1)) { t_reuse_branch(); setbflag(1); t_relay(); } } }``` When filling $du manually before sending out the call again, everything works. ### Possible Solutions The original destination URI should be copied to the reused branch. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 4.4.5 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, 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_LISTEN 16, 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.7.2 ``` But from what I see in source code, the devel version still copies the same value. * **Operating System**:  ``` Debian Wheezy ``` -- 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/1264 [View Less]

4 5

[kamailio/kamailio] Solve the high potential of having conflicts for internal dialog id in multiple simultaneous kamailio instances (#1500)
by alexsosic 23 Nov '23

23 Nov '23

Regarding the issue 1274 (https://github.com/kamailio/kamailio/issues/1274) there's a problem in highly scalable environments to avoid conflicts in storing dialogs in the same DB. As @miconda pointed out: > The internal id is made from two integers, hash entry and hash id (h_entry, h_id). h_entry is the index of the slot in the hash table used to store the dialog structure, computed by hashing over call id. h_id is an incremented integer specific for each hash table slot. > > So, … [View More]when loading a new record from database, if its h_id is not conflicting with an existing dialog on the same hash table slot, all is ok, otherwise the module is not going to work properly with two dialogs having same h_id. > > So, when loading a new record from database, if its h_id is not conflicting with an existing dialog on the same hash table slot, all is ok, otherwise the module is not going to work properly with two dialogs having same h_id. > > Among solutions I thought of: > > 1. have the servers generating non conflicting h_id, by having a start value different per server and an increment step larger than the number of servers. Iirc, here was at some point a similar attempt, but somehow didn't make it. Let's say one has two servers, first server starts allocating h_id from 1 and increments by 2 (e.g: 1, 3, 5, ...) and the seconds start from 2 and increments with 2 (2, 4, 6, ...). Those values can be set via mod params, eventually with an option to rely on server_id. > This should be the least intrusive in the other modules built on top of dialog. But it is rather rigid, with the example above, if one adds an extra server, it needs to reconfigure the old ones, so each server starts from either 1, 2 or 3 and increment by 3. Of course, one can set increment step to a larger value, like 100, and then has flexibility to deploy up to 1 hundred servers before having to reconfigure in case there is need for more server. > > 2. add server_id as the third field in the dialog id. It will require review of other modules using dialog and eventual code updates in those modules. One column to store the server_id needs to be added to dialog db tables. > > 3. switch from this conflicting id system to something like string unique ids, similar to what we have in usrloc records. This will require coding in other modules, changes to database schema, etc., so more work comparing with the above two, but could be the best in long term. It would be great to have the option 3 developed if possible but we would also be satisfied with the option 2 to have a third field, server_id, in the dialog id. Thank You! -- Alex -- 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/1500 [View Less]

3 6

[kamailio/kamailio] allow more than one tcp/tls connection to same destination (#1107)
by juha-h 23 Nov '23

23 Nov '23

When K connects to another SIP proxy over TCP or TLS, the connection is shared for all requests to that destination. If the receiving SIP proxy is K, it means that only one worker process is handling all those requests. This may become a bottleneck if processing of requests is time consuming, e.g., because of DB operations. It should therefore be possible one way or another to establish more than one parallel TCP or TLS connections to the same destination. One solution could be based on a … [View More]

6 6

[kamailio/kamailio] kazoo: incomplete documentation (#976)
by Ovidiu Sas 23 Nov '23

23 Nov '23

There are lots of module parameters that are not documented in the README file: "amqp_timmer_process_interval" "amqp_consumer_ack_timeout_micro" "amqp_consumer_ack_timeout_sec" "amqp_interprocess_timeout_micro" "amqp_interprocess_timeout_sec" "amqp_waitframe_timeout_micro" "amqp_waitframe_timeout_sec" "amqp_consumer_workers" "amqp_query_timeout_micro" "amqp_query_timeout_sec" "pua_include_entity" "json_escape_char" "app_name" "… [View More]

3 3

[kamailio/kamailio] Presentity tabla, faster update when drop TCP/TLS connection (#915)
by jresende 23 Nov '23

23 Nov '23

Hello, I'm testing kamailio with a SIP client with presence support, when I get a connection drop from a client (i.e when the client lost the access to the Internet connection) I do not receive the change in the status to offline immediately, I just received when the timeout from the presentity database finishes. I know that I'm able to change the expiry parameter from the presentity table, but that increases my battery consumption and the data exchange, the same happens if I reduce the … [View More]

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2020