31 Oct
2023
31 Oct
'23
3:14 p.m.
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(a)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.…
<https://kamailio.org/docs/modules/5.7.x/modules/registrar.html#registrar.p.use_path>
On 27 Oct 2023, at 10:59, Alex Balashov
<abalashov(a)evaristesys.com <mailto:abalashov@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
--
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-leave(a)lists.kamailio.org
<mailto:sr-users-leave@lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
On 27 Oct 2023, at 10:23, Jawaid Bazyar via
sr-users <sr-users(a)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 <hw(a)gilawa.com <mailto:hw@gilawa.com>>
Date: Friday, October 27, 2023 at 10:10 AM
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Cc: Jawaid Bazyar <bazyar(a)gmail.com <mailto:bazyar@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(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
Sent: Mittwoch, 25. Oktober 2023 21:54
To: sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
Cc: Jawaid Bazyar <bazyar(a)gmail.com <mailto:bazyar@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-leave(a)lists.kamailio.org
<mailto:sr-users-leave@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