Excellent! Always happy to hear a success story — they usually don’t get reported.
> On Dec 1, 2021, at 7:52 AM, Rhys Hanrahan <[email protected]> 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" > <[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 -- 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
