[kamailio/kamailio] ims_ipsec_pcscf: dummy AOR sip:you@kamailio.org prevents ipsec_destroy() from finding contact (Issue #3570)
14 Sep
2023
14 Sep
'23
11:06 a.m.
### 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
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570(a)github.com>
20 Sep
20 Sep
11:43 a.m.
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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1727361903
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1727361903(a)github.com>
2 Oct
2 Oct
12:59 p.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
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?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1742807215
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1742807215(a)github.com>
3 Oct
3 Oct
9:50 a.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
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 ***(a)***.***>
Sent: Wednesday, September 20, 2023 11:44 AM
To: kamailio/kamailio ***(a)***.***>
Cc: BISHOP James (JRC-ISPRA) ***(a)***.***>gt;; Author ***(a)***.***>
Subject: Re: [kamailio/kamailio] ims_ipsec_pcscf: dummy AOR ***(a)***.*** 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
GitHub<https://urldefense.com/v3/__https:/github.com/kamailio/kamailio/i…c$>,
or
unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/…g$>.
You are receiving this because you authored the thread.Message ID: ***(a)***.***>
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1744392656
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1744392656(a)github.com>
15 Nov
15 Nov
3:41 a.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
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.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1811719467
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1811719467(a)github.com>
9:10 a.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
@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.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1811984001
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1811984001(a)github.com>
3:37 p.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
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 ***(a)***.***>
Sent: Wednesday, November 15, 2023 9:11 AM
To: kamailio/kamailio ***(a)***.***>
Cc: BISHOP James (JRC-ISPRA) ***(a)***.***>gt;; Mention ***(a)***.***>
Subject: Re: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy()
(Issue #3570)
@jbipre2<https://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
GitHub<https://urldefense.com/v3/__https:/github.com/kamailio/kamailio/i…k$>,
or
unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/…8$>.
You are receiving this because you were mentioned.Message ID: ***(a)***.***>
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1812652624
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1812652624(a)github.com>
16 Nov
16 Nov
2:29 p.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
@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?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1814439014
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1814439014(a)github.com>
3:17 p.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
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 ***(a)***.***>
Sent: Thursday, November 16, 2023 2:29 PM
To: kamailio/kamailio ***(a)***.***>
Cc: BISHOP James (JRC-ISPRA) ***(a)***.***>gt;; Mention ***(a)***.***>
Subject: Re: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy()
(Issue #3570)
@jbipre2<https://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
GitHub<https://urldefense.com/v3/__https:/github.com/kamailio/kamailio/i…8$>,
or
unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/…4$>.
You are receiving this because you were mentioned.Message ID: ***(a)***.***>
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1814518345
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1814518345(a)github.com>
29 Dec
29 Dec
3:36 a.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
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.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1871685578
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1871685578(a)github.com>
8:59 a.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
This feature is in master via #3645 and subsequent commits.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#issuecomment-1871821373
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3570/1871821373(a)github.com>
8:59 a.m.
New subject: [kamailio/kamailio] ims_ipsec_pcscf: add AoR parameter to ipsec_destroy() (Issue #3570)
Closed #3570 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3570#event-11355454965
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issue/3570/issue_event/11355454965(a)github.com>
142
days inactive
248
days old
11 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
github-actions[bot]
-
Henning Westerholt
-
jbipre2