In thinking through it a bit more, I think I understand better now. You want to interrogate -- that is, to query -- the location service via redirect rather than by sending a request directly to it, and you want the returned coordinates for the AOR being interrogated to incorporate the path hop so that the querying entity can send requests to it through that adjacency (RS) rather than directly to it.
It might have been easier if you explicitly stated that. :-) Contact addresses in 3xx replies generated by Kamailio come from the destination set of the branches resolved via a lookup(). By default, the Request URI of an incoming request is set to the resolved Contact in the registrar, but if you set a destination next-hop ($du) equal to the Path hop, which should happen automatically if this[1] and other Path-related parameters are set to enabled, that's what should be returned in a 3xx constructed by Kamailio from the preloaded branches. At least, that is how I understand it. So, in fact, Kamailio does accommodate this use-case in a canned way, it's just not very obvious. -- Alex [1] https://kamailio.org/docs/modules/5.7.x/modules/registrar.html#registrar.p.use_path > On 27 Oct 2023, at 10:59, Alex Balashov <abalas...@evaristesys.com> wrote: > > Yes, the remove_hf() et al. functions are designed to operate on requests. > Only a small subset of textops-family manipulation functions operate on > replies, and they should be explicitly labelled or named in a way that > reflects that. > > I can't say I understand the scenario you've outlined, either, but prima > facie, it seems bizarre. Why would you put the Path value into a 302 > redirect? The Path value simply provides a next-hop in a trapezoid where the > registrar is reached indirectly through an intermediate proxy. > > It may be the case that you're doing something in a roundabout way that > routes around the simpler, "baked in" scenarios Kamailio is prepared to > handle... > > -- Alex > >> On 27 Oct 2023, at 10:23, Jawaid Bazyar via sr-users >> <sr-users@lists.kamailio.org> wrote: >> >> Hi Henning, thanks for your reply. >> I have successfully used PATH before as you describe. >> This model, however, I am having Kamailio issue a 302 Redirect, and, I need >> to take the recorded PATH information and put it into the 302 Redirect >> Contact field, to send back with sl_send_reply. Sl_send_reply does not seem >> to do that automatically even after a lookup() and reg_fetch. >> I was able to figure out the textops transforms and get the data into a >> Contact header, though I’m not 100% confident I’m creating a correct >> Contact, as sometimes the PATH can be quite complex and I’m taking only the >> host part and reconstructing a contact from that. I guess I will have to >> scour the RFC and do some learning 😊 >> I was hoping this particular scenario had been baked into Kamailio >> previously and I just needed to find the right configuration options to >> exercise it. >> On my second issue: >> I am left however with an inability to remove the existing Contact from the >> reply. I tried remove_hf before sl_send_reply, but either it doesn’t remove >> the Contact field, or, sl_send_reply adds the Contact field. >> From: Henning Westerholt <h...@gilawa.com> >> Date: Friday, October 27, 2023 at 10:10 AM >> To: "Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org> >> Cc: Jawaid Bazyar <baz...@gmail.com> >> Subject: RE: Registrar / Path >> Hello, >> I probably failed to understand your scenario completely. >> But basically, if you want to just forward REGISTER message from one >> Kamailio to the other, you can use “forward()” or “r_relay()” for stateless >> respectively stateful forwarding. The path extension was designed to take >> the same way routing e.g. an INVITE to an user agent as it came through your >> infrastructure. It will work automatically by setting the destination URI if >> it path is set and you are using the “lookup(..)” function. >> Cheers, >> Henning >> -- Henning Westerholt – https://skalatan.de/blog/ >> Kamailio services – https://gilawa.com >> From: Jawaid Bazyar via sr-users <sr-users@lists.kamailio.org> >> Sent: Mittwoch, 25. Oktober 2023 21:54 >> To: sr-users@lists.kamailio.org >> Cc: Jawaid Bazyar <baz...@gmail.com> >> Subject: [SR-Users] Registrar / Path >> Hi, >> I have a scenario where I have an edge proxy (named RS), which locally >> stores registrations from Endpoints in its USRLOC, but which then also >> forward's REGISTER requests on to another proxy (named CN), which stores >> registrations in its USRLOC. (which then does DMQ with another CN like it). >> Both RS and CN are storing Path information, for example: >> kamctl ul show displays on both RS and CN: >> "Path": "sip:vs-rs01.blah.foo.bar;lr;received=sip:3.4.5.6:33577", >> So I know the path info is in there. >> I want CN , when presented with an INVITE, to reply with a 302 Redirect. >> Right now I have this: >> if (!lookup("location",sip:$tU@nodomain)) { >> } >> reg_fetch_contacts("location", "$tu", "called"); >> xlog("location info $ulc(called=>path)"); >> sl_send_reply("302","Redirect"); >> and the xlog does display the path. Good, so I have it being sent all the >> way through RS and CN and into CN’s USRLOC. >> but this isn’t complete. >> I am now faced with two issues. >> One, I need to mangle the Path into a Contact header for the Redirect. >> Two, I need to delete the Contact header that sl_send_reply is putting on >> there, which is the Contact as RS sees it from the endpoint. This needs to >> be removed and replaced with a Contact of only the RS server. >> It feels like there ought to be a simpler way to do this than parsing the >> Path string and reassembling a Contact from it, but if there is it's not >> readily apparent. Both Google and chatgpt have failed me :) >> Thanks in advance, >> Jawaid >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the >> sender! >> Edit mailing list options or unsubscribe: > > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
