sr-dev April 2023

sr-dev@lists.kamailio.org

15 participants
171 discussions

[kamailio/kamailio] ipops: srv_query and naptr_query do not trigger DNS request (Issue #3419)

by sergey-safarov

### Description I found `srv_query` and `naptr_query` do not trigger DNS requests. This was checked via Kamailio logs and via tcpdump utility. #### Reproduction Required start Kamailio with config like ``` #!define L_DBG 3 #!define IPV4_ADDR 127.0.0.1 loadmodule "debugger.so" modparam("debugger", "cfgtrace", 1) modparam("debugger", "log_level_name", "exec") debug=L_DBG log_stderror=yes loadmodule "ipops.so" listen=udp:IPV4_ADDR name "ipv4_udp" request_route { naptr_query ("example.com", "res"); srv_query ("_sip._udp.example.com", "udp"); dns_query("test.com", "xyz"); drop; } ``` #### Log Messages ``` 28(2324390) DEBUG: <core> [core/ip_addr.c:580]: print_ip(): tcpconn_new: new tcp connection: 2600:1f18:578:5702:0:0:0:cc 28(2324390) DEBUG: <core> [core/tcp_main.c:1216]: tcpconn_new(): on port 34664, type 2, socket 46 28(2324390) DEBUG: <core> [core/tcp_main.c:1548]: tcpconn_add(): hashes: 1351:58:985, 2 28(2324390) DEBUG: <core> [core/io_wait.h:374]: io_watch_add(): processing io_watch_add(0x9ff548, 46, 2, 0xffff901ff268) - fd_no=40 28(2324390) DEBUG: <core> [core/io_wait.h:599]: io_watch_del(): DBG: io_watch_del (0x9ff548, 46, -1, 0x0) fd_no=41 called 28(2324390) DEBUG: <core> [core/tcp_main.c:4547]: handle_tcpconn_ev(): sending to child, events 1 28(2324390) DEBUG: <core> [core/tcp_main.c:4217]: send2child(): selected tcp worker idx:1 proc:21 pid:2324383 for activity on [tcp:[2605:84c0:88:42::1]:5060], 0xffff901ff268 21(2324383) DEBUG: <core> [core/tcp_read.c:1735]: handle_io(): received n=8 con=0xffff901ff268, fd=6 21(2324383) DEBUG: <core> [core/tcp_read.c:1533]: tcp_read_req(): content-length=782 21(2324383) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): SIP Request: 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:680]: parse_msg(): method: <INVITE> 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:682]: parse_msg(): uri: <urn:service:sos> 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:684]: parse_msg(): version: <SIP/2.0> 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Record-Route] type 10 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Record-Route] type 10 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKb72a.e5268cd9ad7d121798072d354270bec4.0>; state=6 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 236, <i> = <6c7781>; state=16 21(2324383) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Via] type 1 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 234, <received> = <2600:1f18:578:5704:62c1:bea:3535:6449>; state=6 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 235, <rport> = <34895>; state=6 21(2324383) DEBUG: <core> [core/parser/parse_via.c:1300]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKrB4pr8Sa2gaKQ>; state=16 21(2324383) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=78 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:568]: parse_headers(): this is the second via 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [From] type 4 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [To] type 3 21(2324383) DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=10 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [19]; uri=[urn:service:sos] 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (19)[<urn:service:sos> ], to tag (0)[] 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [Call-ID] type 6 21(2324383) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name(): parsed header name [CSeq] type 5 21(2324383) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <66360993> <INVITE> 21(2324383) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message - request - call-id: [b12b3938-ddf8-11ed-8503-e9120e4ae1c8] - cseq: [66360993 INVITE] 21(2324383) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 21(2324383) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing scripts... 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=34 a=26 n=naptr_query 21(2324383) DEBUG: ipops [ipops_pv.c:1483]: naptr_update_pv(): ipops_pv.c:1483 naptr_update_pv - called: naptrname => [example.com], pvid => [res] 21(2324383) DEBUG: ipops [ipops_pv.c:1204]: sr_naptr_add_item(): ipops_pv.c:1204 sr_naptr_add_item - called: pvid => [res] findflg => [1] 21(2324383) DEBUG: ipops [ipops_pv.c:1503]: naptr_update_pv(): pvid not found: res 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=35 a=26 n=srv_query 21(2324383) DEBUG: ipops [ipops_pv.c:1034]: srv_update_pv(): pvid not found: udp 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=36 a=26 n=dns_query 21(2324383) DEBUG: ipops [ipops_pv.c:390]: dns_update_pv(): attempting to resolve: test.com 21(2324383) DEBUG: ipops [ipops_pv.c:421]: dns_update_pv(): #0 - type 4 addr: 67.225.146.248 (2) 21(2324383) DEBUG: ipops [ipops_pv.c:434]: dns_update_pv(): dns PV updated for: test.com (1) 21(2324383) exec: *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/etc/sip-aggregator/kamailio2.cfg] l=37 a=2 n=drop 21(2324383) DEBUG: <core> [core/receive.c:528]: receive_msg(): request-route executed in: 4324 usec 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 21(2324383) DEBUG: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 21(2324383) DEBUG: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 21(2324383) DEBUG: <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 21(2324383) DEBUG: <core> [core/receive.c:628]: receive_msg(): cleaning up 21(2324383) DEBUG: <core> [core/io_wait.h:374]: io_watch_add(): processing io_watch_add(0xa437d8, 6, 2, 0xffff901ff268) - fd_no=1 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` Here is little modified 5.6.4 ``` version: kamailio 5.6.4 (aarch64/linux) 5583a2 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-NOSMP, 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: 5583a2 compiled on 00:00:00 Sep 13 2022 with gcc 12.2.1 ``` * **Operating System**: ``` NAME="Fedora Linux" VERSION="37.20230322.3.0 (CoreOS)" ID=fedora VERSION_ID=37 VERSION_CODENAME="" PLATFORM_ID="platform:f37" PRETTY_NAME="Fedora CoreOS 37.20230322.3.0" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:37" HOME_URL="https://getfedora.org/coreos/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-coreos/" SUPPORT_URL="https://github.com/coreos/fedora-coreos-tracker/" BUG_REPORT_URL="https://github.com/coreos/fedora-coreos-tracker/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=37 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=37 SUPPORT_END=2023-11-14 VARIANT="CoreOS" VARIANT_ID=coreos OSTREE_VERSION='37.20230322.3.0' ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3419 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3419(a)github.com>

4 months

[kamailio/kamailio] tm:t_lookup_callid use only trans Call-ID header value to match with … (PR #3393)

by descartin

…callid param   #### 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 - [ x] 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:  - [x ] PR should be backported to stable branches - [x ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Using kamailio 5.4 version, we have had an issue with a carrier that sent a CANCEL with to-tag. To be able to process that request, we used the function t_cancel_callid, to convert that abnormal CANCEL to a regular one cancelling the current transaction for that call. But we saw that it was not working since they sent the callid header named as CALL-ID. Seems the matching between the stored callid header in memory and the param passed for the callid lookup matching, is being done in case sensitive way with a generated Call-ID: XXXXXXXX based on the called param of the function. we have tested a wasy to do the comparision only with the callid header value, so we strip from the callid header stored at memory the Call-ID: (or CALL-ID:) part. maybe there is another way to do that in other part of the code, but seems at least this worked for the tests thanks a lot and regards david You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3393 -- Commit Summary -- * tm:t_lookup_callid use only trans Call-ID header value to match with callid param -- File Changes -- M src/modules/tm/t_lookup.c (10) M src/modules/tm/t_msgbuilder.c (9) M src/modules/tm/t_msgbuilder.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3393.patch https://github.com/kamailio/kamailio/pull/3393.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3393 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3393(a)github.com>

4 months, 1 week

[kamailio/kamailio] tls: build does not apply TLS_PTHREAD_MUTEX_SHARED on systems with libssl 1.1+ and without pkg-config (Issue #3384)

by shaneqld

### Description On systems running libssl 1.1+, the compile flag `TLS_PTHREAD_MUTEX_SHARED` is set to avoid an issue with deadlocks. However, if the system does not have `pkg-config` installed, the build completes successfully without setting this compile flag. As such, users with this particular configuration are at risk of TLS-related deadlocks. ### Troubleshooting This scenario arose for me when I experienced suspected TLS-related deadlocks in Kamailio 5.4.1. Particularly, in a simple configuration, multiple UDP workers were using t_relay to near-simultaneously connect to the same TLS host. After some time, the UDP workers stopped responding while executing this simple route block. I cannot definitively conclude this issue was the same deadlock bug. The compile flag `TLS_PTHREAD_MUTEX_SHARED` was not set and `pkg-config` was not installed. I found [this mailing list thread](https://lists.kamailio.org/pipermail/sr-users/2019-December/107759.… discussing TLS deadlocks and the build process and the user was running Kamailio 5.3.1, libssl 1.1 but did not have `TLS_PTHREAD_MUTEX_SHARED` set. This issue may explain how this user ended up in that situation. #### Reproduction Tested against Kamailio 5.4.1 and latest master. On a system with libssl 1.1+, build (including the `tls` module) with `pkg-config` installed and run `kamailio -I`. `TLS_PTHREAD_MUTEX_SHARED` flag is set. ``` Version: kamailio 5.7.0-dev3 (x86_64/linux) b75b6e Default config: /usr/local/etc/kamailio/kamailio.cfg Default paths to modules: /usr/local/lib64/kamailio/modules Compile flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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 ``` Uninstall `pkg-config` and rebuild. `TLS_PTHREAD_MUTEX_SHARED` flag is not set. ``` Version: kamailio 5.7.0-dev3 (x86_64/linux) b75b6e Default config: /usr/local/etc/kamailio/kamailio.cfg Default paths to modules: /usr/local/lib64/kamailio/modules Compile flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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 ``` When `pkg-config` is not installed, the build also outputs the following log lines, however the build does not fail. ``` /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found /bin/sh: 1: pkg-config: not found ``` ### Possible Solutions Some thoughts about options: 1. It looks like effort has been applied in other areas to support the absence of `pkg-config`, so potentially support libssl 1.1+ detection without `pkg-config`. 2. Require `pkg-config` on build and fail without it. 3. Enable `TLS_PTHREAD_MUTEX_SHARED` by default as I assume most people are running libssl 1.1+ these days, and disable it if libssl < 1.1 detected. Personally I have installed `pkg-config` and rebuilt, however I think for the safety of others building from source that the compile flag should be correctly set or the build should fail. ### Operating System ``` Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Linux debian-kamailio 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3384 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3384(a)github.com>

4 months, 2 weeks

[kamailio/kamailio] Topos: Added Call-ID mask support for Topos (PR #3347)

by Harish S

Added Call-ID mask Support for Topos with API call from Topoh to mask the callID Call-ID mask happens before the request is sent downstream and unmasked when received from downstream.   #### 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) - [ ] 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/3347 -- Commit Summary -- * Topos: Added Call ID mask when sending to Downstream * Topos: Added CallID Mask Document for Topos -- File Changes -- M src/modules/topos/doc/topos_admin.xml (20) M src/modules/topos/topos_mod.c (119) M src/modules/topos/tps_msg.c (37) M src/modules/topos/tps_msg.h (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3347.patch https://github.com/kamailio/kamailio/pull/3347.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3347 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3347(a)github.com>

4 months, 2 weeks

[kamailio/kamailio] lost: HELD request with broken sip uri (Issue #3426)

by sergey-safarov

### Description Kamailio sending HELD request with broken sip uri when the INVITE message contains a display name or display name with special character "&". ``` P-Asserted-Identity: "User &" <sip:+12001112233@206.147.236.78:5060> ``` or ``` P-Asserted-Identity: "User" <sip:+12001112233@206.147.236.78:5060> ``` For the first case, HELD request body looks like ```xml <?xml version="1.0" encoding="UTF-8"?> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000"> <locationType exact="true">geodetic locationURI</locationType> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri /> </device> </locationRequest> ``` Here `uri` element is empty. For the second case, HELD request body looks like (ident formatted) ``` <?xml version="1.0" encoding="UTF-8"?> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="5000"> <locationType exact="true">geodetic locationURI</locationType> <device xmlns="urn:ietf:params:xml:ns:geopriv:held:id"> <uri>"User" <sip:+12001112233@206.147.236.78:5060></uri> </device> </locationRequest> ``` In [HELD schema](https://datatracker.ietf.org/doc/html/rfc6155#section-6) the 'uri' element specified as ``` <xs:element name="uri" type="xs:anyURI"/> ``` For me looks like here `display name` cannot be used. Moreover, if an inbound call does not contain `P-Asserted-Identity` header then `lost` properly extracts uri from the `From` header. For me look like need to improve `P-Asserted-Identity` parsing in the `lost` module and properly extract uri from header value. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3426 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3426(a)github.com>

4 months, 3 weeks

[kamailio/kamailio] rtpengine: google sanitizer aligment warning (Issue #3058)

by sergey-safarov

``` bencode.c:149:14: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 18 26 9c ^ bencode.c:50:64: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 18 26 9c ^ bencode.c:50:54: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 00 00 00 ^ bencode.c:50:48: runtime error: member access within misaligned address 0xffff9f18937f for type 'struct bencode_item_t', which requires 8 byte alignment 0xffff9f18937f: note: pointer points here 9f ff ff 00 00 14 00 00 00 00 00 00 00 98 1b 21 9f ff ff 00 00 f0 8b 9a fe ff ff 00 00 00 00 00 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3058 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3058(a)github.com>

4 months, 3 weeks

[kamailio/kamailio] p_usrloc: Add use_domain_crc32 modparam (PR #3427)

by Stefan Mititelu

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] 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  Needed a way to use_domain but calculate crc32 for user part only. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3427 -- Commit Summary -- * p_usrloc: Add use_domain_crc32 modparam -- File Changes -- M src/modules/p_usrloc/doc/p_usrloc_admin.xml (21) M src/modules/p_usrloc/p_usrloc_mod.c (2) M src/modules/p_usrloc/p_usrloc_mod.h (1) M src/modules/p_usrloc/ul_db_handle.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3427.patch https://github.com/kamailio/kamailio/pull/3427.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3427 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3427(a)github.com>

4 months, 3 weeks

[kamailio/kamailio] tls: Add rpc function to kill session by id (PR #3428)

by Stefan Mititelu

#### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] 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  Kill a TLS session by moving the TCP connectin to -2 state. Note that it may take few seconds for session to be killed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3428 -- Commit Summary -- * tls: Add rpc function to kill session by id -- File Changes -- M src/modules/tls/doc/rpc.xml (12) M src/modules/tls/tls_rpc.c (35) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3428.patch https://github.com/kamailio/kamailio/pull/3428.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3428 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3428(a)github.com>

4 months, 3 weeks

[kamailio/kamailio] registrar: adding tcpconn_id to xavp_cfg (PR #3430)

by Julien Chavanton

4 months, 3 weeks

Building with clang

by Ivan Ribakov

Hi all, I looked at Kamailio 5.6.3 makefiles and saw mention of clang being supported. Yet when I try to build it with clang (more precisely, I build a C++ module using clang that includes some Kamailio C headers via "extern C") I get following error: In file included from /tmp/kamailio/kamailio/modules/tm/t_funcs.h:45: /tmp/kamailio/kamailio/modules/tm/timer.h:204:2: error: no matching function for call to 'atomic_cmpxchg_int' Any suggestions on how to overcome this error or any general suggestions for using Kamailio + clang? clang version 14.0.6 (Red Hat 14.0.6-4.el9_1) -- Ivan Ribakov Software Engineer www.zaleos.net

5 months

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2023