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
