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
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:
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/684059ca5bb76e2006a9560ac1efa8c3...
-- Alex
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@evaristesys.com wrote:
Hi Charles,
Thank you kindly for your response:
On Wed, Jan 31, 2018 at 04:53:09AM +0000, Charles Chance wrote:
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
Hi Alex
On Wed, 31 Jan 2018 at 05:35, Alex Balashov abalashov@evaristesys.com wrote:
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#registra... .
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
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:
Unfortunately, no luck with 5.1 either.
On Thu, Feb 01, 2018 at 02:49:32AM -0500, Alex Balashov wrote:
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@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@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
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@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:
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@evaristesys.com wrote:
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.
I have the latter set, but left the former two to defaults.
-- Alex
On 1 February 2018 at 19:02, Alex Balashov abalashov@evaristesys.com 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
Hi Charles,
By way of further update:
On Thu, Feb 01, 2018 at 07:06:41PM +0000, Charles Chance wrote:
path_mode 0 + path_check_local + append_hf() + msg_apply_changes() was indeed the winning formula. Thank you.
-- Alex
Hi Alex,
Thanks for the update - glad you solved it.
Cheers,
Charles
On Mon, 5 Feb 2018 at 14:41, Alex Balashov abalashov@evaristesys.com wrote:
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,
On 7 February 2018 at 18:05, Alex Balashov abalashov@evaristesys.com wrote:
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.
(2) When multiple Contact bindings are available for the same AOR, both
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
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@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@evaristesys.com:
-
Alex Balashov -
Carsten Bock -
Charles Chance