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
