sr-dev April 2025

sr-dev@lists.kamailio.org

14 participants
201 discussions

[kamailio/kamailio] MAR callback is not executed after a MAR request is sent (ims _auth module) (Issue #4205)
by Amin Nazari 20 May '25

20 May '25

amnapa created an issue (kamailio/kamailio#4205) ### Description Using sCSCF sample found [here](https://github.com/kamailio/kamailio/blob/master/misc/examples/ims/sc…, after calling ims_www_challenge in REGISTER route block and sending a Diameter MAR request, the control is never passed to REG_MAR_REPLY route block and debug messages within REG_MAR_REPLY are not logged. This is not the case with REG_SAR_REPLY and PRE_REG_SAR_REPLY, those blocks are executed as expected. ``` ###################################################################### # Route for handling Registrations: ###################################################################### route[REGISTER] { xlog("ALGORITHM IS [$aa] and User-Agent is [$ua]\n"); $var(alg) = $aa; if ($aa == $null) { $var(alg) = "MD5"; #force to MD5 for zoiper.... non-ims } #!ifdef WITH_AUTH if (!ims_www_authenticate("$td")) { #!else if (($var(alg) == "MD5") && (!ims_www_authenticate("$td"))) { #!endif if ($? == -2) { send_reply("403", "Authentication Failed"); exit; } else if ($? == -3) { send_reply("400", "Bad Request"); exit; } else if ($? == -9) { xlog("L_DBG", "Authentication re-sync requested\n"); ims_www_resync_auth("REG_RESYNC_REPLY", "$td"); exit; } else { #user has not been authenticated. Lets send a challenge via 401 Unauthorized xlog("L_DBG", "About to challenge! auth_ims\n"); ims_www_challenge("REG_MAR_REPLY", "$td", "$var(alg)"); exit; } } else { xlog("L_DBG", "Auth succeeded\n"); # We need to check if this user is registered or not if (!impu_registered("location")) { xlog("L_ERR", "Not REGISTERED\n"); save("PRE_REG_SAR_REPLY", "location"); exit; } else { isc_match_filter_reg("1", "location"); save("REG_SAR_REPLY", "location"); exit; } } } route[REG_MAR_REPLY] { #this is async so to know status we have to check the reply avp xlog("L_DBG", "maa_return code is $avp(s:maa_return_code)\n"); switch ($avp(s:maa_return_code)){ case 1: #success xlog("L_DBG", "MAR success - 401/407 response sent from module\n"); break; case -1: #failure xlog("L_ERR", "MAR failure - error response sent from module\n"); break; case -2: #error xlog("L_ERR", "MAR error - sending error response now\n"); send_reply("500", "MAR failed"); break; default: xlog("L_ERR", "Unknown return code from MAR, value is [$avp(s:maa_return_code)]\n"); send_reply("500", "Unknown response code from MAR"); break; } exit; } ``` ### Troubleshooting #### Reproduction  #### Debugging Data ``` (paste your debugging data here) ``` #### Log Messages ``` ERROR: *** cfgtrace:request_route=[REGISTER] c=[/usr/local/etc/kamailio/kamailio.cfg] l=712 a=27 n=ims_www_challenge DEBUG: ims_auth [authorize.c:290]: challenge(): Looking for route block [REG_MAR_REPLY] INFO: ims_auth [cxdx_mar.c:76]: create_return_code(): created AVP successfully : [maa_return_code] - [-2] DEBUG: ims_auth [authorize.c:314]: challenge(): Need to challenge for realm [ims.mnc072.mcc432.3gppnetwork.org] DEBUG: ims_auth [authorize.c:321]: challenge(): Checking if REGISTER is authorized for realm [ims.mnc072.mcc432.3gppnetwork.org]... DEBUG: ims_auth [authorize.c:1446]: get_auth_userdata(): Searching auth_userdata for IMPU sip:bob@ims.mnc072.mcc432.3gppnetwork.org (Hash 295) DEBUG: ims_auth [authorize.c:1455]: get_auth_userdata(): Found auth_userdata DEBUG: ims_auth [authorize.c:1061]: get_auth_vector(): looping through AV status is 3 and were looking for 0 DEBUG: tm [t_lookup.c:1343]: t_newtran(): msg (0x7f8d3f410cb0) id=1/11 global id=1/11 T start=(nil) DEBUG: tm [t_lookup.c:498]: t_lookup_request(): start searching: hash=21555, isACK=0 DEBUG: tm [t_lookup.c:456]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bK3345.d6f2aff0d9192c2647aca3baea62cf94.1] DEBUG: tm [t_lookup.c:681]: t_lookup_request(): no transaction found DEBUG: tm [t_hooks.c:337]: run_reqin_callbacks_internal(): trans=0x7f8d2bff4520, callback type 1, id 0 entered DEBUG: ims_auth [authorize.c:457]: challenge(): Suspending SIP TM transaction DEBUG: ims_auth [authorize.c:1526]: multimedia_auth_request(): Sending MAR DEBUG: ims_auth [cxdx_mar.c:572]: cxdx_send_mar(): Successfully sent async diameter DEBUG: tm [t_lookup.c:1628]: t_lookup_ident_filter(): transaction found INFO: ims_auth [cxdx_avp.c:134]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp (avp_code = 297, vendor_id = 0) DEBUG: ims_auth [authorize.c:1557]: pack_challenge(): setting QOP str used is [, qop="auth"] DEBUG: ims_auth [authorize.c:1559]: pack_challenge(): QOP str used is [, qop="auth"] DEBUG: tm [t_reply.c:1660]: cleanup_uac_timers(): RETR/FR timers reset DEBUG: tm [t_reply.c:595]: _reply_light(): reply sent out. buf=0x7f8d3f4120b8: SIP/2.0 401 Unauthor..., shmem=0x7f8d2bff9288: SIP/2.0 401 Unauthor DEBUG: tm [t_reply.c:606]: _reply_light(): finished DEBUG: ims_auth [authorize.c:1446]: get_auth_userdata(): Searching auth_userdata for IMPU sip:bob@ims.mnc072.mcc432.3gppnetwork.org (Hash 295) DEBUG: ims_auth [authorize.c:1455]: get_auth_userdata(): Found auth_userdata DEBUG: ims_auth [authorize.c:1679]: add_auth_vector(): Adding auth_vector (status 1) for IMPU sip:bob@ims.mnc072.mcc432.3gppnetwork.org / IMPI bob(a)ims.mnc072.mcc432.3gppnetwork.org (Hash 295) DEBUG: ims_auth [cxdx_mar.c:483]: async_cdp_callback(): DBG:UAR Async CDP callback: ... Done resuming transaction INFO: ims_auth [cxdx_mar.c:76]: create_return_code(): created AVP successfully : [maa_return_code] - [1] DEBUG: ims_auth [cxdx_mar.c:495]: async_cdp_callback(): Destroying current transaction prevented! DEBUG: tm [t_lookup.c:1620]: t_lookup_ident_filter(): transaction in terminated phase - skipping ERROR: tm [t_suspend.c:196]: t_continue_helper(): active transaction not found DEBUG: ims_auth [cxdx_mar.c:84]: free_saved_transaction_data(): Freeing saved transaction data: async ``` #### SIP Traffic ``` (paste your sip traffic here) ``` ### Possible Solutions The issue is related to ims_auth module, in [cxdx_mar.c ](https://github.com/kamailio/kamailio/blob/master/src/modules/ims_auth/cxdx_mar.c). within async_cdp_callback function, if I replace: ``` tmb.t_continue(data->tindex, data->tlabel, data->act); ```` with the following: ``` tmb.t_continue_skip_timer(data->tindex, data->tlabel, data->act); ``` the issue will be fixed and the control will be passed to REG_MAR_REPLY route block. In fact, in ims_registrar_scscf module, in [cxdx_sar.c ](https://github.com/kamailio/kamailio/blob/master/src/modules/ims_registrar_scscf/cxdx_sar.c) file, the t_continue_skip_timer is called instead of t_continue, if I replace it with t_continue the same issue happens for SAR callbacks. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 6.1.0-dev0 (x86_64/linux) c858ce-dirty 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 ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_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: c858ce -dirty compiled on 10:33:37 Apr 5 2025 with gcc 11.4.0 ``` * **Operating System**: ``` Distributor ID: Ubuntu Description: Ubuntu 22.04.5 LTS Release: 22.04 Codename: jammy Linux kuber-worker 5.15.0-133-generic #144-Ubuntu SMP Fri Feb 7 20:47:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4205 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4205(a)github.com>

2 3

[kamailio/kamailio] ims_dialog: missing srdb1 schema definition (Issue #4100)
by Victor Seva 20 May '25

20 May '25

there's no ``kamailio-ims_dialog.xml`` at ``src/lib/srdb1/schema`` but there's a manual file created at ``utils/kamctl/mysql/ims_dialog-create.sql`` Same thing for: - ``utils/kamctl/mysql/ims_charging-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_pcscf-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_scscf-create.sql`` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4100 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4100(a)github.com>

3 10

[kamailio/kamailio] rtpengine: fix race condn (same ip:port) in parallel forks due to gencookie (PR #4139)
by Souradeep Bera 18 May '25

18 May '25

- avoid parallel calls to gencookie from generating the same cookie for rtpengine #### 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/4139 -- Commit Summary -- * rtpengine: fix race condn assigning same ip:port due to gencookie in parallel forks -- File Changes -- M src/modules/rtpengine/rtpengine.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4139.patch https://github.com/kamailio/kamailio/pull/4139.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4139 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4139(a)github.com>

4 5

[kamailio/kamailio] generate rpm packages using github actions (PR #4194)
by sergey-safarov 17 May '25

17 May '25

#### 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 - [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 I have refactored the rpm packaging and am now using the GitHub actions. Now `tar.gz` archive with rpm packages, source rpm and deps rpm files attached to the release message like. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4194 -- Commit Summary -- * generate rpm packages using github actions -- File Changes -- A .github/workflows/rpm.yml (57) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4194.patch https://github.com/kamailio/kamailio/pull/4194.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4194 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4194(a)github.com>

2 5

[kamailio/kamailio] ims_auth: replaced t_continue_skip_timer with t_continue in cxdx_mar.c (PR #4206)
by Amin Nazari 17 May '25

17 May '25

- fixed log message in MAR Async CDP callback - fixed executing cfg_action after sending MAR Diameter request - cfg_action is the callback parameter of the ims_www_challenge function   #### 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) - [ ] 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 #4205 (replace XXXX with an open issue number) #### Description Based on the description in issue #4205, this PR will fix a bug in ims_auth module related to MAR Diameter request callbacks, by replacing the call to t_continue function with t_continue_skip_timer, after the MAR request is sent, the control will successfully move to the cfg action in Kamailio scripts. Just like what we already have in ims_registrar_scscf module, using t_continue_skip_timer instead of t_continue cause the transaction to be found and resumed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4206 -- Commit Summary -- * ims_auth: replaced t_continue_skip_timer with t_continue in cxdx_mar.c -- File Changes -- M src/modules/ims_auth/cxdx_mar.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4206.patch https://github.com/kamailio/kamailio/pull/4206.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4206 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4206(a)github.com>

2 1

[kamailio/kamailio] kafka_send in event_route not work (Issue #4198)
by wangduanduan 17 May '25

17 May '25

wangduanduan created an issue (kamailio/kamailio#4198)  ### Description kafka_send in event_route like tcp:timeout, tcp:closed not work ``` event_route[tcp:closed] { if (kafka_send("my_topic", "tcp:closed")) { xlog("L_INFO", "send success tcp:closed"); } } event_route[tcp:timeout] { if (kafka_send("my_topic", "tcp:timeout")) { xlog("L_INFO", "send success tcp:timeout"); } } ``` in log, its show "send success tcp:closed", "send success tcp:timeout", but in kafka web ui, in the **my_topic**, can't find the "tcp:closed" or " tcp:timeout" message. --- but if the kafka_send in onreply_route, message will be send ok, in the kafka web ui, the "some_route" can be find. ``` onreplay_route[some_route]{ if (kafka_send("my_topic", "some_routet")) { xlog("L_INFO", "send success some_routet"); } } ```  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic i use tcpdump to capture the traffic between kamailio and kafka. - when use kafka_send in event_route, no packages captured.  ``` ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` 5.6.1 ``` * **Operating System**: centos7  ``` (paste your output here) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4198 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4198(a)github.com>

5 9

[kamailio/kamailio] dispatcher: weight documentation and workaround for limitations (PR #4158)
by Christian Berger 17 May '25

17 May '25

- describe limitation of weight parameter - describe a potential workaround against those limitations  #### 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 - [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:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  We had problems understanding the weight parameter of the dispatcher module and wrote a little workaround against the problems we have found. This workaround in the configuration file improves behavior for setups with many dispatcher targets at the cost of more CPU load. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4158 -- Commit Summary -- * dispatcher: weight documentation and workaround for limitations -- File Changes -- M src/modules/dispatcher/doc/dispatcher_admin.xml (28) A src/modules/dispatcher/doc/weights.cfg (49) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4158.patch https://github.com/kamailio/kamailio/pull/4158.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4158 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4158(a)github.com>

4 3

[kamailio/kamailio] Topos not working Properly for ACK (Issue #4208)
by Pandi1981 14 May '25

14 May '25

Pandi1981 created an issue (kamailio/kamailio#4208) We are facing an issue while using TOPOS in Kamailio P-CSCF (running under Docker). Kamailio version: 6.0.0 operating system: "10 (buster)" **Call Flow & Issue Description:** Note: Public IP and Private IP mapping using the below configuration. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ listen=udp:LOCAL_IP:5060 name "internal" listen=udp:LOCAL_IP:6080 advertise PUBLIC_IP:6080 name "external" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ **Call Flow (INVITE):** A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) B-Party <-- Kamailio P-CSCF (Public IP) <-- Kamailio P-CSCF (Private IP) <-- Kamailio S-CSCF (Private IP) Everything works correctly up to the point where the 200 OK is received by the A-Party. However, when the A-Party sends the ACK, it is received by the Kamailio P-CSCF but is not forwarded to the B-Party. Upon investigation, we found that when Kamailio receives the ACK from the A-Party, the rr (Record-Route) module fails to recognize its own Route header and thus falls back to strict routing instead of performing loose routing. This results in an incorrect rewrite of the Request-URI of the ACK, causing it to fail to reach the B-Party. Essentially, the Route header is not popped as expected and the ACK routing breaks. TOPOS module is configured as follows: loadmodule "topos_redis.so" loadmodule "ndb_redis.so" loadmodule "topos.so" modparam("ndb_redis", "server", "name=tps;addr=127.0.0.1;port=6379;db=0") modparam("topos", "storage", "redis") modparam("topos_redis", "serverid", "tps") modparam("topos", "rr_update", 1) modparam("topos", "contact_mode", 1) modparam("topos", "xavu_field_a_contact", "a_contact") modparam("topos", "xavu_field_b_contact", "b_contact") modparam("topos", "xavu_cfg", "tps") Please guide us how to achieve and what we are doing wrong. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4208 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4208(a)github.com>

2 5

[kamailio/kamailio] tls: Create one shared context and reuse it. (PR #3972)
by Xenofon Karamanos 14 May '25

14 May '25

#### 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 - [x] Related to issue #3823 #### Description  This PR aims to implement what was discussed in [mailing list](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-dev@lists.kama… regarding some `tls.reload` and increasing memory usage. It adds a new parameter `enable_shared_ctx` in `tls` module that if set to 0, preserves the old behavior and if set to 1 (other than 0 tbh), it creates a single SSL context that is being shared. This have the effect of using way less memory when initialized as well, but also minimizes (can't say it fixes the problem) the `tls.reload` memory increase. I have also added a small markdown (comparison.md) file, where some comparisons where made between enabled/disabled shared context and with/without CA file (where the initial problem was occurring by the reporter). Feedback would be necessary to verify whether this patch, acts as expected and kamailio works as intented. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3972 -- Commit Summary -- * tls: Add parameter for shared contexts * tls: Comparison for enable_shared_ctx -- File Changes -- A comparison.md (15) M src/modules/tls/tls_domain.c (172) M src/modules/tls/tls_mod.c (11) M src/modules/tls/tls_mod.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3972.patch https://github.com/kamailio/kamailio/pull/3972.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3972 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3972(a)github.com>

4 10

[kamailio/kamailio] core: local TCP socket is bound on listening address (PR #3925)
by sergey-safarov 14 May '25

14 May '25

#### 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 - [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 As a local IP address for TCP sending operation the Kamailio service is taking the same network_interface/IP_address, which is used by the service for TCP listening. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3925 -- Commit Summary -- * core: local TCP socket is bound on listening address -- File Changes -- M src/core/tcp_main.c (24) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3925.patch https://github.com/kamailio/kamailio/pull/3925.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3925 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3925(a)github.com>

5 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2025