31 Jan
2018
31 Jan
'18
4:26 a.m.
Hi,
The Socket parameter of location entries is not replicated under
dmq_usrloc.
To make matters worse, the technical characteristics of the registrar
module are such that I cannot straightforwardly modify the incoming
Contact to add a rider indicating the server on which the register was
received.
The AoR domain is the same for all registrations received on any server
in the DMQ mesh.
To reach the registrants, I need to forward the registration to the
correct server that corresponds to the true provenance of the
registration. What is a reasonable way of finding out what that is? I
don't see any method of injecting such values into the replicated
contacts, as dmq_usrloc does not provide hooks for this.
Thanks,
-- 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/
31 Jan
31 Jan
4:29 a.m.
Also, it appears that under the DMQ regime, the socket parameter is not
set for locally received registrations either?
# kamcmd -s /tmp/kamailio_ctl ul.dump | grep Socket
Socket: [not set]
Socket: [not set]
Socket: [not set]
Socket: [not set]
Socket: [not set]
Socket: [not set]
Socket: [not set]
Socket: [not set]
-- Alex
On Tue, Jan 30, 2018 at 10:26:24PM -0500, Alex Balashov wrote:
Hi,
The Socket parameter of location entries is not replicated under
dmq_usrloc.
To make matters worse, the technical characteristics of the registrar
module are such that I cannot straightforwardly modify the incoming
Contact to add a rider indicating the server on which the register was
received.
The AoR domain is the same for all registrations received on any server
in the DMQ mesh.
To reach the registrants, I need to forward the registration to the
correct server that corresponds to the true provenance of the
registration. What is a reasonable way of finding out what that is? I
don't see any method of injecting such values into the replicated
contacts, as dmq_usrloc does not provide hooks for this.
Thanks,
-- 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/
4:32 a.m.
Ah, I guess this is the very problem that this relatively bleeding-edge
patch by Charles is meant to solve:
https://github.com/kamailio/kamailio/commit/684059ca5bb76e2006a9560ac1efa8c…
-- 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/
5:53 a.m.
Hi Alex,
Which version are you running? There were a few related patches recently -
the one you mentioned will correctly set the server_id, although on its own
will probably not help in the correct routing of requests. For that, I
would normally make use of Path.
The socket should indeed be set for locally received registrations - if not
then there is something wrong.
Cheers,
Charles
On 31 January 2018 at 03:32, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Ah, I guess this is the very problem that this
relatively bleeding-edge
patch by Charles is meant to solve:
https://github.com/kamailio/kamailio/commit/684059ca5bb76e2006a9560ac1efa8
c3540d3a58#diff-511a71ab6e3db75071b6a440618be1df
-- 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
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
6:33 a.m.
Hi Charles,
Thank you kindly for your response:
On Wed, Jan 31, 2018 at 04:53:09AM +0000, Charles Chance wrote:
Which version are you running? There were a few
related patches recently -
the one you mentioned will correctly set the server_id, although on its own
will probably not help in the correct routing of requests. For that, I
would normally make use of Path.
I am running 5.0, but taking into account newer patches in 5.1 as I look
for solutions.
I hadn't even thought of Path; I do see that it's replicated. However,
what are the consequences of adding a Path to a locally bound
registration that is also replicated? I would assume that would cause
outbound requests to the endpoint to loop through Kamailio. Is there a
means of adding Path only to replicated requests? Or am I mistaken about
the effect?
The Socket is definitely not set on any registrations, including local
ones. This is 5.0:60dc10a.
-- 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/
8:50 a.m.
Hi Alex
On Wed, 31 Jan 2018 at 05:35, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
I hadn't even thought of Path; I do see that it's replicated. However,
what are the consequences of adding a Path to a locally bound
registration that is also replicated? I would assume that would cause
outbound requests to the endpoint to loop through Kamailio. Is there a
means of adding Path only to replicated requests? Or am I mistaken about
the effect?
This module parameter will avoid any local looping and was added for this
very scenario:
https://www.kamailio.org/docs/modules/stable/modules/registrar.html#registr…
.
The Socket is definitely not set on any registrations, including local
ones. This is 5.0:60dc10a.
Let’s look into this - can you provide the relevant parts of your config
(mainly registrar/usrloc modparams and the route/section which handles
registrations)?
Best,
Charles
--
*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.
1 Feb
1 Feb
8:49 a.m.
Hi Charles,
It does not appear that Path is being replicated, either.
I am running add_path() prior to save()ing to usrloc, but on both hosts,
I see:
# kamcmd -s /tmp/kamailio_ctl ul.dump | grep -i path
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
This applies to both local registrations and replicated ones.
This is 5.0, though. Haven't tried 5.1 yet.
-- Alex
On Wed, Jan 31, 2018 at 04:53:09AM +0000, Charles Chance wrote:
Hi Alex,
Which version are you running? There were a few related patches recently -
the one you mentioned will correctly set the server_id, although on its own
will probably not help in the correct routing of requests. For that, I
would normally make use of Path.
The socket should indeed be set for locally received registrations - if not
then there is something wrong.
Cheers,
Charles
On 31 January 2018 at 03:32, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Ah, I guess this is the very problem that this
relatively bleeding-edge
patch by Charles is meant to solve:
https://github.com/kamailio/kamailio/commit/684059ca5bb76e2006a9560ac1efa8
c3540d3a58#diff-511a71ab6e3db75071b6a440618be1df
-- 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
--
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
--
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/
8:59 a.m.
Unfortunately, no luck with 5.1 either.
On Thu, Feb 01, 2018 at 02:49:32AM -0500, Alex Balashov wrote:
Hi Charles,
It does not appear that Path is being replicated, either.
I am running add_path() prior to save()ing to usrloc, but on both hosts,
I see:
# kamcmd -s /tmp/kamailio_ctl ul.dump | grep -i path
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
This applies to both local registrations and replicated ones.
This is 5.0, though. Haven't tried 5.1 yet.
-- Alex
On Wed, Jan 31, 2018 at 04:53:09AM +0000, Charles Chance wrote:
--
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/
Hi Alex,
Which version are you running? There were a few related patches recently -
the one you mentioned will correctly set the server_id, although on its own
will probably not help in the correct routing of requests. For that, I
would normally make use of Path.
The socket should indeed be set for locally received registrations - if not
then there is something wrong.
Cheers,
Charles
On 31 January 2018 at 03:32, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Ah, I guess this is the very problem that this
relatively bleeding-edge
patch by Charles is meant to solve:
https://github.com/kamailio/kamailio/commit/684059ca5bb76e2006a9560ac1efa8
c3540d3a58#diff-511a71ab6e3db75071b6a440618be1df
-- 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
--
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
--
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
9:05 a.m.
Hi Alex,
You’ll need to call msg_apply_changes before saving. Also, as I recall,
add_path will only work if relaying so you’ll need to add the header
manually. Something like this:
...
append_hf("Path:<sip:$Ri:$Rp;received=sip:$si:$sp;lr>\r\n");
msg_apply_changes();
...
Let me know if it works for you.
Cheers,
Charles
On Thu, 1 Feb 2018 at 07:52, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Hi Charles,
It does not appear that Path is being replicated, either.
I am running add_path() prior to save()ing to usrloc, but on both hosts,
I see:
# kamcmd -s /tmp/kamailio_ctl ul.dump | grep -i path
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
Path: [not set]
This applies to both local registrations and replicated ones.
This is 5.0, though. Haven't tried 5.1 yet.
-- Alex
On Wed, Jan 31, 2018 at 04:53:09AM +0000, Charles Chance wrote:
Registered
--
*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.
Hi Alex,
Which version are you running? There were a few related patches recently
-
the one you mentioned will correctly set the
server_id, although on its
own
will probably not help in the correct routing of
requests. For that, I
would normally make use of Path.
The socket should indeed be set for locally received registrations - if
not
then there is something wrong.
Cheers,
Charles
On 31 January 2018 at 03:32, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
> Ah, I guess this is the very problem that this relatively bleeding-edge
> patch by Charles is meant to solve:
>
>
https://github.com/kamailio/kamailio/commit/684059ca5bb76e2006a9560ac1efa8
c3540d3a58#diff-511a71ab6e3db75071b6a440618be1df
-- 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
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. 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
--
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
9:29 a.m.
Ah, thank you for that! I had tried calling msg_apply_changes() after
using add_path(), but didn't realise that it's dependent on relay rather
than just adding it to the existing message lumps. However, to your
point, the documentation does say that the "outgoing" interface address
is populated by add_path*(), which of course means that has to be known.
Nevertheless, Path is not being replicated. Furthermore, after upgrading
to 5.1, I am not getting any replication of remote contacts whatsoever,
even with no path involvement. And "socket" is still not an attribute of
the DMQ messages being passed:
KDMQ sip:usrloc@100.2.160.20 SIP/2.0
Via: SIP/2.0/UDP 100.2.128.20;branch=z9hG4bKc0ec.d07b9da1000000000000000000000000.0
To: <sip:usrloc@100.2.160.20>
From: <sip:usrloc@100.2.128.20:5060>;tag=68a630e496181361fe35a2f5a89714ad-02ab
CSeq: 10 KDMQ
Call-ID: 4cf0c5e5257bcb22-6408(a)100.2.99.211
Content-Length: 461
User-Agent: kamailio (5.1.1 (x86_64/linux))
Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"marshal@org","ruid":"uloc-5a712c1a-1901-dae1","c":"sip:va-server@100.2.129.149:6060;ob","received":"sip:100.2.129.149:6060","path":"","callid":"R6m3zCogWsifTLebJ7n6zmlGHOwk1xA6","user_agent":"CallServer","instance":"","expires":1517473708,"cseq":5015,"flags":0,"cflags":0,"q":0,"last_modified":1517473678,"methods":8159,"reg_id":0,"server_id":0}
-- 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/
9:44 a.m.
Hi Alex,
Socket is never replicated but path definitely should be.
Without DMQ involved and simply saving locally (with path header added
first) can you show me the output of ul.dump?
Cheers,
Charles
On Thu, 1 Feb 2018 at 08:31, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Ah, thank you for that! I had tried calling
msg_apply_changes() after
using add_path(), but didn't realise that it's dependent on relay rather
than just adding it to the existing message lumps. However, to your
point, the documentation does say that the "outgoing" interface address
is populated by add_path*(), which of course means that has to be known.
Nevertheless, Path is not being replicated. Furthermore, after upgrading
to 5.1, I am not getting any replication of remote contacts whatsoever,
even with no path involvement. And "socket" is still not an attribute of
the DMQ messages being passed:
KDMQ sip:usrloc@100.2.160.20 SIP/2.0
Via: SIP/2.0/UDP
100.2.128.20;branch=z9hG4bKc0ec.d07b9da1000000000000000000000000.0
To: <sip:usrloc@100.2.160.20>
From: <sip:usrloc@100.2.128.20:5060
--
*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.
;tag=68a630e496181361fe35a2f5a89714ad-02ab
CSeq: 10 KDMQ
Call-ID: 4cf0c5e5257bcb22-6408(a)100.2.99.211
Content-Length: 461
User-Agent: kamailio (5.1.1 (x86_64/linux))
Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"marshal@org
","ruid":"uloc-5a712c1a-1901-dae1","c":"sip:va-server@100.2.129.149:6060
;ob","received":"sip:100.2.129.149:6060
","path":"","callid":"R6m3zCogWsifTLebJ7n6zmlGHOwk1xA6","user_agent":"CallServer","instance":"","expires":1517473708,"cseq":5015,"flags":0,"cflags":0,"q":0,"last_modified":1517473678,"methods":8159,"reg_id":0,"server_id":0}
-- 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:47 p.m.
Hi Charles,
ul.dump reflects that Path is not being applied to the local contact, so
it should come as no surprise that it's not being replicated either.
I added this:
append_hf("Path: <sip:$Ri:$Rp;lr>\r\n");
msg_apply_changes();
if(!save("location")) {
...
}
...
-- Alex
On Thu, Feb 01, 2018 at 08:44:38AM +0000, Charles Chance wrote:
Hi Alex,
Socket is never replicated but path definitely should be.
Without DMQ involved and simply saving locally (with path header added
first) can you show me the output of ul.dump?
Cheers,
Charles
On Thu, 1 Feb 2018 at 08:31, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Ah, thank you for that! I had tried calling
msg_apply_changes() after
using add_path(), but didn't realise that it's dependent on relay rather
than just adding it to the existing message lumps. However, to your
point, the documentation does say that the "outgoing" interface address
is populated by add_path*(), which of course means that has to be known.
Nevertheless, Path is not being replicated. Furthermore, after upgrading
to 5.1, I am not getting any replication of remote contacts whatsoever,
even with no path involvement. And "socket" is still not an attribute of
the DMQ messages being passed:
KDMQ sip:usrloc@100.2.160.20 SIP/2.0
Via: SIP/2.0/UDP
100.2.128.20;branch=z9hG4bKc0ec.d07b9da1000000000000000000000000.0
To: <sip:usrloc@100.2.160.20>
From: <sip:usrloc@100.2.128.20:5060
--
*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. ;tag=68a630e496181361fe35a2f5a89714ad-02ab
CSeq: 10 KDMQ
Call-ID: 4cf0c5e5257bcb22-6408(a)100.2.99.211
Content-Length: 461
User-Agent: kamailio (5.1.1 (x86_64/linux))
Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"marshal@org
","ruid":"uloc-5a712c1a-1901-dae1","c":"sip:va-server@100.2.129.149:6060
;ob","received":"sip:100.2.129.149:6060
","path":"","callid":"R6m3zCogWsifTLebJ7n6zmlGHOwk1xA6","user_agent":"CallServer","instance":"","expires":1517473708,"cseq":5015,"flags":0,"cflags":0,"q":0,"last_modified":1517473678,"methods":8159,"reg_id":0,"server_id":0}
-- 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/
7:57 p.m.
Hi Alex,
Just to confirm, do you have use_path set?
modparam("registrar", "use_path", 1)
For your setup I'd also recommend setting:
modparam("registrar", "path_mode", 0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local", 1)
Cheers,
Charles
On 1 February 2018 at 18:47, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Hi Charles,
ul.dump reflects that Path is not being applied to the local contact, so
it should come as no surprise that it's not being replicated either.
I added this:
append_hf("Path: <sip:$Ri:$Rp;lr>\r\n");
msg_apply_changes();
if(!save("location")) {
...
}
...
-- Alex
On Thu, Feb 01, 2018 at 08:44:38AM +0000, Charles Chance wrote:
Registered
--
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 Alex,
Socket is never replicated but path definitely should be.
Without DMQ involved and simply saving locally (with path header added
first) can you show me the output of ul.dump?
Cheers,
Charles
On Thu, 1 Feb 2018 at 08:31, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
> Ah, thank you for that! I had tried calling msg_apply_changes() after
> using add_path(), but didn't realise that it's dependent on relay
rather
> than just adding it to the existing message
lumps. However, to your
> point, the documentation does say that the "outgoing" interface address
> is populated by add_path*(), which of course means that has to be
known.
>
> Nevertheless, Path is not being replicated. Furthermore, after
upgrading
> to 5.1, I am not getting any replication of
remote contacts whatsoever,
> even with no path involvement. And "socket" is still not an attribute
of
> the DMQ messages being passed:
>
> KDMQ sip:usrloc@100.2.160.20 SIP/2.0
> Via: SIP/2.0/UDP
> 100.2.128.20;branch=z9hG4bKc0ec.d07b9da1000000000000000000000000.0
> To: <sip:usrloc@100.2.160.20>
> From: <sip:usrloc@100.2.128.20:5060
> >;tag=68a630e496181361fe35a2f5a89714ad-02ab
> CSeq: 10 KDMQ
> Call-ID: 4cf0c5e5257bcb22-6408(a)100.2.99.211
> Content-Length: 461
> User-Agent: kamailio (5.1.1 (x86_64/linux))
> Max-Forwards: 1
> Content-Type: application/json
>
> {"action":1,"aor":"marshal@org
>
","ruid":"uloc-5a712c1a-1901-dae1","c":"sip:va-server@100.
2.129.149:6060
>
;ob","received":"sip:100.2.129.149:6060
>
","path":"","callid":"R6m3zCogWsifTLebJ7n6zmlGHOwk1x
A6","user_agent":"CallServer","instance":"","expires":
1517473708,"cseq":5015,"flags":0,"cflags":0,"q":0,"last_
modified":1517473678,"methods":8159,"reg_id":0,"server_id":0}
-- 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
--
*Charles Chance*
Managing Director
t. 0330 120 1200 m. 07932 063 891
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. 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
--
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
8:02 p.m.
On Thu, Feb 01, 2018 at 06:57:03PM +0000, Charles Chance wrote:
Just to confirm, do you have use_path set?
modparam("registrar", "use_path", 1)
I do indeed.
modparam("registrar", "path_mode",
0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local", 1)
I have the latter set, but left the former two to defaults.
-- 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/
8:06 p.m.
On 1 February 2018 at 19:02, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
On Thu, Feb 01, 2018 at 06:57:03PM +0000, Charles
Chance wrote:
That may be the issue then, I think. The default for path_mode is 2:
"The path header is only saved into usrloc, if path support is indicated in
the registration request by the “path” option of the “Supported” header."
Can you try with the suggested values?
Cheers,
Charles
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
Just to confirm, do you have use_path set?
modparam("registrar", "use_path", 1)
I do indeed.
modparam("registrar",
"path_mode", 0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local", 1)
I have the latter set, but left the former two to defaults.
5 Feb
5 Feb
3:40 p.m.
Hi Charles,
By way of further update:
On Thu, Feb 01, 2018 at 07:06:41PM +0000, Charles Chance wrote:
That may be the issue then, I think. The default for path_mode is 2:
"The path header is only saved into usrloc, if path support is indicated in
the registration request by the “path” option of the “Supported” header."
path_mode 0 + path_check_local + append_hf() + msg_apply_changes() was
indeed the winning formula. Thank you.
-- 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/
modparam("registrar", "path_mode",
0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local", 1)
I have the latter set, but left the former two to defaults.
4:32 p.m.
Hi Alex,
Thanks for the update - glad you solved it.
Cheers,
Charles
On Mon, 5 Feb 2018 at 14:41, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Hi Charles,
By way of further update:
On Thu, Feb 01, 2018 at 07:06:41PM +0000, Charles Chance wrote:
That may be the issue then, I think. The default for path_mode is 2:
"The path header is only saved into usrloc, if path support is indicated in
--
*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.
modparam("registrar", "path_mode",
0)
modparam("registrar", "path_use_received", 1)
modparam("registrar", "path_check_local", 1)
I have the latter set, but left the former two to defaults.
the registration request by the “path” option of
the “Supported” header."
path_mode 0 + path_check_local + append_hf() + msg_apply_changes() was
indeed the winning formula. Thank you.
-- 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 Feb
7 Feb
7:05 p.m.
Hi Charles,
A few other questions arise, mostly as a matter of best practices rather
than functional possibility:
(1) Most of the endpoints in question are NAT'd, and I was using
fix_nated_register() and the "received AVP" for mitigation.
Although the "Received" address is replicated by DMQ, using Path to
discover the adjacent "last hop" registrar overwrites the destination
set and stops the 'received' parameter from being utilised. Moreover,
there is no way to intercept it before the lookup() overwrites $du with
Path instead of 'received'.
There are two solutions to this; one is to send the call to the last-hop
registrar and have it re-do the lookup(), reviving the 'received'
attribute. The requires transmitting the original AOR to be looked up as
a custom header or whatnot. The other option is to manually fetch the
'received' attribute subsequent to the lookup() on the source
(first/egress hop) registrar using reg_fetch_contacts(), which is what I
currently do. I stick that in a custom header instead.
Another option is to change the NAT traversal approach altogether and
instead of using the 'received' attribute, use set_contact_alias() to
modify the stored Contact everywhere.
Perhaps the latter option is the simplest of all, but I am curious as to
whether you have an opinion on possible pitfalls and virtues in the
context of a dmq_usrloc-replicated registrar cluster.
(2) When multiple Contact bindings are available for the same AOR, both
local and remote, it would be desirable to have an easy way of selecting
the most adjacent one (i.e. the local one, in preference to the ones
removed by one Path hop).
Is there a nonobvious easy way to accomplish this, or am I going to have
to switch from lookup() to reg_fetch_contacts() or walk the lookup()'d
branches and find the one I want?
Thanks,
-- Alex
On Mon, Feb 05, 2018 at 03:32:21PM +0000, Charles Chance wrote:
Hi Alex,
Thanks for the update - glad you solved it.
Cheers,
Charles
On Mon, 5 Feb 2018 at 14:41, Alex Balashov <abalashov(a)evaristesys.com>
wrote:
Hi Charles,
By way of further update:
On Thu, Feb 01, 2018 at 07:06:41PM +0000, Charles Chance wrote:
in
--
*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. >
modparam("registrar", "path_mode", 0)
> modparam("registrar", "path_use_received", 1)
> modparam("registrar", "path_check_local", 1)
I have the latter set, but left the former two to defaults.
That may be the issue then, I think. The default for path_mode is 2:
"The path header is only saved into usrloc, if path support is indicated the registration request by the “path” option of
the “Supported” header."
path_mode 0 + path_check_local + append_hf() + msg_apply_changes() was
indeed the winning formula. Thank you.
-- 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/
11:35 p.m.
Hi Alex,
On 7 February 2018 at 18:05, Alex Balashov <abalashov(a)evaristesys.com wrote:
(2) When multiple Contact bindings are available
for the same AOR, both
> local and remote, it would be desirable to have an easy way of selecting
> the most adjacent one (i.e. the local one, in preference to the ones
> removed by one Path hop).
> Is there a nonobvious easy way to
accomplish this, or am I going to have
> to switch from lookup() to reg_fetch_contacts() or walk the lookup()'d
> branches and find the one I want?
I'm unsure about that one, I'm afraid, since we generally just append
branches for all contacts in parallel (which lookup(), combined with the
above, does very well).
There may be something that can be done with dmq_usrloc and q value, to
ensure that local contacts have a higher priority - and then set
append_branches parameter to 0 - but I am unaware of any existing way to
accomplish it without, as you suggest, switching to reg_fetch_contacts().
Cheers,
Charles
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
(1) Most of the endpoints in question are NAT'd, and I was using
fix_nated_register() and the "received AVP" for mitigation.
Although the "Received" address is replicated by DMQ, using Path to
discover the adjacent "last hop" registrar overwrites the destination
set and stops the 'received' parameter from being utilised. Moreover,
there is no way to intercept it before the lookup() overwrites $du with
Path instead of 'received'.
I would typically append the received IP/port to the Path header before
saving:
append_hf("Path: <sip:$Ri:$Rp;received=sip:$si:$sp;lr>\r\n");
The last-hop registrar (as defined in Path uri) can then do something
like...
$du = $(hdr(Route){param.value,received});
...before sending it on its way.
I recall that we also set path_use_received parameter, although from memory
I couldn't say for sure if the above depended on it.
1 Feb
1 Feb
10:01 a.m.
Hi Alex,
i have a setup, where I do a similar thing (except that the
Path-Header is added by another Proxy in front of Kamailio). I can
confirm, that "dmq_usrloc" replicates the Path as well on Kamailio
5.0.5:
U 2018/02/01 09:56:44.779300 37.120.180.58:5060 -> 37.120.181.229:5060
KDMQ sip:usrloc@37.120.181.229:5060 SIP/2.0.
Via: SIP/2.0/UDP
37.120.180.58;branch=z9hG4bK2d05.fd672857000000000000000000000000.0.
To: <sip:usrloc@37.120.181.229:5060>.
From: <sip:usrloc@37.120.180.58:5060>;tag=e94ea6a75c2153ce030bc5ab6be9dab2-364e.
CSeq: 10 KDMQ.
Call-ID: 24984627006a76f0-18299(a)37.120.180.58.
Content-Length: 436.
User-Agent: Registrar.
Max-Forwards: 1.
Content-Type: application/json.
.
{"action":1,"aor":"b0bba8305d50a86667e5f4ee681eb1238f370e64@localhost","ruid":"uloc-5a5bd00d-4772-245f2","c":"sip:ab21155bd3a2f8e7@37.120.181.198:5070;transport=udp","received":"","path":"<sip:37.120.180.6:5060;lr>","callid":"6D5E123F-5A72D64C000BD2B4-E2316700","user_agent":"STARFACE
PBX","instance":"","expires":1517476004,"cseq":10,"flags":0,"cflags":0,"q":-1,"last_modified":1517475404,"methods":4294967295,"reg_id":0,"server_id":0}
You said, that Path is not populated even in the local registry.
Probably you should check this without DMQ initially, because I
believe at least locally without DMQ the Path should be populated in
your config.
Thanks,
Carsten
2018-02-01 9:29 GMT+01:00 Alex Balashov <abalashov(a)evaristesys.com>om>:
Ah, thank you for that! I had tried calling
msg_apply_changes() after
using add_path(), but didn't realise that it's dependent on relay rather
than just adding it to the existing message lumps. However, to your
point, the documentation does say that the "outgoing" interface address
is populated by add_path*(), which of course means that has to be known.
Nevertheless, Path is not being replicated. Furthermore, after upgrading
to 5.1, I am not getting any replication of remote contacts whatsoever,
even with no path involvement. And "socket" is still not an attribute of
the DMQ messages being passed:
KDMQ sip:usrloc@100.2.160.20 SIP/2.0
Via: SIP/2.0/UDP 100.2.128.20;branch=z9hG4bKc0ec.d07b9da1000000000000000000000000.0
To: <sip:usrloc@100.2.160.20>
From: <sip:usrloc@100.2.128.20:5060>;tag=68a630e496181361fe35a2f5a89714ad-02ab
CSeq: 10 KDMQ
Call-ID: 4cf0c5e5257bcb22-6408(a)100.2.99.211
Content-Length: 461
User-Agent: kamailio (5.1.1 (x86_64/linux))
Max-Forwards: 1
Content-Type: application/json
{"action":1,"aor":"marshal@org","ruid":"uloc-5a712c1a-1901-dae1","c":"sip:va-server@100.2.129.149:6060;ob","received":"sip:100.2.129.149:6060","path":"","callid":"R6m3zCogWsifTLebJ7n6zmlGHOwk1xA6","user_agent":"CallServer","instance":"","expires":1517473708,"cseq":5015,"flags":0,"cflags":0,"q":0,"last_modified":1517473678,"methods":8159,"reg_id":0,"server_id":0}
-- 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
--
Carsten Bock
CEO (Geschäftsführer)
Meet us at MWC 2018 in Barcelona and see IMS and VoLTE in action!
(February 26th - March 1st, Hall 7 - Booth 7L80)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:carsten@ng-voice.com
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
2271
days inactive
2278
days old
19 comments
3 participants
participants (3)
-
Alex Balashov -
Carsten Bock -
Charles Chance