With GNU make 4.4 building Kamailio prints many “make: --libs: No such file or directory” and similar warnings. This changeset utilizes immediate variables and silences the warnings on my systems.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3475
-- Commit Summary --
* lib/ims: Aviod “make: --libs: No such file or directory” warnings
* auth_identity: Aviod “make: --libs: No such file or directory” warnings
* auth_ephemeral: Aviod “make: --libs: No such file or directory” warnings
* app_python3: Avoid “/bin/sh: line 1: --ldflags: command not found” warnings
* app_python3s: Avoid “/bin/sh: line 1: --ldflags: command not found” warnings
* cdp: Aviod “make: --libs: No such file or directory” warnings
* cnxcc: Avoid “make: --libs-only-L: No such file or directory” warnings
* cplc: Avoid “make: --libs-only-L: No such file or directory” warnings
* crypto: Aviod “make: --libs: No such file or directory” warnings
* db_postgres: Avoid “make: --libs-only-L: No such file or directory” warnings
* db_redis: Avoid “make: --libs-only-L: No such file or directory” warning
* dialplan: Avoid “make: --libs-only-L: No such file or directory” warning
* gzcompress: Aviod “make: --libs: No such file or directory” warnings
* http_async_client: Aviod “make: --libs: No such file or directory” warnings
* http_client: Aviod “make: --libs: No such file or directory” warning
* ims_auth: Avoid “make: --libs-only-L: No such file or directory” warning
* ims_icscf: Aviod “make: --libs: No such file or directory” warning
* ims_registrar_scscf: Avoid “make: --libs-only-L: No such file or directory” warnings
* ims_registrar_pcscf: Aviod “make: --libs: No such file or directory” warning
* ims_isc: Avoid “make: --libs-only-L: No such file or directory” warnings
* jansson: Aviod “make: --libs: No such file or directory” warning
* kazoo: Avoid “make: --libs: No such file or directory’ warning
* lcr: Aviod “make: --libs: No such file or directory” warning
* log_systemd: Aviod “make: --libs: No such file or directory” warning
* lost: Aviod “make: --libs: No such file or directory” warnings
* lwsc: Aviod “make: --libs: No such file or directory” warning
* ndb_redis: Aviod “make: --libs: No such file or directory” warning
* osp: Avoid “make: --libs: No such file or directory’ warning
* outbound: Aviod “make: --libs: No such file or directory” warnings
* presence: Avoid “make: --libs-only-L: No such file or directory” warnings
* presence_conference: Aviod “make: --libs: No such file or directory” warning
* presence_dialog: Aviod “make: --libs: No such file or directory” warning
* presence_reginfo: Aviod “make: --libs: No such file or directory” warning
* presence_xml: Avoid “make: --libs-only-L: No such file or directory” warnings
* pua: Avoid “make: --libs-only-L: No such file or directory” warnings
* pua_bla: Aviod “make: --libs: No such file or directory” warning
* pua_dialoginfo: Aviod “make: --libs: No such file or directory” warning
* pua_reginfo: Aviod “make: --libs: No such file or directory” warning
* pua_usrloc: Aviod “make: --libs: No such file or directory” warning
* pua_xmpp: Aviod “make: --libs: No such file or directory” warning
* regex: Aviod “make: --libs: No such file or directory” warning
* rls: Avoid “make: --libs-only-L: No such file or directory” warnings
* slack: Aviod “make: --libs: No such file or directory” warning
* systemdops: Avoid “make: --libs-only-L: No such file or directory” warning
* tls: Aviod “make: --libs: No such file or directory” warnings
* tlsa: Avoid “make: --libs-only-L: No such file or directory” warning
* topos_redis: Aviod “make: --libs: No such file or directory” warning
* utils: Avoid “make: --libs-only-L: No such file or directory” warnings
* uuid: Aviod “make: --libs: No such file or directory” warning
* websocket: Aviod “make: --libs: No such file or directory” warnings
* xcap_server: Avoid “make: --libs-only-L: No such file or directory” warnings
* xhttp_pi: Avoid “make: --libs-only-L: No such file or directory” warnings
* xmlops: Aviod “make: --libs: No such file or directory” warning
* xmlrpc: Aviod “make: --libs: No such file or directory” warning
-- File Changes --
M src/lib/ims/Makefile (4)
M src/modules/app_python3/Makefile (6)
M src/modules/app_python3s/Makefile (6)
M src/modules/auth_ephemeral/Makefile (2)
M src/modules/auth_identity/Makefile (4)
M src/modules/cdp/Makefile (4)
M src/modules/cnxcc/Makefile (4)
M src/modules/cplc/Makefile (4)
M src/modules/crypto/Makefile (2)
M src/modules/db_postgres/Makefile (2)
M src/modules/db_redis/Makefile (2)
M src/modules/dialplan/Makefile (2)
M src/modules/gzcompress/Makefile (2)
M src/modules/http_async_client/Makefile (6)
M src/modules/http_client/Makefile (2)
M src/modules/ims_auth/Makefile (4)
M src/modules/ims_icscf/Makefile (4)
M src/modules/ims_isc/Makefile (4)
M src/modules/ims_registrar_pcscf/Makefile (4)
M src/modules/ims_registrar_scscf/Makefile (4)
M src/modules/jansson/Makefile (2)
M src/modules/kazoo/Makefile (2)
M src/modules/lcr/Makefile (2)
M src/modules/log_systemd/Makefile (2)
M src/modules/lost/Makefile (6)
M src/modules/lwsc/Makefile (2)
M src/modules/ndb_redis/Makefile (2)
M src/modules/osp/Makefile (2)
M src/modules/outbound/Makefile (7)
M src/modules/presence/Makefile (4)
M src/modules/presence_conference/Makefile (4)
M src/modules/presence_dialoginfo/Makefile (4)
M src/modules/presence_reginfo/Makefile (4)
M src/modules/presence_xml/Makefile (4)
M src/modules/pua/Makefile (4)
M src/modules/pua_bla/Makefile (4)
M src/modules/pua_dialoginfo/Makefile (4)
M src/modules/pua_reginfo/Makefile (4)
M src/modules/pua_usrloc/Makefile (4)
M src/modules/pua_xmpp/Makefile (4)
M src/modules/regex/Makefile (2)
M src/modules/rls/Makefile (4)
M src/modules/slack/Makefile (2)
M src/modules/systemdops/Makefile (2)
M src/modules/tls/Makefile (4)
M src/modules/tlsa/Makefile (4)
M src/modules/topos_redis/Makefile (2)
M src/modules/utils/Makefile (4)
M src/modules/uuid/Makefile (2)
M src/modules/websocket/Makefile (2)
M src/modules/xcap_server/Makefile (4)
M src/modules/xhttp_pi/Makefile (4)
M src/modules/xmlops/Makefile (4)
M src/modules/xmlrpc/Makefile (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3475.patchhttps://github.com/kamailio/kamailio/pull/3475.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3475
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3475(a)github.com>
Actual implementation doesn't work with async. Need to investigate how to support it
---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/684
### Description
We have updated one system from a Ubuntu Focal 5.6.x container to a Ubuntu Jammy 5.7.2 container. In the last 24 hours, we saw three crashes. The logs of the last crash say:
```
Nov 09 20:39:34 sipproxy /usr/sbin/kamailio[4332]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f[4434056180](tel:4434056180)), called from tls: tls_init.c: ser_free>
Nov 09 20:39:34 sipproxy /usr/sbin/kamailio[4331]: CRITICAL: <core> [core/mem/q_malloc.c:123]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f[44340561](tel:44340561)d0 (address 0x7f[4434056208](tel:4434056208)) beginning overwritten >
Nov 09 20:39:43 sipproxy /usr/sbin/kamailio[4273]: ALERT: <core> [main.c:776]: handle_sigs(): child process 4331 exited by a signal 6
Nov 09 20:39:43 sipproxy /usr/sbin/kamailio[4273]: ALERT: <core> [main.c:779]: handle_sigs(): core was generated
```
#### Debugging Data
Backtraces of the three crashes are attached.
[kamailio-crash1.log](https://github.com/kamailio/kamailio/files/13313115/ka…
[kamailio-crash2.log](https://github.com/kamailio/kamailio/files/13313116/ka…
[kamailio-crash3.log](https://github.com/kamailio/kamailio/files/13313117/ka…
### Additional Information
We are using the official Kamailio debian packages.
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.7.2 (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 with gcc 11.4.0
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
root@sipproxy:/WORKSPACE/sipproxy-container# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
root@sipproxy:/WORKSPACE/sipproxy-container# uname -a
Linux sipproxy 5.15.0-87-generic #97-Ubuntu SMP Mon Oct 2 21:09:21 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3635
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3635(a)github.com>
The dialog module will expire dialogs that don't actually belong to the particular proxy.
Scenario: 2 proxies on 5.2.4 with a loadbalancer in front. Call was routed over proxy1, dialog timeout on proxy2 was shorter (to make it easier to reproduce it). The results:
* Dialog synchronized with DMQ: proxy 2 would timeout the dialog
* Dialog entry synchronized to proxy2 DB and proxy2 restarted: Proxy2 would timeout the dialog
* Dialog entry synchronized to proxy2 DB and proxy2 not restarted: Proxy2 would _not_ timeout the dialog (I’ve tried both db_mode 1 and 2)
So the proxy2 would load the dialog into memory and then later expire it. So timeout routes, send_bye on timeout would not work correctly.
One idea to solve this would be to check e.g. over the existing socket data if the dialog belongs to this proxy and skip loading it in this case. This could be also made configurable e.g. with a module parameter.
Any comments? Better ideas how to solve it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2080
### Description & troubleshooting
I have defined a redis cluster as followed. The cluster consists of 3 masters (port 6379) and 3 slaves (port 6380).
The password is identical on all nodes through redis option 'requirepass'.
```
modparam("ndb_redis", "server", "name=sbcredis;addr=SBCMASTERREDISIP;port=6379;db=0;pass=REDACTED")
modparam("ndb_redis", "server", "name=sbcredis;addr=PRIVATEIP;port=6380;db=0;pass=REDACTED")
modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP5IP;port=6380;db=0;pass=REDACTED")
modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP6IP;port=6379;db=0;pass=REDACTED")
modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP3IP;port=6380;db=0;pass=REDACTED")
modparam("ndb_redis", "server", "name=sbcredis;addr=ASTP4IP;port=6379;db=0;pass=REDACTED")
modparam("ndb_redis", "cluster", 1)
modparam("ndb_redis", "allow_dynamic_nodes", 1)
modparam("ndb_redis", "debug", 3)
```
When executing the redis_cmd command, most of the times an expected warning is shown due to another server providing the requested slot:
`"(error) MOVED ... 192.168.136.241:6380"`
Notice that I've enabled "allow_dynamic_nodes" to make sure there is an automated connection attempt to the indicated server.
However, it appears that sometimes a "NOAUTH Authentication required." error is thrown when there is a redirection to a slave server serving that slot. I can authenticate succesfull on the redis-cli when using the identical password though.
Also note that when a redis master is queried, the redis_cmd is successful.
#### Reproduction
Each simple redis command that needs authentication (GET, SET, ...)
`redis_cmd("sbcredis", "SET TESTKEY TESTVALUE", "r");`
#### Log Messages
```
ndb_redis [redis_client.c:1089]: redisc_exec(): Redis error:NOAUTH Authentication required.
```
### Possible Solutions
None for now except disabling the password on all nodes.
### Additional Information
```
kamailio 5.7.2
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3654
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3654(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
The dmq_usrloc module is not replicating the extra attributes saved in the xavp for the contact. So remote nodes don't receive these values, being unable to access it properly.
It is expected that the attributes are replicated as well.
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
Setup two nodes using the dmq_usrloc and usrloc in db_mode=0.
When receiving a REGISTER, before saving the contact add some attribute in the xavp_contact. In a subsequent message to this contact (e.g.: INVITE) use a lookup() or registered() and try to access the desired xavp_contact attribute. If the request is received in the local node (which received the original REGISTER), the attribute will be valid, but if the request is received in the remote node, the attribute is empty.
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: registrar [save.c:410]: pack_ci(): generated ruid is: uloc-5cee2114-5abe-2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:73]: ucontact_xavp_store(): trying to clone per contact xavps
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:697]: xavp_clone_level_nodata(): cloned root xavp [ulattrs]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: <core> [core/xavp.c:721]: xavp_clone_level_nodata(): cloned inner xavp [cluster_node]
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ucontact.c:1701]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7f51b624d418, callback type 2/15, id 1 entered
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:776]: dmq_ul_cb_contact(): Callback from usrloc with type=2
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:427]: init_usrloc_dmq_recv(): Initializing usrloc_dmq_recv for pid (23230)
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:785]: dmq_ul_cb_contact(): Replicating local update to other nodes...
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:746]: usrloc_dmq_send_contact(): sending serialized data {"action":1,"aor":"345671002","ruid":"uloc-5cee20df-5953-1","c":"sip:345671002@172.28.128.200:5060;rinstance=38e53fed7e84e081;transport=UDP","received":"","path":"<sip:172.28.128.102:5060;received=sip:172.28.128.200:5060;lr>","callid":"NOeeFh1Bh5JR0eJG8DENkg..","user_agent":"Z 3.15.40006 rv2.8.20","instance":"","expires":1559110577,"cseq":12,"flags":0,"cflags":3072,"q":-1,"last_modified":1559109977,"methods":4294967295,"reg_id":0,"server_id":0}
May 29 16:06:18 kamailio-2 /usr/sbin/kamailio[23230]: DEBUG: dmq_usrloc [usrloc_sync.c:315]: usrloc_dmq_send(): sending dmq broadcast...
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
Only workaround seems to use usrloc with db_mode=3 and then not use the dmq_usrloc, having the usrloc with attributes info shared via the DB....
### Additional Information
Kamailio 5.2.2 installed from the repo.
```
# kamailio -v
version: kamailio 5.2.2 (x86_64/linux) 67f967
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
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: 67f967
compiled on 11:40:41 Mar 11 2019 with gcc 4.8.5
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux kamailio-2 3.10.0-514.21.2.el7.x86_64 #1 SMP Tue Jun 20 12:24:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1968
### Description
We have various commercial UE's connecting over an Amarisoft Callbox Classic eNB with Open5GS core network. This issue concerns different UE behaviour.
Name checking code introduced between Kamailio v5.6.4 and v5.7.1 (udomain.c lines 580 to 599) leads to rejection of the SUBSCRIBE request from a Huawei UE (user-agent: IM-client/OMA1.0 HW-Rto/V1.0). SUBSCRIBE requests from a OnePlus UE (user-agent: OnePlus_KB2003_RPIA.201005.001) are accepted.
We assume that the behaviour of the commercial-off-the-shelf UE's complies with the 3GPP standards; but we do not know to what extent. The following code, however, caused our Huawei UE's to lose VoLTE capability, after updating the Kamailio IMS from v5.6.4 to v5.7.1.
```
580 if ((contact_info->aor.len>0) && (needle_uri.user.len != 0)){
581 if ((needle_uri.user.len != c->contact_user.len) ||
582 (memcmp(needle_uri.user.s, c->contact_user.s, needle_uri.user.len) != 0)) {
583 LM_ERR("user name does not match - no match here...\n");
584 LM_DBG("found pcontact username [%d]: [%.*s]\n", i, c->contact_user.len, c->contact_user.s);
585 LM_DBG("incoming contact username: [%.*s]\n", needle_uri.user.len, needle_uri.user.s);
586 c = c->next;
587 continue;
588 }
589 if ((contact_info->aor.len >= 4) && (memcmp(contact_info->aor.s, c->aor.s, 4) != 0)) { // do not mix up sip- and tel-URIs.
590 LM_ERR("scheme does not match - no match here...\n");
591 LM_DBG("found pcontact scheme [%d]: [%.*s]\n", i, 4, c->aor.s);
592 LM_DBG("incoming contact scheme: [%.*s]\n", 4, contact_info->aor.s);
593 c = c->next;
594 continue;
595 }
596 }
597 else{
598 LM_DBG("No user name present - abort user name check\n");
599 }
```
The above code also does not consider the reverse_search flag (uses c=c->next instead of c = reverse_search? c->prev : c->next), so if reverse_search is set, the code's behaviour may be incorrect.
In the following pcap file, the Huawei's SIP REGISTER process starts at packet 2, 200 OK arriving in packet 41, with the P-Associated-URI <sip:51194@ims.mnc001.mcc001.3gppnetwork.org>. This UE sends SUBSCRIBE (packet 47) incorporating a new Contact: <sip:51194@10.46.0.6:31896>, presumably derived from the P-Associated-URI; but receives "403 Forbidden - You must register first with a S-CSCF".
The Oneplus sends SIP REGISTER at packet 56, receiving 200 OK at packet 83 with P-Associated-URI <sip:51196@ims.mnc001.mcc001.3gppnetwork.org>. But this UE's SUBSCRIBE (packet 84) incorporates the same Contact used in the REGISTER request: <sip:c57d4262-e59d-4530-a0f4-b4faaa2fb1c6@10.46.0.8:5060>, and 200 OK arrives at packet 92.
[v571-pcscf-name-check-fail.zip](https://github.com/kamailio/kamailio/files/…
#### Debugging Data
None acquired
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
NB: log messages acquired prior to above pcap. The following extract shows failed name check (udomain.c lines 580 - 599) for username 51194, while 001010000051194 was registered:
```
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:210]: getContactP(): This is a request - using first via to find contact
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:218]: getContactP(): searching for contact with host:port:proto contact [1://10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:459]: get_pcontact_from_cache(): Searching for contact with AOR [sip:51194@10.46.0.6:31894] in P-CSCF usrloc based on VIA [1://10.46.0.6:31894] Received [1://10.46.0.6:31409], Search flag is 0, reverse_search 0
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:469]: get_pcontact_from_cache(): Have an AOR to search for
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:474]: get_pcontact_from_cache(): checking for rinstance
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [1746035570]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:509]: get_pcontact_from_cache(): get_pcontact slot is [370]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:5060]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:5060]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:5060]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:31409]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:541]: get_pcontact_from_cache(): matched contact ip address and port
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:569]: get_pcontact_from_cache(): found contact with URI [sip:001010000051194@10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: ims_usrloc_pcscf [udomain.c:583]: get_pcontact_from_cache(): user name does not match - no match here...
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:584]: get_pcontact_from_cache(): found pcontact username [1]: [001010000051194]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:585]: get_pcontact_from_cache(): incoming contact username: [51194]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:643]: get_pcontact_from_cache(): contact not found in memory
Jul 18 12:15:31 corsa03 p-cscf[58090]: INFO: ims_registrar_pcscf [service_routes.c:277]: getContactP(): Contact not found based on Contact-header, trying IP/Port/Proto
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:459]: get_pcontact_from_cache(): Searching for contact with AOR [sip:51194@10.46.0.6:31894] in P-CSCF usrloc based on VIA [1://10.46.0.6:31894] Received [1://10.46.0.6:31409], Search flag is 1, reverse_search 0
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:469]: get_pcontact_from_cache(): Have an AOR to search for
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:474]: get_pcontact_from_cache(): checking for rinstance
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [usrloc.c:157]: get_aor_hash(): Returning hash: [1746035570]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:509]: get_pcontact_from_cache(): get_pcontact slot is [370]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:5060]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:5060]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:5060]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:546]: get_pcontact_from_cache(): continuing to match on received details
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:513]: get_pcontact_from_cache(): comparing contact with aorhash [1746035570], aor [sip:001010000051194@10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:514]: get_pcontact_from_cache(): contact host [10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:515]: get_pcontact_from_cache(): contact received [2:10.46.0.6:31409]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:522]: get_pcontact_from_cache(): mached a record by aorhash: 1746035570
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:546]: get_pcontact_from_cache(): continuing to match on received details
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:569]: get_pcontact_from_cache(): found contact with URI [sip:001010000051194@10.46.0.6:31894]
Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: ims_usrloc_pcscf [udomain.c:583]: get_pcontact_from_cache(): user name does not match - no match here...
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:584]: get_pcontact_from_cache(): found pcontact username [1]: [001010000051194]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:585]: get_pcontact_from_cache(): incoming contact username: [51194]
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_usrloc_pcscf [udomain.c:643]: get_pcontact_from_cache(): contact not found in memory
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:282]: getContactP(): No entry in usrloc for 10.46.0.6:31409 (Proto 1) found!
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: ims_registrar_pcscf [service_routes.c:319]: getContactP(): Asserted identity not set
Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[MO] c=[/etc/kamailio/pcscf/route/mo.cfg] l=16 a=26 n=send_reply
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: sl [sl.c:310]: send_reply(): reply in stateless mode (sl)
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: <core> [core/receive.c:126]: sip_check_fline(): first line indicates a SIP reply
Jul 18 12:15:31 corsa03 p-cscf[58090]: ERROR: *** cfgtrace:dbg_cfg_trace(): request_route=[MO] c=[/etc/kamailio/pcscf/route/mo.cfg] l=17 a=2 n=exit
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: <core> [core/receive.c:528]: receive_msg(): request-route executed in: 4219 usec
Jul 18 12:15:31 corsa03 p-cscf[58090]: DEBUG: <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list 0x7f043587bfc0
```
### Possible Solutions
Commenting out udomain.c lines 580-599 allowed both UE's to complete their SUBSCRIBE's, and make VoLTE calls. In the following pcap, the Oneplus REGISTER's and SUBSCRIBE's over packets 1 to 37; the Huawei process occurs from packets 45 to 98.
[v571-pcscf-name-check-skipped.zip](https://github.com/kamailio/kamailio/fil…
### 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
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
Linux corsa03 6.5.?-gentoo-x86_64 #2 SMP PREEMPT_DYNAMIC <not recorded> 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/3646
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3646(a)github.com>