Using path with DMQ to send calls to origin SBC - not sure when to modify destination URI
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: rhys@nexusone.com.au<mailto:rhys@nexusone.com.au> [www.nexusone.com.au]<http://www.nexusone.com.au/> [signature_555064778] <http://www.fusiontech.com.au/> 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<http://www.nexusone.com.au/> | www.fusiontech.com.au<http://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.
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.... 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.... 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.... 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 <rhys@nexusone.com.au> 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: rhys@nexusone.com.au
<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 * sr-users@lists.kamailio.org 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/
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" <abalashov@evaristesys.com> 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.... 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.... 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.... 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 <rhys@nexusone.com.au> 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: rhys@nexusone.com.au > > <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 > * sr-users@lists.kamailio.org > 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 * sr-users@lists.kamailio.org 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
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 <rhys@nexusone.com.au> 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" <abalashov@evaristesys.com> 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....
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....
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....
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 <rhys@nexusone.com.au> 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: rhys@nexusone.com.au
<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 * sr-users@lists.kamailio.org 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 * sr-users@lists.kamailio.org 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 * sr-users@lists.kamailio.org 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
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" <sr-users-bounces@lists.kamailio.org on behalf of abalashov@evaristesys.com> 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 <rhys@nexusone.com.au> 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" <abalashov@evaristesys.com> 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.... > > 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.... > > 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.... > > 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 <rhys@nexusone.com.au> 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: rhys@nexusone.com.au >> >> <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 >> * sr-users@lists.kamailio.org >> 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 > * sr-users@lists.kamailio.org > 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 > * sr-users@lists.kamailio.org > 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 * sr-users@lists.kamailio.org 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
Excellent! Always happy to hear a success story — they usually don’t get reported.
On Dec 1, 2021, at 7:52 AM, Rhys Hanrahan <rhys@nexusone.com.au> wrote:
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" <sr-users-bounces@lists.kamailio.org on behalf of abalashov@evaristesys.com> 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 <rhys@nexusone.com.au> 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" <abalashov@evaristesys.com> 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....
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....
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....
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 <rhys@nexusone.com.au> 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: rhys@nexusone.com.au
<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 * sr-users@lists.kamailio.org 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 * sr-users@lists.kamailio.org 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 * sr-users@lists.kamailio.org 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 * sr-users@lists.kamailio.org 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 * sr-users@lists.kamailio.org 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/
participants (2)
-
Alex Balashov -
Rhys Hanrahan