Hi Alex,
Just wanted to say thanks for your guidance! I tried this out yesterday and it
seems to all be working great. This is what I came up with - hopefully I'm not
wrong anywhere, and hopefully this helps someone else!
I set path_use_received to 0, but left the other suggested params in place.
Then added the following. I didn't have to worry about RTP at this stage as I'm
not yet doing anything with RTP engine and it's all being handled by my
Asterisk PBXes which are further downstream.
request_route {
# per request initial checks
route(REQINIT);
# Handle DMQ
if (is_method("KDMQ") && $Rp == 5090)
{
dmq_handle_message();
}
...
# handle requests within SIP dialogs
route(WITHINDLG);
### only initial requests (no To tag)
# Handle quests routed from another DMQ node
# Run after WITHINDLG so that handle_ruri_alias() is handled
route(DMQ_HANDLE);
# authentication
route(AUTH);
...
}
In [REGISTRAR]:
# Add path header before saving usrloc
append_hf("Path: <sip:$Ri:$Rp;lr>\r\n");
# Must apply changes or they get lost when saving.
msg_apply_changes();
if (!save("location")) {
sl_reply_error();
}
exit;
}
# I am using RELAY as it's automatically handling t_on_reply cases.
route[DMQ_HANDLE] {
if (uri == myself) return;
if (!dmq_is_from_node()) return;
if (is_method("INVITE")) {
record_route(); # Keep this SBC in the signaling chain permanently.
}
route(RELAY);
}
Thanks,
Rhys.
On 30/11/21, 12:45 am, "sr-users on behalf of Alex Balashov"
<[email protected] on behalf of [email protected]>
wrote:
The reasoning for dispensing with received is that it’s just too
complicated and adds more moving parts than necessary. :-)
—
Sent from mobile, with due apologies for brevity and errors.
> On Nov 29, 2021, at 8:25 AM, Rhys Hanrahan <[email protected]> wrote:
>
> Thanks Alex!
>
> I am already doing steps 1, 2, 3 and 5, but I am using the received
parameter though, with "path_use_received". I am wondering what your reasoning
is to not use the received parameter? With it involved, things (including NAT
traversal) seem to mostly "just work", provided I set the destination URI on
the home registrar. Interested to know your reasoning, though? Will have to
work through your example and see how I go as it's a fair bit different to what
I have now and I'm still learning!
>
> Thanks for the tip on "dmq_is_from_node" - I was looking for a more
elegant way of allowing traffic from other SBCs without a bunch of IP
whitelists, and this looks like the way to go!
>
> Thanks for your help.
>
> Rhys.
>
> On 29/11/21, 11:44 pm, "Alex Balashov" <[email protected]> wrote:
>
> Hi,
>
> I had started the first of the original threads you referenced, so
thought I might chime in here. :-)
>
> The best practices here (in the eye of this beholder):
>
> 1) Enable `path_check_local` in the registrar module:
>
>
https://kamailio.org/docs/modules/stable/modules/registrar.html#registrar.p.path_check_local
>
> This will allow you to have the same logic on every node without
explicit attention in route config script to whether the home registrar of the
registering endpoint == myself.
>
> 2) Enable `use_path` in the registrar module in the first place:
>
>
https://kamailio.org/docs/modules/stable/modules/registrar.html#registrar.p.use_path
>
> This will allow `lookup()` to set the destination URI ($du)
transparently to you.
>
> 3) Set `path_mode` to 0 in registrar:
>
>
https://kamailio.org/docs/modules/stable/modules/registrar.html#registrar.p.path_mode
>
> 4) Dispense with `received` altogether and use only
`{set,add}_contact_alias()` and `handle_ruri_alias()` for server-side NAT
traversal.
>
> This concern was essentially spurious on my part.
>
> 5) Prior to `save()`ing a registration, add your own Path header with
the local hop address:
>
> append_hf(“Path: <sip:$Ri:5060;lr>\r\n”);
> msg_apply_changes(); # I forget if this is needed here.
>
> if(!save(“location”)) {
> …
> }
>
> 6) You need to add logic on the endpoint’s “home registrar” to pass
through requests bound for a local registrant but resolved on a different
ingress registrant, but still deal with NAT and such.
>
> I do this in the main request route using something like the below:
>
> route {
> …
>
> t_check_trans();
>
> …
>
> # Initial request handling of various kinds.
>
> if(uri == myself) {
> …
> } else {
> # Any initial requests not addressed to a local domain
> # are rejected unless they are laterally routed from a DMQ
> # peer.
>
> if(dmq_is_from_node()) {
> if(is_method(“INVITE”))
> record_route(); # Add ourselves to signalling chain.
>
> handle_ruri_alias();
>
> t_on_reply(“NAT_AND_SUCH_REPLY”);
>
> if(!t_relay())
> sl_reply_error();
> } else {
> sl_send_reply(“403”, “Forbidden”);
> }
> }
> }
>
> 7) Handle any RTP anchoring on the ingress proxy (the one the call
came in on) as opposed to the last-hop/home registrar.
>
> Hope that helps!
>
> — Alex
>
>> On Nov 29, 2021, at 4:23 AM, Rhys Hanrahan <[email protected]> wrote:
>>
>> Hi Everyone,
>>
>> I am trying to add DMQ for redundancy of registrations and USRLOC, and
I’m trying to send calls to the correct SBC that is the original registrar for
a handset. I’ve been using the thread here where Charles gave some guidance on
how to use path to store and use the original
SBC:https://lists.kamailio.org/pipermail/sr-users/2018-February/100246.html and
https://lists.kamailio.org/pipermail/sr-users/2013-September/079736.html
>>
>> I am struggling with when to decide to modify the destination URI. My
testing shows this is required otherwise some handsets will ignore the invite,
but right now I am doing it in a blanket form, right before SIPOUT (which is
where the origin SBC handles the invite instead of LOCATION). I am sure this is
being too heavy-handed though and there are some cases where I won’t want to
set this, but I am not sure which?
>>
>> # record routing for dialog forming requests (in case they are
routed)
>> # - remove preloaded route headers
>> remove_hf("Route");
>> if (is_method("INVITE|SUBSCRIBE")) {
>> record_route();
>> }
>> …
>> xlog("Setting du according to path. Current du is $du\n");
>> xlog("Current route header: $(hdr(Route))\n");
>> xlog("Current route: $(hdr(Route){uri.host})\n");
>>>>> $du = $(hdr(Route){param.value,received});
>> #xlog("New du destination uri is: $du\n");
>>
>> # dispatch requests to foreign domains
>> route(SIPOUT);
>>
>> In the linked threads, Charles mentioned that only the last-hop
registrar should make this change, but what’s the best way to determine if I am
on the last-hop registrar?
>>
>> As per the snippet above, I tried using the {uri.host} transformation to
extract the origin SBC’s IP from the route header. My plan is to then compare
this against “myself” but I am struggling to extract the right info from the
route header. And I am not even sure if this is the right general approach?
>>
>> The route header looks like
this:<sip:ORIGIN_SBC_IP:5060;received=sip:UAC_WAN_IP:2048;lr>
>>
>> Any guidance or examples would be appreciated.
>>
>> Thanks!
>>
>> Rhys Hanrahan | Chief Information Officer
>> e: [email protected]
>>
>> <image001.png> <image002.png>
>>
>> NEXUS ONE | FUSION TECHNOLOGY SOLUTIONS
>> p: 1800 NEXUS1 (1800 639 871) or 1800 565 845 | a: Suite 12.03 Level 12,
227 Elizabeth Street, Sydney NSW 2000
>> www.nexusone.com.au | www.fusiontech.com.au
>>
>> The information in this email and any accompanying attachments may
contain; a. Confidential information of Fusion Technology Solutions Pty Ltd,
Nexus One Pty Ltd or third parties; b. Legally privileged information of Fusion
Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; and or c.
Copyright material Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or
third parties. If you have received this email in error, please notify the
sender immediately and delete this message. Fusion Technology Solutions Pty
Ltd, Nexus One Pty Ltd does not accept any responsibility for loss or damage
arising from the use or distribution of this email.
>>
>> Please consider the environment before printing this email.
>>
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> * [email protected]
>> Important: keep the mailing list in the recipients, do not reply only to
the sender!
>> Edit mailing list options or unsubscribe:
>> * 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 - Users Mailing List - Non Commercial Discussions
> * [email protected]
> Important: keep the mailing list in the recipients, do not reply only
to the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> * [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
the sender!
> Edit mailing list options or unsubscribe:
> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* [email protected]
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
