Just for fun, can you try send_reply() instead of sl_send_reply()?

> On 31 Oct 2023, at 10:14, Jawaid Bazyar <baz...@gmail.com> wrote:
> 
> Hi,
> 
> So with use_path 1 (I already had this set) and path_mode 0, the Contact 
> header is not set on a sl_send_reply(302).
> 
> Neither, with use_path 1 and path_mode 1.
> 
> Path mode 2 does not seem appropriate.
> 
> What other path related parameters did you have in mind?
> 
> 
> 
> 
> On 10/27/23, 11:37 AM, "Alex Balashov via sr-users" 
> <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> wrote:
> 
> 
> 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
>  
> <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 
>> <mailto: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 <mailto: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 <mailto:h...@gilawa.com>>
>>> Date: Friday, October 27, 2023 at 10:10 AM
>>> To: "Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org 
>>> <mailto:sr-users@lists.kamailio.org>>
>>> Cc: Jawaid Bazyar <baz...@gmail.com <mailto: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/ 
>>> <https://skalatan.de/blog/>
>>> Kamailio services – https://gilawa.com <https://gilawa.com>
>>> From: Jawaid Bazyar via sr-users <sr-users@lists.kamailio.org 
>>> <mailto:sr-users@lists.kamailio.org>> 
>>> Sent: Mittwoch, 25. Oktober 2023 21:54
>>> To: sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>>> Cc: Jawaid Bazyar <baz...@gmail.com <mailto: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 
>>> <mailto: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 <https://evaristesys.com>
>> Tel: +1-706-510-6800
>> 
> 
> 
> -- 
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com <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 
> <mailto: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

__________________________________________________________
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:

Reply via email to