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
