4 Dec
2019
4 Dec
'19
10:48 p.m.
Hi guys.
I'm setting up an anycast scenario with several kamailios sharing an active
state and I've noticed that the dmq_usrloc module is not replication the
usrloc socket_info attribute when a register comes in through one of the
kamailio nodes. Is there a reason behind this?
I'm thinking on adding the replication for that attribute in the code.
Another way of address this woud be by having a modparam to replicate the
socket.
What do you think?
This is what I'm seeing:
*anycast node that actually gets the SIP REGISTER:*
$ kamcmd ul.dump
{
Domains: {
Domain: {
Domain: location
Size: 32768
AoRs: {
Info: {
AoR: 309(a)nmreis.test
HashID: -35263718
Contacts: {
Contact: {
Address:
sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test
Expires: 585
Q: -1.000000
Call-ID:
6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0
CSeq: 4
User-Agent:
Jitsi2.11.5602Linux
Received: sip:
2.2.2.2:31171
Path: [not set]
State: CS_SYNC
Flags: 1
CFlags: 192
Socket: udp:
1.1.1.1:5060
Methods: -1
Ruid:
uloc-5de8056d-22ab-f
Instance: [not set]
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive:
1575487540
Last-Modified:
1575487540
}
}
}
}
Stats: {
Records: 1
Max-Slots: 1
}
}
}
}
*anycast node that gets the USRLOC update via KDMQ:*
$ kamcmd ul.dump
{
Domains: {
Domain: {
Domain: location
Size: 32768
AoRs: {
Info: {
AoR: 309(a)nmreis.test
HashID: -35263718
Contacts: {
Contact: {
Address:
sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test
Expires: 574
Q: -1.000000
Call-ID:
6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0
CSeq: 4
User-Agent:
Jitsi2.11.5602Linux
Received: sip:
2.2.2.2:31171
Path: [not set]
State: CS_SYNC
Flags: 1
CFlags: 192
Socket: [not set]
Methods: -1
Ruid:
uloc-5de7ff7b-4617-3
Instance: [not set]
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive:
1575487540
Last-Modified:
1575487540
}
}
}
}
Stats: {
Records: 1
Max-Slots: 1
}
}
}
}
*the actual KDMQ message:*
*KDMQ sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060>
SIP/2.0 Via: SIP/2.0/UDP
10.100.100.22;branch=z9hG4bK6034.290e4186000000000000000000000000.0 To:
<sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060>>
From: <sip:usrloc@10.100.100.22:5060
<http://sip:usrloc@10.100.100.22:5060>>;tag=3393f0703fb0ccaca74109ff37de39f5-1e4c092b
CSeq: 10 KDMQ Call-ID: 0cfde4d32a31addc-8875(a)127.0.0.1
<0cfde4d32a31addc-8875(a)127.0.0.1> Content-Length: 433 Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"309@nmreis.test","ruid":"uloc-5de8056d-22ab-f","c":"sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test","received":"sip:2.2.2.2:31171
<http://2.2.2.2:31171>","path":"","callid":"6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0","user_agent":"Jitsi2.11.5602Linux","instance":"","expires":1575487600,"cseq":2,"flags":1,"cflags":192,"q":-1,"last_modified":1575487000,"methods":4294967295,"reg_id":0,"server_id":0}*
--
Nuno Miguel Reis
Departamento de Engenharia Informática
Faculdade de Ciências e Tecnologia
Universidade de Coimbra
mobile: +351 918519145
--
get my PGP key @
http://pgp.dei.uc.pt:11371/pks/lookup?op=get&search=0x750296EECEAD2B6D
5 Dec
5 Dec
2:16 a.m.
Hello,
I don't see a problem with replicating the socket in this case, although I
agree it should be enabled with a modparam to avoid breaking existing
unicast deployments.
Feel free to submit a PR or I can try to add it over the coming week.
Best regards,
Charles
On Wed, 4 Dec 2019 at 19:51, Nuno Miguel Reis <nmreis(a)student.dei.uc.pt>
wrote:
Hi guys.
I'm setting up an anycast scenario with several kamailios sharing an
active state and I've noticed that the dmq_usrloc module is not replication
the usrloc socket_info attribute when a register comes in through one of
the kamailio nodes. Is there a reason behind this?
I'm thinking on adding the replication for that attribute in the code.
Another way of address this woud be by having a modparam to replicate the
socket.
What do you think?
This is what I'm seeing:
*anycast node that actually gets the SIP REGISTER:*
$ kamcmd ul.dump
{
Domains: {
Domain: {
Domain: location
Size: 32768
AoRs: {
Info: {
AoR: 309(a)nmreis.test
HashID: -35263718
Contacts: {
Contact: {
Address:
sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test
Expires: 585
Q: -1.000000
Call-ID:
6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0
CSeq: 4
User-Agent:
Jitsi2.11.5602Linux
Received: sip:
2.2.2.2:31171
Path: [not set]
State: CS_SYNC
Flags: 1
CFlags: 192
Socket: udp:
1.1.1.1:5060
Methods: -1
Ruid:
uloc-5de8056d-22ab-f
Instance: [not set]
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive:
1575487540
Last-Modified:
1575487540
}
}
}
}
Stats: {
Records: 1
Max-Slots: 1
}
}
}
}
*anycast node that gets the USRLOC update via KDMQ:*
$ kamcmd ul.dump
{
Domains: {
Domain: {
Domain: location
Size: 32768
AoRs: {
Info: {
AoR: 309(a)nmreis.test
HashID: -35263718
Contacts: {
Contact: {
Address:
sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test
Expires: 574
Q: -1.000000
Call-ID:
6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0
CSeq: 4
User-Agent:
Jitsi2.11.5602Linux
Received: sip:
2.2.2.2:31171
Path: [not set]
State: CS_SYNC
Flags: 1
CFlags: 192
Socket: [not set]
Methods: -1
Ruid:
uloc-5de7ff7b-4617-3
Instance: [not set]
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive:
1575487540
Last-Modified:
1575487540
}
}
}
}
Stats: {
Records: 1
Max-Slots: 1
}
}
}
}
*the actual KDMQ message:*
*KDMQ sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060>
SIP/2.0 Via: SIP/2.0/UDP
10.100.100.22;branch=z9hG4bK6034.290e4186000000000000000000000000.0 To:
<sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060>>
From: <sip:usrloc@10.100.100.22:5060
<http://sip:usrloc@10.100.100.22:5060>>;tag=3393f0703fb0ccaca74109ff37de39f5-1e4c092b
CSeq: 10 KDMQ Call-ID: 0cfde4d32a31addc-8875(a)127.0.0.1
<0cfde4d32a31addc-8875(a)127.0.0.1> Content-Length: 433 Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"309@nmreis.test","ruid":"uloc-5de8056d-22ab-f","c":"sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test","received":"sip:2.2.2.2:31171
<http://2.2.2.2:31171>","path":"","callid":"6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0","user_agent":"Jitsi2.11.5602Linux","instance":"","expires":1575487600,"cseq":2,"flags":1,"cflags":192,"q":-1,"last_modified":1575487000,"methods":4294967295,"reg_id":0,"server_id":0}*
--
Nuno Miguel Reis
Departamento de Engenharia Informática
Faculdade de Ciências e Tecnologia
Universidade de Coimbra
mobile: +351 918519145
--
get my PGP key @
http://pgp.dei.uc.pt:11371/pks/lookup?op=get&search=0x750296EECEAD2B6D
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Sipcentric Ltd.
Company registered in England & Wales no.
7365592. Registered
office: Faraday Wharf, Innovation
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
3:04 a.m.
I Charles. Thanks for replying me back.
I'll try to patch the code tomorrow. I let you know if I need any help with
that.
Thanks.
--
Nuno Miguel Reis | Unified Communication Systems
WAVECOM - Soluções Rádio, S.A.
Cacia Park | Rua do Progresso, Lote 15
3800-639 AVEIRO | Portugal
mobile: +351 918519145
On Wed, Dec 4, 2019, 23:16 Charles Chance <charles.chance(a)sipcentric.com>
wrote:
Hello,
I don't see a problem with replicating the socket in this case, although I
agree it should be enabled with a modparam to avoid breaking existing
unicast deployments.
Feel free to submit a PR or I can try to add it over the coming week.
Best regards,
Charles
On Wed, 4 Dec 2019 at 19:51, Nuno Miguel Reis <nmreis(a)student.dei.uc.pt>
wrote:
Hi guys.
I'm setting up an anycast scenario with several kamailios sharing an
active state and I've noticed that the dmq_usrloc module is not replication
the usrloc socket_info attribute when a register comes in through one of
the kamailio nodes. Is there a reason behind this?
I'm thinking on adding the replication for that attribute in the code.
Another way of address this woud be by having a modparam to replicate the
socket.
What do you think?
This is what I'm seeing:
*anycast node that actually gets the SIP REGISTER:*
$ kamcmd ul.dump
{
Domains: {
Domain: {
Domain: location
Size: 32768
AoRs: {
Info: {
AoR: 309(a)nmreis.test
HashID: -35263718
Contacts: {
Contact: {
Address:
sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test
Expires: 585
Q: -1.000000
Call-ID:
6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0
CSeq: 4
User-Agent:
Jitsi2.11.5602Linux
Received: sip:
2.2.2.2:31171
Path: [not set]
State: CS_SYNC
Flags: 1
CFlags: 192
Socket: udp:
1.1.1.1:5060
Methods: -1
Ruid:
uloc-5de8056d-22ab-f
Instance: [not
set]
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive:
1575487540
Last-Modified:
1575487540
}
}
}
}
Stats: {
Records: 1
Max-Slots: 1
}
}
}
}
*anycast node that gets the USRLOC update via KDMQ:*
$ kamcmd ul.dump
{
Domains: {
Domain: {
Domain: location
Size: 32768
AoRs: {
Info: {
AoR: 309(a)nmreis.test
HashID: -35263718
Contacts: {
Contact: {
Address:
sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test
Expires: 574
Q: -1.000000
Call-ID:
6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0
CSeq: 4
User-Agent:
Jitsi2.11.5602Linux
Received: sip:
2.2.2.2:31171
Path: [not set]
State: CS_SYNC
Flags: 1
CFlags: 192
Socket: [not set]
Methods: -1
Ruid:
uloc-5de7ff7b-4617-3
Instance: [not
set]
Reg-Id: 0
Server-Id: 0
Tcpconn-Id: -1
Keepalive: 1
Last-Keepalive:
1575487540
Last-Modified:
1575487540
}
}
}
}
Stats: {
Records: 1
Max-Slots: 1
}
}
}
}
*the actual KDMQ message:*
*KDMQ sip:usrloc@10.100.100.21:5060
<http://sip:usrloc@10.100.100.21:5060> SIP/2.0 Via: SIP/2.0/UDP
10.100.100.22;branch=z9hG4bK6034.290e4186000000000000000000000000.0 To:
<sip:usrloc@10.100.100.21:5060 <http://sip:usrloc@10.100.100.21:5060>>
From: <sip:usrloc@10.100.100.22:5060
<http://sip:usrloc@10.100.100.22:5060>>;tag=3393f0703fb0ccaca74109ff37de39f5-1e4c092b
CSeq: 10 KDMQ Call-ID: 0cfde4d32a31addc-8875(a)127.0.0.1
<0cfde4d32a31addc-8875(a)127.0.0.1> Content-Length: 433 Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"309@nmreis.test","ruid":"uloc-5de8056d-22ab-f","c":"sip:309@192.168.150.158:55060;transport=udp;registering_acc=nmreis_test","received":"sip:2.2.2.2:31171
<http://2.2.2.2:31171>","path":"","callid":"6e7635ce4604e16400ee763b2ead55b2@0:0:0:0:0:0:0:0","user_agent":"Jitsi2.11.5602Linux","instance":"","expires":1575487600,"cseq":2,"flags":1,"cflags":192,"q":-1,"last_modified":1575487000,"methods":4294967295,"reg_id":0,"server_id":0}*
--
Nuno Miguel Reis
Departamento de Engenharia Informática
Faculdade de Ciências e Tecnologia
Universidade de Coimbra
mobile: +351 918519145
--
get my PGP key @
http://pgp.dei.uc.pt:11371/pks/lookup?op=get&search=0x750296EECEAD2B6D
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1814
days inactive
1815
days old
2 comments
2 participants
participants (2)
-
Charles Chance -
Nuno Miguel Reis