15 Dec
2017
15 Dec
'17
10:31 p.m.
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/
15 Dec
15 Dec
11:52 p.m.
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(a)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/
18 Dec
18 Dec
2:50 p.m.
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(a)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:
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5 p.m.
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/
19 Dec
19 Dec
7:17 a.m.
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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7:26 a.m.
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/
7:33 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
7:58 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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/
1:30 p.m.
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(a)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:
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
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(a)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
","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}
;tag=36786f8e01b2230090da58c495caeae0-9338.
CSeq: 10 KDMQ.
Call-ID: 567aa40265453df7-29439(a)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(a)127.0.1.1
#
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(a)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
abalashov(a)evaristesys.com>
;expires=1917.
Server: kamailio (5.1.0
(x86_64/linux)).
Content-Length: 0.
.
On Mon, Dec 18, 2017 at 8:26 PM, Alex Balashov < 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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> _______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
10:37 p.m.
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/
10:43 p.m.
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(a)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/
11:05 p.m.
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(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
11:07 p.m.
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(a)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(a)evaristesys.com>
wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
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(a)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(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
11:08 p.m.
db_mode 1 also does not work.
On December 19, 2017 3:05:44 PM EST, Julien Chavanton <jchavanton(a)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(a)evaristesys.com>
wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
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(a)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(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
11:37 p.m.
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(a)evaristesys.com>
wrote:
db_mode 1 also does not work.
On December 19, 2017 3:05:44 PM EST, Julien Chavanton <
jchavanton(a)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(a)evaristesys.com>
wrote:
-- Alex
--
Sent via mobile, please forgive typos and brevity.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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(a)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(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
11:39 p.m.
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 | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
2530
days inactive
2534
days old
15 comments
3 participants
participants (3)
-
Alex Balashov -
Charles Chance -
Julien Chavanton