[kamailio/kamailio] ims_ipsec_pcscf: dummy AOR sip:you@kamailio.org prevents ipsec_destroy() from finding contact (Issue #3570)
### Description Have two 4G UE's registered (over Open5GS CN / Amarisoft eNB): UE1 (OnePlus) connects to P-CSCF over UDP, UE2 (Huawei) connects using IPSec SA. Immediately after registration, VoLTE calls work from UE1 to UE2 and vice-versa; but after some time, only from UE2 to UE1. Calls initiated from UE1 fail with a "network error" message.
Following Kamailio logfile extract shows periodic OPTIONS processing failing (cause unknown to me) leading to de-registration: ``` Sep 14 00:56:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:67435055-f201-4c46-a31f-10b7f30c9574@10.46.0.11:5060 via sip:10.46.0.11:5060;transport=tcp... Sep 14 00:56:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:001010000051194@10.46.0.6:31907 via sip:10.46.0.6:31907;transport=tcp... Sep 14 00:57:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:67435055-f201-4c46-a31f-10b7f30c9574@10.46.0.11:5060 via sip:10.46.0.11:5060;transport=tcp... Sep 14 00:57:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:001010000051194@10.46.0.6:31907 via sip:10.46.0.6:31907;transport=tcp... Sep 14 00:58:01 corsa03 p-cscf[8124]: INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 1 Sep 14 00:58:01 corsa03 p-cscf[8134]: INFO: cdp [authstatemachine.c:270]: auth_client_statefull_sm_process(): after callback of event 17 Sep 14 00:58:01 corsa03 p-cscf[8134]: INFO: cdp [authstatemachine.c:425]: auth_client_statefull_sm_process(): state machine: AUTH_EV_RECV_STA about to clean up Sep 14 00:58:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:67435055-f201-4c46-a31f-10b7f30c9574@10.46.0.11:5060 via sip:10.46.0.11:5060;transport=tcp... Sep 14 00:58:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:001010000051194@10.46.0.6:31907 via sip:10.46.0.6:31907;transport=tcp... Sep 14 00:58:37 corsa03 p-cscf[8124]: NOTICE: <script>: request sent to sip:001010000051194@10.46.0.6:31907: Fail Counter is 1 Sep 14 00:59:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:67435055-f201-4c46-a31f-10b7f30c9574@10.46.0.11:5060 via sip:10.46.0.11:5060;transport=tcp... Sep 14 00:59:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:001010000051194@10.46.0.6:31907 via sip:10.46.0.6:31907;transport=tcp... Sep 14 00:59:37 corsa03 p-cscf[8124]: NOTICE: <script>: request sent to sip:001010000051194@10.46.0.6:31907: Fail Counter is 2 Sep 14 01:00:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:67435055-f201-4c46-a31f-10b7f30c9574@10.46.0.11:5060 via sip:10.46.0.11:5060;transport=tcp... Sep 14 01:00:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:001010000051194@10.46.0.6:31907 via sip:10.46.0.6:31907;transport=tcp... Sep 14 01:00:37 corsa03 p-cscf[8124]: NOTICE: <script>: request sent to sip:001010000051194@10.46.0.6:31907: Fail Counter is 3 Sep 14 01:01:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:67435055-f201-4c46-a31f-10b7f30c9574@10.46.0.11:5060 via sip:10.46.0.11:5060;transport=tcp... Sep 14 01:01:07 corsa03 p-cscf[8138]: INFO: <script>: OPTIONS to sip:001010000051194@10.46.0.6:31907 via sip:10.46.0.6:31907;transport=tcp... Sep 14 01:01:37 corsa03 p-cscf[8124]: NOTICE: <script>: request sent to sip:001010000051194@10.46.0.6:31907: Fail Counter is 4 Sep 14 01:01:37 corsa03 p-cscf[8124]: NOTICE: <script>: Unregistering sip:001010000051194@10.46.0.6:31907;alias=10.46.0.6~31907~2
``` But now the dummy AOR: sip:you@kamailio.org is used by ipsec_destroy(), instead of UE2's AOR: sip:001010000051194@10.46.0.6:31907:
``` Sep 14 01:01:37 corsa03 p-cscf[8124]: NOTICE: <script>: Unregistering sip:001010000051194@10.46.0.6:31907;alias=10.46.0.6~31907~2 Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_ipsec_pcscf [cmd.c:198]: fill_contact(): using original uri for contact filling: sip:you@kamailio.org Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: <core> [core/mem/q_malloc.c:373]: qm_malloc(): qm_malloc(0x7f73e298e010, 50) called from ims_ipsec_pcscf: cmd.c: fill_contact(282) Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: <core> [core/mem/q_malloc.c:416]: qm_malloc(): qm_malloc(0x7f73e298e010, 56) returns address 0x7f73e2c5a0f8 frag. 0x7f73e2c5a0c0 (size=56) on 1 -th hit Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_ipsec_pcscf [cmd.c:333]: fill_contact(): SIP REQUEST fill contact with AOR [sip:you@kamailio.org], VIA [0://kamailio.org:5060], received_host [1://1.0.0.127:5060] Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [4128780523] Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [usrloc.c:148]: get_hash_slot(): Returning hash slot: [235] Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [udomain.c:459]: get_pcontact_from_cache(): Searching for contact with AOR [sip:you@kamailio.org] in P-CSCF usrloc based on VIA [0://kamailio.org:5060] Received [1://1.0.0.127:5060], Search flag is 0, reverse_search 0 Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [udomain.c:469]: get_pcontact_from_cache(): Have an AOR to search for Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [udomain.c:474]: get_pcontact_from_cache(): checking for rinstance Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [4128780523] Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [udomain.c:509]: get_pcontact_from_cache(): get_pcontact slot is [235] Sep 14 01:01:37 corsa03 p-cscf[8124]: DEBUG: ims_usrloc_pcscf [udomain.c:642]: get_pcontact_from_cache(): contact not found in memory Sep 14 01:01:37 corsa03 p-cscf[8124]: ERROR: ims_ipsec_pcscf [cmd.c:1062]: ipsec_destroy(): Contact doesn't exist ``` I assume that ipsec_destroy() determines that the contact doesn't exist, so no change can be made to any SA. The ipsec_destroy() function call in pcscf/kamailio.cfg is used as follows: ``` event_route[uac:reply] { #!ifdef WITH_DEBUG xnotice("request sent to $uac_req(ruri) completed with code: $uac_req(evcode), Type $uac_req(evtype)\n"); #!endif if (($uac_req(evtype) != 1) || ($uac_req(evcode) != 200)) { if ($sht(natpingfail=>$uac_req(ouri)) == $null) { $sht(natpingfail=>$uac_req(ouri)) = 1; } else { $sht(natpingfail=>$uac_req(ouri)) = $sht(natpingfail=>$uac_req(ouri)) + 1; } xnotice(" request sent to $uac_req(ruri): Fail Counter is $sht(natpingfail=>$uac_req(ouri))\n"); if ($sht(natpingfail=>$uac_req(ouri)) > 3) { if ($(uac_req(ouri){uri.transport}) == "tcp") { $var(alias) = "alias="+$(uac_req(ouri){uri.host})+"~"+$(uac_req(ouri){uri.port})+"~2"; } else if ($(uac_req(ouri){uri.transport}) == "tls") { $var(alias) = "alias="+$(uac_req(ouri){uri.host})+"~"+$(uac_req(ouri){uri.port})+"~3"; } else { $var(alias) = "alias="+$(uac_req(ouri){uri.host})+"~"+$(uac_req(ouri){uri.port})+"~1"; } xnotice(" Unregistering $uac_req(ruri);$var(alias)\n"); setdebug("9"); ipsec_destroy("location"); pcscf_unregister("location", "$uac_req(ruri);$var(alias)", "$(uac_req(ouri){uri.host})", "$(uac_req(ouri){uri.port})"); resetdebug(); sht_lock("natping=>natpinglock"); $sht(natping=>$uac_req(ouri)) = $null; sht_unlock("natping=>natpinglock");
sht_lock("natpingfrom=>natpingfromlock"); $sht(natpingfrom=>$uac_req(ouri)) = $null; sht_unlock("natpingfrom=>natpingfromlock");
$sht(natpingfail=>$uac_req(ouri)) = $null; } } else { $sht(natpingfail=>$uac_req(ouri)) = $null; } } ``` How do I ensure that ipsec_destroy() receives a real AOR, and not the dummy (default?) value sip:you@kamailio.org?
### Additional Information ``` version: kamailio 5.7.1 (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, 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_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 17:01:00 Aug 12 2023 with x86_64-pc-linux-gnu-gcc 13.2.0 ```
* **Operating System**: ``` Linux corsa03 6.5.2-gentoo-x86_64 #2 SMP PREEMPT_DYNAMIC Thu Sep 7 15:16:58 CEST 2023 x86_64 AMD EPYC 7513 32-Core Processor AuthenticAMD GNU/Linux ```
The event route are executed with a fake message, because there could be situations when there is not SIP message received from the wire. The solution here is to enhance the function to get the value of the AoR as a parameter.
I am tagging this accordingly, maybe someone is going to code it (you are of course welcome to do it, as well), if not, it is going to be closed after a while.
Taking a cue from code in ims_registrar_pcscf / w_unregister, this patch replaces the dummy AOR in the SIP message passed to fill_contact: ``` diff -urw a/src/modules/ims_ipsec_pcscf/cmd.c b/src/modules/ims_ipsec_pcscf/cmd.c --- a/src/modules/ims_ipsec_pcscf/cmd.c 2023-06-28 09:40:45.000000000 +0200 +++ b/src/modules/ims_ipsec_pcscf/cmd.c 2023-09-29 15:26:52.200511805 +0200 @@ -1039,7 +1039,7 @@ }
-int ipsec_destroy(struct sip_msg *m, udomain_t *d) +int ipsec_destroy(struct sip_msg *m, udomain_t *d, str *uri) { struct pcontact_info ci; pcontact_t *pcontact = NULL; @@ -1050,6 +1050,12 @@ t = tmb.t_gett(); }
+ // Insert URI in SIP message + if(uri != NULL) { + m->first_line.u.request.uri.s = uri->s; + m->first_line.u.request.uri.len = uri->len; + } + // Find the contact if(fill_contact(&ci, m, t, 0) != 0) { LM_ERR("Error filling in contact data\n"); diff -urw a/src/modules/ims_ipsec_pcscf/cmd.h b/src/modules/ims_ipsec_pcscf/cmd.h --- a/src/modules/ims_ipsec_pcscf/cmd.h 2023-06-28 09:40:45.000000000 +0200 +++ b/src/modules/ims_ipsec_pcscf/cmd.h 2023-09-29 15:24:42.422362274 +0200 @@ -65,7 +65,7 @@
int ipsec_create(struct sip_msg *m, udomain_t *d, int _cflags); int ipsec_forward(struct sip_msg *m, udomain_t *d, int _cflags); -int ipsec_destroy(struct sip_msg *m, udomain_t *d); +int ipsec_destroy(struct sip_msg *m, udomain_t *d, str *uri); int ipsec_cleanall(); int ipsec_reconfig(); void ipsec_on_expire(pcontact_t *c, int type, void *param); diff -urw a/src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c b/src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c --- a/src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c 2023-06-28 09:40:45.000000000 +0200 +++ b/src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c 2023-10-02 12:51:04.135697115 +0200 @@ -56,12 +56,13 @@ static void mod_destroy(void); static int w_create(struct sip_msg *_m, char *_d, char *_cflags); static int w_forward(struct sip_msg *_m, char *_d, char *_cflags); -static int w_destroy(struct sip_msg *_m, char *_d, char *_cflags); +static int w_destroy(struct sip_msg *_m, char *_d, char *_aor);
/*! \brief Fixup functions */ static int domain_fixup(void **param, int param_no); static int save_fixup2(void **param, int param_no); static int free_uint_fixup(void **param, int param_no); +static int unregister_fixup(void **param, int param_no);
extern int bind_ipsec_pcscf(usrloc_api_t *api);
@@ -83,6 +84,8 @@ free_uint_fixup, REQUEST_ROUTE | ONREPLY_ROUTE }, {"ipsec_destroy", (cmd_function)w_destroy, 1, save_fixup2, 0, REQUEST_ROUTE | ONREPLY_ROUTE }, + {"ipsec_destroy", (cmd_function)w_destroy, 2, unregister_fixup, + 0, ANY_ROUTE }, {"bind_ims_ipsec_pcscf", (cmd_function)bind_ipsec_pcscf, 1, 0, 0, 0}, {0, 0, 0, 0, 0, 0} @@ -448,6 +451,36 @@ return 0; }
+/*! \brief + * Fixup for "unregister" operation - both domain and aor + */ +static int unregister_fixup(void **param, int param_no) +{ + if(param_no == 1) { + return domain_fixup(param, param_no); + } else { + pv_elem_t *model=NULL; + str s; + + /* convert to str */ + s.s = (char*)*param; + s.len = strlen(s.s); + + model = NULL; + if(s.len==0) { + LM_ERR("no param!\n"); + return E_CFG; + } + if(pv_parse_format(&s, &model)<0 || model==NULL) { + LM_ERR("wrong format [%s]!\n", s.s); + return E_CFG; + } + *param = (void*)model; + return 0; + } + return E_CFG; +} +
/*! \brief * Wrapper to ipsec functions @@ -468,7 +501,20 @@ return ipsec_forward(_m, (udomain_t *)_d, 0); }
-static int w_destroy(struct sip_msg *_m, char *_d, char *_cflags) +static int w_destroy(struct sip_msg *_m, char *_d, char *_aor) { - return ipsec_destroy(_m, (udomain_t *)_d); + pv_elem_t *model; + str aor; + + if(_aor) { + model = (pv_elem_t*)_aor; + if (pv_printf_s(_m, model, &aor) < 0) { + LM_ERR("error - cannot print the format\n"); + return -1; + } + LM_DBG("URI: %.*s\n", aor.len, aor.s); + + return ipsec_destroy(_m, (udomain_t *)_d, &aor); + } + return ipsec_destroy(_m, (udomain_t *)_d, NULL); } ``` This patch allows ipsec_destroy to be called from the PCSCF cfg file with the optional argument: $uac_req(ruri): ``` event_route[uac:reply] { #!ifdef WITH_DEBUG xnotice("request sent to $uac_req(ruri) completed with code: $uac_req(evcode), Type $uac_req(evtype)\n"); #!endif if (($uac_req(evtype) != 1) || ($uac_req(evcode) != 200)) { if ($sht(natpingfail=>$uac_req(ouri)) == $null) { $sht(natpingfail=>$uac_req(ouri)) = 1; } else { $sht(natpingfail=>$uac_req(ouri)) = $sht(natpingfail=>$uac_req(ouri)) + 1; } xnotice(" request sent to $uac_req(ruri): Fail Counter is $sht(natpingfail=>$uac_req(ouri))\n"); if ($sht(natpingfail=>$uac_req(ouri)) > 3) { if ($(uac_req(ouri){uri.transport}) == "tcp") { $var(alias) = "alias="+$(uac_req(ouri){uri.host})+"~"+$(uac_req(ouri){uri.port})+"~2"; } else if ($(uac_req(ouri){uri.transport}) == "tls") { $var(alias) = "alias="+$(uac_req(ouri){uri.host})+"~"+$(uac_req(ouri){uri.port})+"~3"; } else { $var(alias) = "alias="+$(uac_req(ouri){uri.host})+"~"+$(uac_req(ouri){uri.port})+"~1"; } xnotice(" Unregistering $uac_req(ruri);$var(alias)\n"); setdebug("9"); ipsec_destroy("location", "$uac_req(ruri)"); pcscf_unregister("location", "$uac_req(ruri);$var(alias)", "$(uac_req(ouri){uri.host})", "$(uac_req(ouri){uri.port})"); resetdebug(); sht_lock("natping=>natpinglock"); $sht(natping=>$uac_req(ouri)) = $null; sht_unlock("natping=>natpinglock");
sht_lock("natpingfrom=>natpingfromlock"); $sht(natpingfrom=>$uac_req(ouri)) = $null; sht_unlock("natpingfrom=>natpingfromlock");
$sht(natpingfail=>$uac_req(ouri)) = $null; } } else { $sht(natpingfail=>$uac_req(ouri)) = $null; } } ``` Logs shows the contact being found and destroy_ipsec_tunnel being called: ``` Oct 1 04:37:16 corsa03 p-cscf[50066]: NOTICE: <script>: request sent to sip:001010000051194@10.46.0.6:31904: Fail Counter is 4 Oct 1 04:37:16 corsa03 p-cscf[50066]: NOTICE: <script>: Unregistering sip:001010000051194@10.46.0.6:31904;alias=10.46.0.6~31904~2 Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_ipsec_pcscf [ims_ipsec_pcscf_mod.c:514]: w_destroy(): URI: sip:001010000051194@10.46.0.6:31904 Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_ipsec_pcscf [cmd.c:198]: fill_contact(): using original uri for contact filling: sip:001010000051194@10.46.0.6:31904 Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: <core> [core/mem/q_malloc.c:373]: qm_malloc(): qm_malloc(0x7f03a61c7010, 50) called from ims_ipsec_pcscf: cmd.c: fill_contact(282) Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: <core> [core/mem/q_malloc.c:416]: qm_malloc(): qm_malloc(0x7f03a61c7010, 56) returns address 0x7f03a6493260 frag. 0x7f03a6493228 (size=56) on 1 -th hit Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_ipsec_pcscf [cmd.c:333]: fill_contact(): SIP REQUEST fill contact with AOR [sip:001010000051194@10.46.0.6:31904], VIA [0://10.46.0.6:31904], received_host [1://1.0.0.127:5060] Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [1746035570] Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [usrloc.c:148]: get_hash_slot(): Returning hash slot: [370] <omitted get_pcontact_from_cache messages> Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:31904] Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:31904] Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:31435] Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570 Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:541]: get_pcontact_from_cache(): matched contact ip address and port Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:569]: get_pcontact_from_cache(): found contact with URI [sip:001010000051194@10.46.0.6:31904] Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:599]: get_pcontact_from_cache(): Hit patch usrloc pcscf skip user name check Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_usrloc_pcscf [udomain.c:634]: get_pcontact_from_cache(): contact found in memory Oct 1 04:37:16 corsa03 p-cscf[50066]: DEBUG: ims_ipsec_pcscf [cmd.c:529]: destroy_ipsec_tunnel(): Destroying security associations: Local IP: 10.169.138.17 client port: 5105 server port: 6105; UE IP: 1.0.0.127; client port 31435 server port 31904; spi_ps 4147, spi_pc 4146, spi_us 89953814, spi_uc 45782418 ``` Old (i.e. unregistered) contacts appear to accumulate in the cache; I see that ims_registrar_pcscf / w_unregister generates identical log message when it searches for the same AOR. Perhaps ims_registrar_pcscf should remove old contacts from the cache on unregistration?
Thankyou Daniel, Yesterday I posted a comment to the Kamailio Github Issues including a patch which adds an optional parameter to the ipsec_destroy function. Although it’s a quick hack, the patch solves my problem, and I believe it has no impact on existing behaviour. All the best James Bishop European Commission Directorate-General Joint Research Centre E.2 Unit
Via E. Fermi 2749, TP 723 I-21027 Ispra (VA), Italy +39 0332 786225 ***@***.******@***.***>
From: Daniel-Constantin Mierla ***@***.***> Sent: Wednesday, September 20, 2023 11:44 AM To: kamailio/kamailio ***@***.***> Cc: BISHOP James (JRC-ISPRA) ***@***.***>; Author ***@***.***> Subject: Re: [kamailio/kamailio] ims_ipsec_pcscf: dummy AOR ***@***.*** prevents ipsec_destroy() from finding contact (Issue #3570)
The event route are executed with a fake message, because there could be situations when there is not SIP message received from the wire. The solution here is to enhance the function to get the value of the AoR as a parameter.
I am tagging this accordingly, maybe someone is going to code it (you are of course welcome to do it, as well), if not, it is going to be closed after a while.
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/kamailio/kamailio/issues/3570*issuecomment-1727361903__;Iw!!DOxrgLBm!FNvbvjo89zJSce-Z4jBhDmITB6G395ok3xUtVkUElfTeWrARC1n8C2qsW30bBkPV0pxWWO15EsZmRThHZaCmj6pf60bnc9c$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4GRXIZGBNAQ2UN7XDC2TTX3K3FJANCNFSM6AAAAAA4XYHR6E__;!!DOxrgLBm!FNvbvjo89zJSce-Z4jBhDmITB6G395ok3xUtVkUElfTeWrARC1n8C2qsW30bBkPV0pxWWO15EsZmRThHZaCmj6pfvEFF80g$. You are receiving this because you authored the thread.Message ID: ***@***.***>
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
@jbipre2 Could you maybe create a pull request with your patch suggestion? Then it could be reviewed from the developers and possible also integrated in the code base.
Would like to, but don’t know how to; first attempt failed with: Pull request creation failed. Validation failed: must be a collaborator From: Henning Westerholt ***@***.***> Sent: Wednesday, November 15, 2023 9:11 AM To: kamailio/kamailio ***@***.***> Cc: BISHOP James (JRC-ISPRA) ***@***.***>; Mention ***@***.***> Subject: Re: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
@jbipre2https://urldefense.com/v3/__https:/github.com/jbipre2__;!!DOxrgLBm!AroWtwOXpV-qol_2spYEVtV6eenNIJIDQYIbwZatL2vN7Oqr2a2U68Cg4C9Pyr-weMgtj97zDZHBxyKy-6A_v18Ldd4SkQw$ Could you maybe create a pull request with your patch suggestion? Then it could be reviewed from the developers and possible also integrated in the code base.
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/kamailio/kamailio/issues/3570*issuecomment-1811984001__;Iw!!DOxrgLBm!AroWtwOXpV-qol_2spYEVtV6eenNIJIDQYIbwZatL2vN7Oqr2a2U68Cg4C9Pyr-weMgtj97zDZHBxyKy-6A_v18Ln-UzfUk$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4GRXIHNKXDJQR6O2OMVNDYER2IJAVCNFSM6AAAAAA4XYHR6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJRHE4DIMBQGE__;!!DOxrgLBm!AroWtwOXpV-qol_2spYEVtV6eenNIJIDQYIbwZatL2vN7Oqr2a2U68Cg4C9Pyr-weMgtj97zDZHBxyKy-6A_v18LEBdLuJ8$. You are receiving this because you were mentioned.Message ID: ***@***.***>
@jbipre2 not sure why this happens, just to verify - you forked the kamailio repository and then based the PR on that modification in your tree?
My total ignorance is the cause… but I learn, I learn: have now forked jbipre2/kamailio.git, set this as upstream for a local clone, and will continue to read the manual From: Henning Westerholt ***@***.***> Sent: Thursday, November 16, 2023 2:29 PM To: kamailio/kamailio ***@***.***> Cc: BISHOP James (JRC-ISPRA) ***@***.***>; Mention ***@***.***> Subject: Re: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
@jbipre2https://urldefense.com/v3/__https:/github.com/jbipre2__;!!DOxrgLBm!AaDG1CqYvtk1L0u3eqjaC3F7X0jLUOuoRsiSMhJ0aoas3F8yyquT4eN6vYCyx9OGaR1kmFVoqIdXWQ-TLpLFdi6q6TVjLRE$ not sure why this happens, just to verify - you forked the kamailio repository and then based the PR on that modification in your tree?
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/kamailio/kamailio/issues/3570*issuecomment-1814439014__;Iw!!DOxrgLBm!AaDG1CqYvtk1L0u3eqjaC3F7X0jLUOuoRsiSMhJ0aoas3F8yyquT4eN6vYCyx9OGaR1kmFVoqIdXWQ-TLpLFdi6q5p86vC8$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AM4GRXPQHQRXUZ3SGEK7NWDYEYIKVAVCNFSM6AAAAAA4XYHR6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUGQZTSMBRGQ__;!!DOxrgLBm!AaDG1CqYvtk1L0u3eqjaC3F7X0jLUOuoRsiSMhJ0aoas3F8yyquT4eN6vYCyx9OGaR1kmFVoqIdXWQ-TLpLFdi6qRkAZIq4$. You are receiving this because you were mentioned.Message ID: ***@***.***>
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
This feature is in master via #3645 and subsequent commits.
Closed #3570 as completed.
-
Daniel-Constantin Mierla -
github-actions[bot]
-
Henning Westerholt
-
jbipre2