Dear all,
I'm trying Kamailio 5.1.4 and IMS module. When registering to Kamailio IMS using the same ip and port for 30 users (different contact user part), the P-CSCF get the same hash number and aor value.
The function get_aor_hash(_d, &_ci->via_host, _ci->via_port, _ci->via_prot) in ims_usrloc_pcscf pcontact.c seems the problem. Because hashing with host, port, prot will get the same hash value.
Anyone can help this ?
Hello,
On 04.07.18 09:25, tyd wrote:
Dear all,
I'm trying Kamailio 5.1.4 and IMS module. When registering to Kamailio IMS using the same ip and port for 30 users (different contact user part), the P-CSCF get the same hash number and aor value.
The function get_aor_hash(_d, &_ci->via_host, _ci->via_port, _ci->via_prot) in ims_usrloc_pcscf pcontact.c seems the problem. Because hashing with host, port, prot will get the same hash value.
Anyone can help this ?
I am not using the ims module, but the hash id is typically for speeding up the searching, there can be collisions also for different values, so I expect there is a matching rule on other attributes at some point, not only the hash id.
Cheers, Daniel
Hi, Danial
I had modified ims_usrloc_pcscf/udomain.c about hash function and related codes. ex. via_host replaces with aor
aorhash = get_aor_hash(_d, &contact_info->aor, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, &contact_info->via_host, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, &contact_info->via_host, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, &contact_info->via_host, contact_info->via_port, contact_info->via_prot);
When PCSCF DB is empty, it's OK. But if there are data in PCSCF DB, the PCSCF process was crashed. Below is the gdb content. Could you help to find the problem? Thanks.
(gdb) bt full #0 0x00007f9a2c688fc3 in core_hash (s1=0x7f9a2c89e908 <ci.13657+8>, s2=0x0, size=0) at ../../hashes.h:276 p = 0x0 end = 0x0 v = 389295844 h = 0 #1 0x00007f9a2c68ac01 in get_aor_hash (_d=0x7f9a173436e0, via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) at usrloc.c:147 aorhash = 0 __FUNCTION__ = "get_aor_hash" #2 0x00007f9a2c68a8a9 in get_hash_slot (_d=0x7f9a173436e0, via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) at usrloc.c:137 sl = 2000 __FUNCTION__ = "get_hash_slot" #3 0x00007f9a2c66e9f4 in lock_udomain (_d=0x7f9a173436e0, via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) at udomain.c:273 sl = 0 #4 0x00007f9a2c67994d in preload_udomain (_c=0x7f9a2e3162f8, _d=0x7f9a173436e0) at udomain.c:866 ci = 0x7f9a2c89e900 <ci.13657> row = 0x7f9a2e340210 columns = {0x7f9a2c89e2b0 <domain_col>, 0x7f9a2c89e2c0 <aor_col>, 0x7f9a2c89e2d0 <host_col>, 0x7f9a2c89e2e0 <port_col>, 0x7f9a2c89e2f0 <protocol_col>, 0x7f9a2c89e300 <received_col>, 0x7f9a2c89e310 <received_port_col>, 0x7f9a2c89e320 <received_proto_col>, 0x7f9a2c89e350 <rx_session_id_col>, 0x7f9a2c89e360 <reg_state_col>, 0x7f9a2c89e370 <expires_col>, 0x7f9a2c89e390 <socket_col>, 0x7f9a2c89e380 <service_routes_col>, 0x7f9a2c89e3a0 <public_ids_col>, 0x7f9a2c89e330 <path_col>} res = 0x7f9a2e33ff40 aor = {s = 0xb83059 "sip:d4173c5dcbdd1529@172.28.20.225:5080 ;transport=udp", len = 53} i = 0 n = 0 c = 0x7f9a2e335c20 __FUNCTION__ = "preload_udomain" #5 0x00007f9a2c68852d in child_init (_rank=1) at ul_mod.c:249 ptr = 0x7f9a17342c70 __FUNCTION__ = "child_init" #6 0x00000000005308c6 in init_mod_child (m=0x7f9a2e2fbcf0, rank=1) at sr_module.c:921 __FUNCTION__ = "init_mod_child" #7 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fbfa0, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #8 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fcc80, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #9 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fd260, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #10 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fd610, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #11 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fdc40, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #12 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fe158, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #13 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fe460, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #14 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fedc8, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #15 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2ff418, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #16 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2ffb48, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #17 0x00000000005305e3 in init_mod_child (m=0x7f9a2e3000f0, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" ---Type <return> to continue, or q <return> to quit--- #18 0x00000000005305e3 in init_mod_child (m=0x7f9a2e300510, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #19 0x00000000005305e3 in init_mod_child (m=0x7f9a2e301898, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #20 0x00000000005305e3 in init_mod_child (m=0x7f9a2e302130, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #21 0x00000000005305e3 in init_mod_child (m=0x7f9a2e3026d8, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #22 0x00000000005305e3 in init_mod_child (m=0x7f9a2e302a50, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #23 0x0000000000530bfe in init_child (rank=1) at sr_module.c:947 No locals. #24 0x0000000000485bd5 in fork_process (child_id=1, desc=0x7ffe9c85acc0 "udp receiver child=0 sock=172.28.20.216:4060", make_sock=1) at pt.c:327 pid = 0 child_process_no = 1 ret = -1 new_seed1 = 570787820 new_seed2 = 1356713246 sockfd = {-1, -1} __FUNCTION__ = "fork_process" #25 0x000000000052024c in main_loop () at main.c:1586 i = 0 pid = 32766 si = 0x7f9a2e2f1f10 si_desc = "udp receiver child=0 sock=172.28.20.216:4060 \000\177\000\000$[d\000\000\000\000\000\b\000\000\000\000\000\000\000(,4\027\232\177\000\000\000\360\f\027\232\177\000\000P,4\027\232\177\000\000`\000\000\000\000\000\000\000`\255\205\234\001\000\000\000\230t\r\027\232\177\000\000`\255\205\234\376\177\000\000H\036\064.\232\177\000" nrprocs = 8 woneinit = 0 __FUNCTION__ = "main_loop" ---Type <return> to continue, or q <return> to quit--- #26 0x0000000000527a79 in main (argc=7, argv=0x7ffe9c85b0d8) at main.c:2616 cfg_stream = 0xad6010 c = -1 r = 0 tmp = 0x7ffe9c85b818 "" tmp_len = 0 port = 0 proto = 0 options = 0x74b160 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:" ret = -1 seed = 2634858459 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x0 st = {st_dev = 19, st_ino = 72092, st_nlink = 2, st_mode = 16832, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1532054497, tv_nsec = 553300960}, st_mtim = {tv_sec = 1532054692, tv_nsec = 531753344}, st_ctim = { tv_sec = 1532054692, tv_nsec = 531753344}, __unused = {0, 0, 0}} __FUNCTION__ = "main" (gdb)
2018-07-16 15:54 GMT+08:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 04.07.18 09:25, tyd wrote:
Dear all,
I'm trying Kamailio 5.1.4 and IMS module. When registering to Kamailio IMS using the same ip and port for 30 users (different contact user part), the P-CSCF get the same hash number and aor value.
The function get_aor_hash(_d, &_ci->via_host, _ci->via_port, _ci->via_prot) in ims_usrloc_pcscf pcontact.c seems the problem. Because hashing with host, port, prot will get the same hash value.
Anyone can help this ?
I am not using the ims module, but the hash id is typically for speeding up the searching, there can be collisions also for different values, so I expect there is a matching rule on other attributes at some point, not only the hash id.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com
Am Freitag, 20. Juli 2018, 07:23:24 CEST schrieb tyd:
I had modified ims_usrloc_pcscf/udomain.c about hash function and related codes. ex. via_host replaces with aor
aorhash = get_aor_hash(_d, &contact_info->aor, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, &contact_info->via_host, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, &contact_info->via_host, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, &contact_info->via_host, contact_info->via_port, contact_info->via_prot);
When PCSCF DB is empty, it's OK. But if there are data in PCSCF DB, the PCSCF process was crashed. Below is the gdb content. Could you help to find the problem? Thanks.
Hello,
I am also not that familiar with the IMS modules. If you did a modification t the code and now its crashes the best would be to discuss this on our developer list sr-dev. The respective module developers are also there and could assist as well.
Best regards,
Henning
(gdb) bt full #0 0x00007f9a2c688fc3 in core_hash (s1=0x7f9a2c89e908 <ci.13657+8>, s2=0x0, size=0) at ../../hashes.h:276 p = 0x0 end = 0x0 v = 389295844 h = 0 #1 0x00007f9a2c68ac01 in get_aor_hash (_d=0x7f9a173436e0, via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) at usrloc.c:147 aorhash = 0 __FUNCTION__ = "get_aor_hash" #2 0x00007f9a2c68a8a9 in get_hash_slot (_d=0x7f9a173436e0, via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) at usrloc.c:137 sl = 2000 __FUNCTION__ = "get_hash_slot" #3 0x00007f9a2c66e9f4 in lock_udomain (_d=0x7f9a173436e0, via_host=0x7f9a2c89e908 <ci.13657+8>, via_port=5080, via_proto=53877) at udomain.c:273 sl = 0 #4 0x00007f9a2c67994d in preload_udomain (_c=0x7f9a2e3162f8, _d=0x7f9a173436e0) at udomain.c:866 ci = 0x7f9a2c89e900 <ci.13657> row = 0x7f9a2e340210 columns = {0x7f9a2c89e2b0 <domain_col>, 0x7f9a2c89e2c0 <aor_col>, 0x7f9a2c89e2d0 <host_col>, 0x7f9a2c89e2e0 <port_col>, 0x7f9a2c89e2f0 <protocol_col>, 0x7f9a2c89e300 <received_col>, 0x7f9a2c89e310 <received_port_col>, 0x7f9a2c89e320 <received_proto_col>, 0x7f9a2c89e350 <rx_session_id_col>, 0x7f9a2c89e360 <reg_state_col>, 0x7f9a2c89e370 <expires_col>, 0x7f9a2c89e390 <socket_col>, 0x7f9a2c89e380 <service_routes_col>, 0x7f9a2c89e3a0 <public_ids_col>, 0x7f9a2c89e330 <path_col>} res = 0x7f9a2e33ff40 aor = {s = 0xb83059 "sip:d4173c5dcbdd1529@172.28.20.225:5080 ;transport=udp", len = 53} i = 0 n = 0 c = 0x7f9a2e335c20 __FUNCTION__ = "preload_udomain" #5 0x00007f9a2c68852d in child_init (_rank=1) at ul_mod.c:249 ptr = 0x7f9a17342c70 __FUNCTION__ = "child_init" #6 0x00000000005308c6 in init_mod_child (m=0x7f9a2e2fbcf0, rank=1) at sr_module.c:921 __FUNCTION__ = "init_mod_child" #7 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fbfa0, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #8 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fcc80, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #9 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fd260, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #10 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fd610, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #11 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fdc40, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #12 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fe158, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #13 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fe460, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #14 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2fedc8, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #15 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2ff418, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #16 0x00000000005305e3 in init_mod_child (m=0x7f9a2e2ffb48, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #17 0x00000000005305e3 in init_mod_child (m=0x7f9a2e3000f0, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" ---Type <return> to continue, or q <return> to quit--- #18 0x00000000005305e3 in init_mod_child (m=0x7f9a2e300510, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #19 0x00000000005305e3 in init_mod_child (m=0x7f9a2e301898, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #20 0x00000000005305e3 in init_mod_child (m=0x7f9a2e302130, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #21 0x00000000005305e3 in init_mod_child (m=0x7f9a2e3026d8, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #22 0x00000000005305e3 in init_mod_child (m=0x7f9a2e302a50, rank=1) at sr_module.c:918 __FUNCTION__ = "init_mod_child" #23 0x0000000000530bfe in init_child (rank=1) at sr_module.c:947 No locals. #24 0x0000000000485bd5 in fork_process (child_id=1, desc=0x7ffe9c85acc0 "udp receiver child=0 sock=172.28.20.216:4060", make_sock=1) at pt.c:327 pid = 0 child_process_no = 1 ret = -1 new_seed1 = 570787820 new_seed2 = 1356713246 sockfd = {-1, -1} __FUNCTION__ = "fork_process" #25 0x000000000052024c in main_loop () at main.c:1586 i = 0 pid = 32766 si = 0x7f9a2e2f1f10 si_desc = "udp receiver child=0 sock=172.28.20.216:4060 \000\177\000\000$[d\000\000\000\000\000\b\000\000\000\000\000\000\000(,4\027 \232\177\000\000\000\360\f\027\232\177\000\000P,4\027\232\177\000\000`\000\0 00\000\000\000\000\000`\255\205\234\001\000\000\000\230t\r\027\232\177\000\0 00`\255\205\234\376\177\000\000H\036\064.\232\177\000" nrprocs = 8 woneinit = 0 __FUNCTION__ = "main_loop" ---Type <return> to continue, or q <return> to quit--- #26 0x0000000000527a79 in main (argc=7, argv=0x7ffe9c85b0d8) at main.c:2616 cfg_stream = 0xad6010 c = -1 r = 0 tmp = 0x7ffe9c85b818 "" tmp_len = 0 port = 0 proto = 0 options = 0x74b160 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:" ret = -1 seed = 2634858459 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x0 st = {st_dev = 19, st_ino = 72092, st_nlink = 2, st_mode = 16832, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1532054497, tv_nsec = 553300960}, st_mtim = {tv_sec = 1532054692, tv_nsec = 531753344}, st_ctim = { tv_sec = 1532054692, tv_nsec = 531753344}, __unused = {0, 0, 0}} __FUNCTION__ = "main" (gdb)
2018-07-16 15:54 GMT+08:00 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 04.07.18 09:25, tyd wrote:
Dear all,
I'm trying Kamailio 5.1.4 and IMS module. When registering to Kamailio IMS using the same ip and port for 30 users (different contact user part), the P-CSCF get the same hash number and aor value.
The function get_aor_hash(_d, &_ci->via_host, _ci->via_port, _ci->via_prot) in ims_usrloc_pcscf pcontact.c seems the problem. Because hashing with host, port, prot will get the same hash value.
Anyone can help this ?
I am not using the ims module, but the hash id is typically for speeding up the searching, there can be collisions also for different values, so I expect there is a matching rule on other attributes at some point, not only the hash id.
-
Daniel-Constantin Mierla -
Henning Westerholt -
tyd