Hi,
Running bleeding-edge branch 5.1 clone here.
dmq_usrloc replication works fine when using in-memory only backing for the underlying usrloc module, i.e. db_mode 0. I haven't tried mode 1 and mode 2.
I use mode 3, so that contacts are immediately persisted straight to a local database. The database flavour is PostgreSQL in this case.
When new contacts replicated via dmq_usrloc come in, I get this in the Kamailio log:
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found
I added some code to lib/srdb1/db.c to print the parameter name and the location being passed to db_use_table():
*/ int db_use_table(db1_con_t* _h, const str* _t) { + LM_ERR("DB handle = %p\n", _h); + if (!_h || !_t || !_t->s) { - LM_ERR("invalid parameter value\n"); + LM_ERR("invalid parameter value %.*s\n", _t->len, _t->s); return -1; }
And got this:
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil) Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:631]: db_load_urecord(): failed to use table location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil) Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [ucontact.c:679]: db_insert_ucontact(): sql use_table failed Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [urecord.c:582]: insert_ucontact(): failed to insert in database
So, it appears the DB handle being passed here is NULL is in this situation.
The same AOR is present in 'ul.dump' RPC command when using db_mode 0.
Please advise? :)
-- Alex
By way of follow-up:
db_mode 1 likewise fails, in the same fashion.
db_mode 2 does work and successfully sync the contact to the DB on timer_interval.
So, I suspect this is some sort of race that raises when immediate database write-through is required.
On Fri, Dec 15, 2017 at 02:31:06PM -0500, Alex Balashov wrote:
Hi,
Running bleeding-edge branch 5.1 clone here.
dmq_usrloc replication works fine when using in-memory only backing for the underlying usrloc module, i.e. db_mode 0. I haven't tried mode 1 and mode 2.
I use mode 3, so that contacts are immediately persisted straight to a local database. The database flavour is PostgreSQL in this case.
When new contacts replicated via dmq_usrloc come in, I get this in the Kamailio log:
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found
I added some code to lib/srdb1/db.c to print the parameter name and the location being passed to db_use_table():
*/ int db_use_table(db1_con_t* _h, const str* _t) {
LM_ERR("DB handle = %p\n", _h);if (!_h || !_t || !_t->s) {
LM_ERR("invalid parameter value\n");
LM_ERR("invalid parameter value %.*s\n", _t->len, _t->s); return -1; }And got this:
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil) Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [udomain.c:631]: db_load_urecord(): failed to use table location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil) Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [ucontact.c:679]: db_insert_ucontact(): sql use_table failed Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]: ERROR: usrloc [urecord.c:582]: insert_ucontact(): failed to insert in database
So, it appears the DB handle being passed here is NULL is in this situation.
The same AOR is present in 'ul.dump' RPC command when using db_mode 0.
Please advise? :)
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Alex,
Can you provide your usrloc and dmq_usrloc module parameters please?
Cheers,
Charles
On Fri, 15 Dec 2017 at 20:54, Alex Balashov abalashov@evaristesys.com wrote:
By way of follow-up:
db_mode 1 likewise fails, in the same fashion.
db_mode 2 does work and successfully sync the contact to the DB on timer_interval.
So, I suspect this is some sort of race that raises when immediate database write-through is required.
On Fri, Dec 15, 2017 at 02:31:06PM -0500, Alex Balashov wrote:
Hi,
Running bleeding-edge branch 5.1 clone here.
dmq_usrloc replication works fine when using in-memory only backing for the underlying usrloc module, i.e. db_mode 0. I haven't tried mode 1 and mode 2.
I use mode 3, so that contacts are immediately persisted straight to a local database. The database flavour is PostgreSQL in this case.
When new contacts replicated via dmq_usrloc come in, I get this in the Kamailio log:
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: usrloc [udomain.c:817]: db_load_urecord_by_ruid(): failed to use table location
Dec 15 19:23:35 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
WARNING: dmq_usrloc [usrloc_sync.c:147]: delete_contact(): AOR/Contact not found
I added some code to lib/srdb1/db.c to print the parameter name and the location being passed to db_use_table():
*/ int db_use_table(db1_con_t* _h, const str* _t) {
LM_ERR("DB handle = %p\n", _h);if (!_h || !_t || !_t->s) {
LM_ERR("invalid parameter value\n");
LM_ERR("invalid parameter value %.*s\n", _t->len, _t->s); return -1; }And got this:
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil)
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: usrloc [udomain.c:631]: db_load_urecord(): failed to use table location
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: <core> [db.c:462]: db_use_table(): DB handle = (nil)
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: <core> [db.c:465]: db_use_table(): invalid parameter value location
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: usrloc [ucontact.c:679]: db_insert_ucontact(): sql use_table failed
Dec 15 19:23:36 evaristesys-testbed-2 /usr/local/sbin/kamailio[9395]:
ERROR: usrloc [urecord.c:582]: insert_ucontact(): failed to insert in database
So, it appears the DB handle being passed here is NULL is in this situation.
The same AOR is present in 'ul.dump' RPC command when using db_mode 0.
Please advise? :)
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello Charles,
On Mon, Dec 18, 2017 at 11:50:55AM +0000, Charles Chance wrote:
Can you provide your usrloc and dmq_usrloc module parameters please?
Well, naturally!
modparam("usrloc", "nat_bflag", 1) modparam("usrloc", "use_domain", 1) modparam("usrloc", "db_url", "DB_DRIVER://DB_USER:DB_PASSWORD@DB_HOST/DB_NAME") modparam("usrloc", "db_mode", 3) modparam("usrloc", "desc_time_order", 0) #modparam("usrloc", "timer_interval", 60) modparam("usrloc", "matching_mode", 0) modparam("usrloc", "cseq_delay", 10) modparam("usrloc", "fetch_rows", 1000) modparam("usrloc", "hash_size", 16) modparam("usrloc", "timer_procs", 1)
modparam("dmq", "server_address", "sip:<elided>:5060") modparam("dmq", "notification_address", "sip:evaristesys-testbed-2:5060") modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "batch_size", 512) modparam("dmq_usrloc", "batch_msg_size", 65536)
-- Alex
Hi Alex, I have done some tests in a lab with dmq usrloc,
------------------------------------------------------ version: kamailio 5.1.0 (x86_64/linux)
commit 28011aa9fdca7012103506d9a437c8e44dc8963c Author: Daniel-Constantin Mierla miconda@gmail.com Date: Mon Dec 11 16:31:31 2017 +0100 ------------------------------------------------------
With almost the same settings, only 2 servers using DMQ, the contacts are written into postgres when replicated, I wonder what is the problem you are facing ?
Maybe double check the DB schema, just in case ? ../kamailio/utils/kamctl/postgres/usrloc-create.sql
Maybe you could send the trace of the SIP REGISTER to emulate it in the test.
The config I modified to try to test yours :
# ----- usrloc params ----- modparam("usrloc", "db_url", "postgres:// postgres:cacao@127.0.0.1:5432/kamailio510") modparam("usrloc", "db_mode", 3) modparam("usrloc", "db_load", 0) #modparam("usrloc", "db_insert_update", 1) modparam("usrloc", "use_domain", 1) modparam("usrloc", "nat_bflag", 6) modparam("usrloc", "matching_mode", 2) modparam("usrloc", "fetch_rows", 10000) modparam("usrloc", "timer_interval", 5) modparam("usrloc", "timer_procs", 1) modparam("usrloc", "db_timer_clean", 1) modparam("usrloc", "hash_size", 19) # extra just for testing modparam("usrloc", "nat_bflag", 1) modparam("usrloc", "desc_time_order", 0) modparam("usrloc", "matching_mode", 0) modparam("usrloc", "cseq_delay", 10) modparam("usrloc", "fetch_rows", 1000) modparam("usrloc", "hash_size", 16)
#!ifdef WITH_DMQ loadmodule "dmq.so" loadmodule "dmq_usrloc.so" modparam("dmq", "server_address", "sip:127.0.1.103:5060") modparam("dmq", "notification_address", "sip:127.0.1.101:5060") modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "batch_size", 512) modparam("dmq_usrloc", "batch_msg_size", 65536) modparam("dmq_usrloc", "sync", 1) #!endif
On Mon, Dec 18, 2017 at 6:00 AM, Alex Balashov abalashov@evaristesys.com wrote:
Hello Charles,
On Mon, Dec 18, 2017 at 11:50:55AM +0000, Charles Chance wrote:
Can you provide your usrloc and dmq_usrloc module parameters please?
Well, naturally!
modparam("usrloc", "nat_bflag", 1) modparam("usrloc", "use_domain", 1) modparam("usrloc", "db_url", "DB_DRIVER://DB_USER:DB_PASSWORD@DB_HOST /DB_NAME") modparam("usrloc", "db_mode", 3) modparam("usrloc", "desc_time_order", 0) #modparam("usrloc", "timer_interval", 60) modparam("usrloc", "matching_mode", 0) modparam("usrloc", "cseq_delay", 10) modparam("usrloc", "fetch_rows", 1000) modparam("usrloc", "hash_size", 16) modparam("usrloc", "timer_procs", 1)
modparam("dmq", "server_address", "sip:<elided>:5060") modparam("dmq", "notification_address", "sip:evaristesys-testbed-2:5060") modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "batch_size", 512) modparam("dmq_usrloc", "batch_msg_size", 65536)
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello Julien,
On Mon, Dec 18, 2017 at 08:17:54PM -0800, Julien Chavanton wrote:
Hi Alex, I have done some tests in a lab with dmq usrloc,
Thank you for that!
With almost the same settings, only 2 servers using DMQ, the contacts are written into postgres when replicated, I wonder what is the problem you are facing ?
I wonder that too. :-) What version of PG?
Maybe double check the DB schema, just in case ? ../kamailio/utils/kamctl/postgres/usrloc-create.sql
Yep, that's one of the first things I did. It's 100% conformant.
Also, usrloc db_mode 3 without dmq_usrloc works just fine. This is something highly specific to dmq_usrloc.
Maybe you could send the trace of the SIP REGISTER to emulate it in the test.
I'm just testing pretty standard registrations from Bria on Android.
-- Alex
kamailio510=# SELECT version();
version ------------------------------------------------------------------------------------------------- PostgreSQL 9.5.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit (1 row)
# U 127.0.0.1:5061 -> 127.0.1.101:5060 REGISTER sip:flowroute.com SIP/2.0. Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-29823-2-0. Via: SIP/2.0/UDP 1.1.1.2:5061;branch=z9hG4bK-29823-2-0. From: sip:10001@flowroute.com;tag=2. To: sip:10001@flowroute.com. Call-ID: 2-29823@127.0.1.1. CSeq: 1 REGISTER. Contact: sip:10001-1@1.1.1.2:5061. Max-Forwards: 10. Expires: 3000. Content-Length: 0. Path: sip:127.0.1.1:5061;lr. .
# U 127.0.1.101:5060 -> 127.0.1.103:5060 KDMQ sip:usrloc@127.0.1.103:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.1.101;branch=z9hG4bKdd91.f90e0903000000000000000000000000.0. To: sip:usrloc@127.0.1.103:5060. From: <sip:usrloc@127.0.1.101:5060
;tag=36786f8e01b2230090da58c495caeae0-9338.
CSeq: 10 KDMQ. Call-ID: 567aa40265453df7-29439@127.0.1.101. Content-Length: 304. User-Agent: kamailio (5.1.0 (x86_64/linux)). Max-Forwards: 1. Content-Type: application/json. . {"action":1,"aor":"10001","ruid":"uloc-5a3891cf-72ff-1","c":" sip:10001-1@1.1.1.2:5061","received":"","path":"","callid":" 2-29823@127.0.1.1 ","user_agent":"n/a","instance":"","expires":1513660874,"cseq":1,"flags":0,"cflags":0,"q":-1,"last_modified":1513657874,"methods":4294967295,"reg_id":0,"server_id":0} # U 127.0.1.101:5060 -> 127.0.0.1:5061 SIP/2.0 200 OK. Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-29823-2-0;received=127.0.0.1. Via: SIP/2.0/UDP 1.1.1.2:5061;branch=z9hG4bK-29823-2-0. From: sip:10001@flowroute.com;tag=2. To: sip:10001@flowroute.com;tag=3a03bde2e7478628969f6eb67250a042.25c7. Call-ID: 2-29823@127.0.1.1. CSeq: 1 REGISTER. Contact: sip:10001-1@1.1.1.2:5061;expires=3000, sip:10001-2@1.1.1.2:5061;expires=1917, sip:10001-3@1.1.1.2:5061;expires=1917, <sip:10001-4@1.1.1.2:5061
;expires=1917.
Server: kamailio (5.1.0 (x86_64/linux)). Content-Length: 0. .
On Mon, Dec 18, 2017 at 8:26 PM, Alex Balashov abalashov@evaristesys.com wrote:
Hello Julien,
On Mon, Dec 18, 2017 at 08:17:54PM -0800, Julien Chavanton wrote:
Hi Alex, I have done some tests in a lab with dmq usrloc,
Thank you for that!
With almost the same settings, only 2 servers using DMQ, the contacts are written into postgres when replicated, I wonder what is the problem you
are
facing ?
I wonder that too. :-) What version of PG?
Maybe double check the DB schema, just in case ? ../kamailio/utils/kamctl/postgres/usrloc-create.sql
Yep, that's one of the first things I did. It's 100% conformant.
Also, usrloc db_mode 3 without dmq_usrloc works just fine. This is something highly specific to dmq_usrloc.
Maybe you could send the trace of the SIP REGISTER to emulate it in the test.
I'm just testing pretty standard registrations from Bria on Android.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Julien,
I am running PG 10. That is the only difference I can discern thus far, but let me compare your notes to mine and see if I can spot anything.
Thank you very much for your testing and assistance!
On Mon, Dec 18, 2017 at 08:33:26PM -0800, Julien Chavanton wrote:
kamailio510=# SELECT version();
version
PostgreSQL 9.5.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit (1 row)
# U 127.0.0.1:5061 -> 127.0.1.101:5060 REGISTER sip:flowroute.com SIP/2.0. Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-29823-2-0. Via: SIP/2.0/UDP 1.1.1.2:5061;branch=z9hG4bK-29823-2-0. From: sip:10001@flowroute.com;tag=2. To: sip:10001@flowroute.com. Call-ID: 2-29823@127.0.1.1. CSeq: 1 REGISTER. Contact: sip:10001-1@1.1.1.2:5061. Max-Forwards: 10. Expires: 3000. Content-Length: 0. Path: sip:127.0.1.1:5061;lr. .
# U 127.0.1.101:5060 -> 127.0.1.103:5060 KDMQ sip:usrloc@127.0.1.103:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.1.101;branch=z9hG4bKdd91.f90e0903000000000000000000000000.0. To: sip:usrloc@127.0.1.103:5060. From: <sip:usrloc@127.0.1.101:5060
;tag=36786f8e01b2230090da58c495caeae0-9338.
CSeq: 10 KDMQ. Call-ID: 567aa40265453df7-29439@127.0.1.101. Content-Length: 304. User-Agent: kamailio (5.1.0 (x86_64/linux)). Max-Forwards: 1. Content-Type: application/json. . {"action":1,"aor":"10001","ruid":"uloc-5a3891cf-72ff-1","c":" sip:10001-1@1.1.1.2:5061","received":"","path":"","callid":" 2-29823@127.0.1.1 ","user_agent":"n/a","instance":"","expires":1513660874,"cseq":1,"flags":0,"cflags":0,"q":-1,"last_modified":1513657874,"methods":4294967295,"reg_id":0,"server_id":0} # U 127.0.1.101:5060 -> 127.0.0.1:5061 SIP/2.0 200 OK. Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-29823-2-0;received=127.0.0.1. Via: SIP/2.0/UDP 1.1.1.2:5061;branch=z9hG4bK-29823-2-0. From: sip:10001@flowroute.com;tag=2. To: sip:10001@flowroute.com;tag=3a03bde2e7478628969f6eb67250a042.25c7. Call-ID: 2-29823@127.0.1.1. CSeq: 1 REGISTER. Contact: sip:10001-1@1.1.1.2:5061;expires=3000, sip:10001-2@1.1.1.2:5061;expires=1917, sip:10001-3@1.1.1.2:5061;expires=1917, <sip:10001-4@1.1.1.2:5061
;expires=1917.
Server: kamailio (5.1.0 (x86_64/linux)). Content-Length: 0. .
On Mon, Dec 18, 2017 at 8:26 PM, Alex Balashov abalashov@evaristesys.com wrote:
Hello Julien,
On Mon, Dec 18, 2017 at 08:17:54PM -0800, Julien Chavanton wrote:
Hi Alex, I have done some tests in a lab with dmq usrloc,
Thank you for that!
With almost the same settings, only 2 servers using DMQ, the contacts are written into postgres when replicated, I wonder what is the problem you
are
facing ?
I wonder that too. :-) What version of PG?
Maybe double check the DB schema, just in case ? ../kamailio/utils/kamctl/postgres/usrloc-create.sql
Yep, that's one of the first things I did. It's 100% conformant.
Also, usrloc db_mode 3 without dmq_usrloc works just fine. This is something highly specific to dmq_usrloc.
Maybe you could send the trace of the SIP REGISTER to emulate it in the test.
I'm just testing pretty standard registrations from Bria on Android.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Julian - thanks for testing, I had very little time yesterday!
Alex - the only thing I can suggest is to check the table name on your receiving node as by default the replicated contacts will use “location”. If the table name is different then you’ll need to set the domain parameter of dmq_usrloc. Either way, when dmq writes a replicated contact it uses the usrloc API and is entirely independent of the underlying storage method. So if there is an issue I suspect it’s somewhere else.
Cheers,
Charles
On Tue, 19 Dec 2017 at 05:00, Alex Balashov abalashov@evaristesys.com wrote:
Julien,
I am running PG 10. That is the only difference I can discern thus far, but let me compare your notes to mine and see if I can spot anything.
Thank you very much for your testing and assistance!
On Mon, Dec 18, 2017 at 08:33:26PM -0800, Julien Chavanton wrote:
kamailio510=# SELECT version();
version
PostgreSQL 9.5.6 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit (1 row)
# U 127.0.0.1:5061 -> 127.0.1.101:5060 REGISTER sip:flowroute.com SIP/2.0. Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-29823-2-0. Via: SIP/2.0/UDP 1.1.1.2:5061;branch=z9hG4bK-29823-2-0. From: sip:10001@flowroute.com;tag=2. To: sip:10001@flowroute.com. Call-ID: 2-29823@127.0.1.1. CSeq: 1 REGISTER. Contact: sip:10001-1@1.1.1.2:5061. Max-Forwards: 10. Expires: 3000. Content-Length: 0. Path: sip:127.0.1.1:5061;lr. .
# U 127.0.1.101:5060 -> 127.0.1.103:5060 KDMQ sip:usrloc@127.0.1.103:5060 SIP/2.0. Via: SIP/2.0/UDP 127.0.1.101;branch=z9hG4bKdd91.f90e0903000000000000000000000000.0. To: sip:usrloc@127.0.1.103:5060. From: <sip:usrloc@127.0.1.101:5060
;tag=36786f8e01b2230090da58c495caeae0-9338.
CSeq: 10 KDMQ. Call-ID: 567aa40265453df7-29439@127.0.1.101. Content-Length: 304. User-Agent: kamailio (5.1.0 (x86_64/linux)). Max-Forwards: 1. Content-Type: application/json. . {"action":1,"aor":"10001","ruid":"uloc-5a3891cf-72ff-1","c":" sip:10001-1@1.1.1.2:5061","received":"","path":"","callid":" 2-29823@127.0.1.1
","user_agent":"n/a","instance":"","expires":1513660874,"cseq":1,"flags":0,"cflags":0,"q":-1,"last_modified":1513657874,"methods":4294967295,"reg_id":0,"server_id":0}
# U 127.0.1.101:5060 -> 127.0.0.1:5061 SIP/2.0 200 OK. Via: SIP/2.0/UDP 127.0.1.1:5061
;branch=z9hG4bK-29823-2-0;received=127.0.0.1.
Via: SIP/2.0/UDP 1.1.1.2:5061;branch=z9hG4bK-29823-2-0. From: sip:10001@flowroute.com;tag=2. To: sip:10001@flowroute.com;tag=3a03bde2e7478628969f6eb67250a042.25c7. Call-ID: 2-29823@127.0.1.1. CSeq: 1 REGISTER. Contact: sip:10001-1@1.1.1.2:5061;expires=3000, sip:10001-2@1.1.1.2:5061;expires=1917, sip:10001-3@1.1.1.2:5061;expires=1917, <sip:10001-4@1.1.1.2:5061
;expires=1917.
Server: kamailio (5.1.0 (x86_64/linux)). Content-Length: 0. .
On Mon, Dec 18, 2017 at 8:26 PM, Alex Balashov <
abalashov@evaristesys.com>
wrote:
Hello Julien,
On Mon, Dec 18, 2017 at 08:17:54PM -0800, Julien Chavanton wrote:
Hi Alex, I have done some tests in a lab with dmq usrloc,
Thank you for that!
With almost the same settings, only 2 servers using DMQ, the
contacts are
written into postgres when replicated, I wonder what is the problem
you
are
facing ?
I wonder that too. :-) What version of PG?
Maybe double check the DB schema, just in case ? ../kamailio/utils/kamctl/postgres/usrloc-create.sql
Yep, that's one of the first things I did. It's 100% conformant.
Also, usrloc db_mode 3 without dmq_usrloc works just fine. This is something highly specific to dmq_usrloc.
Maybe you could send the trace of the SIP REGISTER to emulate it in
the
test.
I'm just testing pretty standard registrations from Bria on Android.
-- Alex
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
I have tried against PG 9.6, and reloaded all the table schemas just to be completely sure. The problem persists.
I should reemphasise that local usrloc storage works. It's only on the remote peers receiving bindings via dmq_usrloc that there is a problem.
I will further note that db_mode 2 works even with timer_interval == 1, so this is definitely some sort of timing / race issue related to immediate use of the DB in db_mode 3.
On Tue, Dec 19, 2017 at 02:37:01PM -0500, Alex Balashov wrote:
I have tried against PG 9.6, and reloaded all the table schemas just to be completely sure. The problem persists.
I should reemphasise that local usrloc storage works. It's only on the remote peers receiving bindings via dmq_usrloc that there is a problem.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Good, we confirm this is not about Postgres version
Yes I understood that what was not working was the insert done when receiving registration through DMQ, this is also what I have been testing.
Ok only db_mode 3 is not/never working ...
In my lab, only one server is trying to insert and this is the server receiving registration trough DMQ.
I guess we could patch to output every queries generated in module db_postgres
On Tue, Dec 19, 2017 at 11:43 AM, Alex Balashov abalashov@evaristesys.com wrote:
I will further note that db_mode 2 works even with timer_interval == 1, so this is definitely some sort of timing / race issue related to immediate use of the DB in db_mode 3.
On Tue, Dec 19, 2017 at 02:37:01PM -0500, Alex Balashov wrote:
I have tried against PG 9.6, and reloaded all the table schemas just to be completely sure. The problem persists.
I should reemphasise that local usrloc storage works. It's only on the remote peers receiving bindings via dmq_usrloc that there is a problem.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
I think the null DB handle pointer is at the heart of the problem, not any problematic query...
On December 19, 2017 3:05:44 PM EST, Julien Chavanton jchavanton@gmail.com wrote:
Good, we confirm this is not about Postgres version
Yes I understood that what was not working was the insert done when receiving registration through DMQ, this is also what I have been testing.
Ok only db_mode 3 is not/never working ...
In my lab, only one server is trying to insert and this is the server receiving registration trough DMQ.
I guess we could patch to output every queries generated in module db_postgres
On Tue, Dec 19, 2017 at 11:43 AM, Alex Balashov abalashov@evaristesys.com wrote:
I will further note that db_mode 2 works even with timer_interval ==
1,
so this is definitely some sort of timing / race issue related to immediate use of the DB in db_mode 3.
On Tue, Dec 19, 2017 at 02:37:01PM -0500, Alex Balashov wrote:
I have tried against PG 9.6, and reloaded all the table schemas
just to
be completely sure. The problem persists.
I should reemphasise that local usrloc storage works. It's only on
the
remote peers receiving bindings via dmq_usrloc that there is a
problem.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.
db_mode 1 also does not work.
On December 19, 2017 3:05:44 PM EST, Julien Chavanton jchavanton@gmail.com wrote:
Good, we confirm this is not about Postgres version
Yes I understood that what was not working was the insert done when receiving registration through DMQ, this is also what I have been testing.
Ok only db_mode 3 is not/never working ...
In my lab, only one server is trying to insert and this is the server receiving registration trough DMQ.
I guess we could patch to output every queries generated in module db_postgres
On Tue, Dec 19, 2017 at 11:43 AM, Alex Balashov abalashov@evaristesys.com wrote:
I will further note that db_mode 2 works even with timer_interval ==
1,
so this is definitely some sort of timing / race issue related to immediate use of the DB in db_mode 3.
On Tue, Dec 19, 2017 at 02:37:01PM -0500, Alex Balashov wrote:
I have tried against PG 9.6, and reloaded all the table schemas
just to
be completely sure. The problem persists.
I should reemphasise that local usrloc storage works. It's only on
the
remote peers receiving bindings via dmq_usrloc that there is a
problem.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Right looking back at your initial logs the DB handle is null when it should not be.
Wonder where is it lost, we may need to run in debug mode to follow what is going on in db_postgress
On Tue, Dec 19, 2017 at 12:08 PM, Alex Balashov abalashov@evaristesys.com wrote:
db_mode 1 also does not work.
On December 19, 2017 3:05:44 PM EST, Julien Chavanton < jchavanton@gmail.com> wrote:
Good, we confirm this is not about Postgres version
Yes I understood that what was not working was the insert done when receiving registration through DMQ, this is also what I have been testing.
Ok only db_mode 3 is not/never working ...
In my lab, only one server is trying to insert and this is the server receiving registration trough DMQ.
I guess we could patch to output every queries generated in module db_postgres
On Tue, Dec 19, 2017 at 11:43 AM, Alex Balashov abalashov@evaristesys.com wrote:
I will further note that db_mode 2 works even with timer_interval ==
1,
so this is definitely some sort of timing / race issue related to immediate use of the DB in db_mode 3.
On Tue, Dec 19, 2017 at 02:37:01PM -0500, Alex Balashov wrote:
I have tried against PG 9.6, and reloaded all the table schemas
just to
be completely sure. The problem persists.
I should reemphasise that local usrloc storage works. It's only on
the
remote peers receiving bindings via dmq_usrloc that there is a
problem.
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex
-- Sent via mobile, please forgive typos and brevity.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On Tue, Dec 19, 2017 at 12:37:15PM -0800, Julien Chavanton wrote:
Wonder where is it lost, we may need to run in debug mode to follow what is going on in db_postgress
I tried cranking up the debug considerably but did not gain any further insight.
-
Alex Balashov -
Charles Chance -
Julien Chavanton