sr-dev August 2022

sr-dev@lists.kamailio.org

16 participants
279 discussions

[kamailio/kamailio] List selectors (#2705)

by sergey-safarov

#### Pre-Submission Checklist - [x] Commit message has the format required by CONTRIBUTING guide - [x] 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) - [x] 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 - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description This is the selectors feature for `lost` module. The module still in development but the core functionality is working. What need to do 1. separate feature into dedicated `.c` file; 2. rebase on current `lost` implementation; 3. add documentation; 4. add a unit test. Would be fine if we can merge this into 5.5. This branch based on e7d68556e3560f488c4f421731f78b3f9abe549e commit You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2705 -- Commit Summary -- * http_client: http_client_request (api) content-type header support * lost: new features, attributes and a new function to dereference location * lost: bug-fix due to a code formatting error * lost: DOM level count fix * http_client: duplicated code removed * lost: README update * lost: memory leak fix and code refactoring * lost: implemented sectors -- File Changes -- M src/modules/http_client/curl_api.c (1) M src/modules/http_client/curl_api.h (3) M src/modules/http_client/functions.c (30) M src/modules/http_client/functions.h (14) M src/modules/lost/doc/lost.xml (2) M src/modules/lost/doc/lost_admin.xml (172) M src/modules/lost/functions.c (921) M src/modules/lost/functions.h (3) M src/modules/lost/lost.c (754) A src/modules/lost/naptr.c (255) A src/modules/lost/naptr.h (38) M src/modules/lost/pidf.c (5) A src/modules/lost/response.c (991) A src/modules/lost/response.h (131) M src/modules/lost/utilities.c (532) M src/modules/lost/utilities.h (65) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2705.patch https://github.com/kamailio/kamailio/pull/2705.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/2705

6 months, 1 week

[kamailio/kamailio] lib: big integers should not be treated as negative ones (#2106)

by Ivan Murashko

0xffffffff00000000ULL mask does not take into consideration signed 32 bit integers and as result 2147483648 will be stored as -2147483648. Another mask should be used to correct the issue: 0xffffffff80000000ULL. It processes correctly the case of integers that are greater than 2147483647. There are several gdb tests below: (gdb) p ((unsigned long long)2147483648 & 0xffffffff80000000ULL) $1= 2147483648 (gdb) p ((unsigned long long)2147483647 & 0xffffffff80000000ULL) $2 = 0 (gdb) p ((unsigned long long)2147483646 & 0xffffffff80000000ULL) $3 = 0 (gdb) p ((unsigned long long)4147483646 & 0xffffffff80000000ULL) $4 = 2147483648   #### 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  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2106 -- Commit Summary -- * lib: big integers should not be treated as negative ones -- File Changes -- M src/lib/srdb1/db_ut.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2106.patch https://github.com/kamailio/kamailio/pull/2106.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/2106

7 months, 1 week

[kamailio/kamailio] sslv3 errors showing up with 'tls_method' set as 'TLSv1.2+' (Issue #3085)

by Vinicius K. Ruoso

### Description Some users are having issues connecting to kamailio websocket using TLS. The logs show SSLv3 errors. Cannot find why that error would show up if SSLv2/3 is not enabled. Double checked it via SSLLabs that only TLSv1.2 is allowed in the service. Any pointers would be appreciated. Also, let me know if more debug information is needed. ### Troubleshooting #### Debugging Data This is the TLS config: ``` modparam("tls", "tls_method", "TLSv1.2+") modparam("tls", "verify_certificate", 0) modparam("tls", "require_certificate", 0) modparam("tls", "low_mem_threshold1", 0) modparam("tls", "low_mem_threshold2", 0) modparam("tls", "private_key", "/etc/certs/tls.key") modparam("tls", "certificate", "/etc/certs/tls.crt") ``` This is the output from tls module in kamcmd: ``` kamcmd> tls.info { max_connections: 2048 opened_connections: 353 clear_text_write_queued_bytes: 0 } kamcmd> tls.options { force_run: 0 method: TLSv1.2+ verify_certificate: 0 verify_depth: 9 require_certificate: 0 private_key: /etc/certs/tls.key ca_list: <null string> certificate: /etc/certs/tls.crt cipher_list: <null string> session_cache: 0 session_id: kamailio-tls-5.x.y config: <null string> log: 3 debug: 3 connection_timeout: 600 disable_compression: 1 ssl_release_buffers: -1 ssl_freelist_max: -1 ssl_max_send_fragment: -1 ssl_read_ahead: 0 send_close_notify: 0 low_mem_threshold1: 0 low_mem_threshold2: 0 ct_wq_max: 10485760 con_ct_wq_max: 65536 ct_wq_blk_size: 4096 } ``` #### Log Messages I see this log messages related to SSLv3: ``` 15(36) ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown 15(36) ERROR: <core> [core/tcp_read.c:1512]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fafc8768190 r: 0x7fafc8768278 (-1) ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.9 (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, 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 6.3.0 ``` * **Operating System**: Debian 9.13. ``` Linux 4.19.112+ #1 SMP Wed Sep 23 07:53:39 PDT 2020 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3085 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3085(a)github.com>

7 months, 1 week

[kamailio/kamailio] do not generate waring when used UDP protocol and no "Content-Length" header (Issue #3210)

by sergey-safarov

### Description According to [RFC3261](https://datatracker.ietf.org/doc/html/rfc3261#section-20.14) > The Content-Length header field indicates the size of the message- > body, in decimal number of octets, sent to the recipient. > Applications SHOULD use this field to indicate the size of the > message-body to be transferred, regardless of the media type of the > entity. If a stream-based protocol (such as TCP) is used as > transport, the header field MUST be used. When UDP protocol is used then this header is optional. When Kamailio receives an OPTIONS request like in the example, then it floods Kamailio logs with messages like ``` sanity [sanity.c:612]: check_cl(): content length header missing in request ``` OPTIONS message example ``` OPTIONS sip:sbc-0.example.com:5060 SIP/2.0 Via: SIP/2.0/UDP 64.58.61.151:5060;branch=z9hG4bKl7oo3f30a0som61aeu00 Call-ID: 49bc1fcac14b779958dad4b9c43954b400149n2(a)64.58.61.151 To: sip:ping@sbc-0.example.com From: <sip:ping@64.58.61.151>;tag=8fbe5af9178677655bc3a5388c2a8b8c00149n2 Max-Forwards: 70 CSeq: 299694 OPTIONS Route: <sip:3.236.25.4:5060;lr> ``` ### Expected behavior Do not generate warnings about SIP messages that are allowed according to RFC. #### Actual observed behavior Generated warning when "Content-Length" header missing and used UDP protocol. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3210 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3210(a)github.com>

7 months, 3 weeks

[kamailio/kamailio] [stirshaken] copy identity header and forward (Issue #3214)

by Artiom Baloian

### Description I am using STIR/SHAKEN as a third party service and wanted to know if there is a function to copy the Identity header from the 302 response into the original INVITE and then forward it. The Contact header from the 302 will make Kamailio server forward the INVITE to the SBC. Ideally having one function which does everything in one place would be a nice feature to have. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3214 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3214(a)github.com>

7 months, 3 weeks

[kamailio/kamailio] path & RFC5626: flow-token is not added if +sip.instance and reg-id are missing (Issue #3190)

by space88man

### Description If the INVITE contains `;ob` but no `;+sip.instance=xxxx;reg-id=N` then a flow-token is not added to the record-route header. This is contrary to RFC5626. #### Reproduction Configure 2 x kamailio according to module outbound; i.e 1 x edge proxy and 1 x internal proxy/registrar. UA1 and UA2 have already REGISTER'ed with `;+sip.instance=...;reg-id=...`. ``` UA1, UA2 --- edge proxy --- internal proxy ``` Send INVITE from UA1 to UA2 with `;ob` but no other params: ``` Contact: <sip:user1250@192.168.12.45:5063;transport=TLS;ob> Record-Route: <sip:127.0.0.1;r2=on;lr> Record-Route: <sip:192.168.13.50:5061;transport=tls;r2=on;lr> ``` Observe that there is no flow-token added. Send INVITE from UA1 to UA2 with `;ob` with `;+sip.instance=...;reg-id=...`: ``` Contact: <sip:user1200@192.168.122.15;transport=tls;ob>;+sip.instance="<urn:uuid:0000 `0000-0000-0000-0000-0012341234>";reg-id=7 Record-Route: <sip:Jz0HaDIr1ZoqEAPAqA0yE8XAqAwqyAo=@127.0.0.1;r2=on;lr> Record-Route: <sip:Jz0HaDIr1ZoqEAPAqA0yE8XAqAwqyAo=@192.168.13.50:5061;transport=tls;r2=on;lr> ``` Observe that there is a flow-token added. #### Debugging Data #### SIP Traffic ### Possible Solutions ### Additional Information Version; kamailio 5.6.0 #### RFC5626 Section 9.5 https://datatracker.ietf.org/doc/html/rfc5626#section-9.5 INVITE must contain `ob;` but does not need to contain `;+sip.instance=...;reg-id=...` ``` INVITE sip:alice@a.example SIP/2.0 From: Bob <sip:bob@example.com>;tag=ldw22z To: Alice <sip:alice@a.example> Call-ID: 95KGsk2V/Eis9LcpBYy3 CSeq: 1 INVITE Route: <sip:ep1.example.com;lr> Contact: <sip:bob@192.0.2.2;transport=tcp;ob> ``` EP1 adds a Record-Route with a flow-token in message #43. ``` Record-Route: <sip:3yJEbr1GYZK9cPYk5Snocez6DzO7w+AX@ep1.example.com;lr> ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3190 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3190(a)github.com>

7 months, 3 weeks

[kamailio/kamailio] dialog module does not update callee tag until 2xx received (Issue #3155)

by patrickarton

### Description dialog module does not update callee tag until it receives a 2xx response to an INVITE. and so we can not use is_know_dlg() function for in-dialog request like UPDATE when the session is still in early state.  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` kamailio 5.5.4 ``` * **Operating System**:  ``` (paste your output here) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3155 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3155(a)github.com>

7 months, 3 weeks

[kamailio/kamailio] RPC command app_jsdt.reload does not reload "require()" files (Issue #3145)

by Vincent Handfield

### Description If the file loaded with the modparam "load" uses CommonJS modules (Issue #3037-PR #3038), the modules are not reloaded when issuing the command app_jsdt.reload. Only the "main" file is reloaded. #### Reproduction 1 - Start Kamailio with those files as the initial configuration ```generic # kamailio.cfg ## Only the part concerning app_jsdt is included. ## The rest of the config file is ommited for the sake of clarity loadmodule "app_jsdt.so" modparam("app_jsdt", "load", "/etc/kamailio/js/index.js") modparam("app_jsdt", "mode", 1) cfgengine "jsdt" ``` ```js // index.js var myModule = require('./myModule'); function ksr_request_route() { myModule.myFunction() KSR.log("info", "KSR.log called from the index.js file"); } ``` ```js // myModule.js exports.myFunction = function() { KSR.log("info", "KSR.log called from the myModule.js file" } ``` 2 - Modify the myModule.js file ```js // myModule.js exports.myFunction = function() { KSR.log("info", "KSR.log called from the MODIFIED myModule.js file" } ``` 3 - Run the reload command ```console foo@bar:~# kamcmd app_jsdt.reload { old: 0 new: 1 } ``` > Log file > > INFO: app_jsdt [app_jsdt_api.c:1557]: app_jsdt_rpc_reload(): marking for reload js script file: /etc/kamailio/js/index.js (0 => 0) > DEBUG: app_jsdt [app_jsdt_api.c:534]: jsdt_kemi_reload_script(): reloading js script file: /etc/kamailio/js/index.js (0 => 1) 4 - The log file still show those lines: > Log file > >INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the myModule.js file >INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the index.js file 5 - Modify the index.js file ```js // index.js var myModule = require('./myModule'); function ksr_request_route() { myModule.myFunction() KSR.log("info", "KSR.log called from the MODIFIED index.js file"); } ``` 6 - Run the reload command ```console foo@bar:~# kamcmd app_jsdt.reload { old: 1 new: 2 } ``` > Log file > > INFO: app_jsdt [app_jsdt_api.c:1557]: app_jsdt_rpc_reload(): marking for reload js script file: /etc/kamailio/js/index.js (0 => 1) > DEBUG: app_jsdt [app_jsdt_api.c:534]: jsdt_kemi_reload_script(): reloading js script file: /etc/kamailio/js/index.js (1 => 2) 7 - The log file now show those lines: > Log file > > INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the myModule.js file > INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the MODIFIED index.js file 8 - Restart kamailio completly 9 - The log file now show those lines: > Log file > > INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the MODIFIED myModule.js file > INFO <core> [core/kemi.c:156]: sr_kemi_core_log(): KSR.log called from the MODIFIED index.js file ### Possible Solutions Sorry, I would really like to provide one, but, as I'm a new Kamailio user, I don't know all the internals yet. ### Additional Information * **Kamailio Version** ```console foo@bar:~# kamailio -v version: kamailio 5.6.0 (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_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: unknown compiled with gcc 10.2.1 ``` * **Operating System**: ```console foo@bar:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye foo@bar:~# uname -a Linux localhost 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1 (2022-04-29) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3145 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3145(a)github.com>

7 months, 3 weeks

[kamailio/kamailio] usrloc OPTIONS not tracing with HEP (Issue #3136)

by Luke Escudé

### Description OPTIONS keepalives sent by usrloc are not being traced with HEP/Homer ### Troubleshooting #### Reproduction Module setup: modparam("siptrace", "duplicate_uri","sip:HOMERIP:9060"); modparam("siptrace", "hep_mode_on",1); modparam("siptrace", "trace_to_database",0); modparam("siptrace", "trace_flag",22); modparam("siptrace", "trace_on", 1); modparam("siptrace", "hep_version", 3); modparam("siptrace", "trace_mode", 1) I believe the above setup should duplicate ALL packets to homer, which is working just fine, except for usrloc-generated OPTIONS. The 200 OK from endpoints is showing up just fine, just not the initial request. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3136 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3136(a)github.com>

7 months, 3 weeks

[kamailio/kamailio] Add file support to user blocklist for feeding caller numbers list (Issue #3132)

by soroshsabz

ITNOA ### Description I think for non-db deployment of Kamailio it is very useful to add support static data (like another configurations) for caller numbers list in user blocklist module. because if we do not have this feature we cannot use this module in non-db deployment of Kamailio. ### Expected behavior We have a configuration files (like dispatcher file) that contains below information in format of space separated list (like dispatcher file format) ``` +----+----------------+-------------+-----------+-----------+ | id | username | domain | prefix | whitelist | +----+----------------+-------------+-----------+-----------+ | 23 | 49721123456788 | | 1234 | 0 | | 22 | 49721123456788 | | 123456788 | 1 | | 21 | 49721123456789 | | 12345 | 0 | | 20 | 494675231 | | 499034133 | 1 | | 19 | 494675231 | test | 499034132 | 0 | | 18 | 494675453 | test.domain | 49901 | 0 | | 17 | 494675454 | | 49900 | 0 | +----+----------------+-------------+-----------+-----------+ ``` and user blocklist module read this file and load it, and apply this data for blocking call -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3132 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3132(a)github.com>

7 months, 3 weeks

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev August 2022