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
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.comhttps://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 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
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@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 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
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 hw@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 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/ 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 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@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
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.u...
On 27 Oct 2023, at 10:59, Alex Balashov 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
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 hw@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 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/ 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 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@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
Yes, you stated it very well!
Hm, ok I will test out those path parameters. Thanks!
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.u... 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@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
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 <hw@gilawa.com mailto:hw@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 <bazyar@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@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 <bazyar@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@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
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.u... 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@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
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 <hw@gilawa.com mailto:hw@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 <bazyar@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@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 <bazyar@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@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
Just for fun, can you try send_reply() instead of sl_send_reply()?
On 31 Oct 2023, at 10:14, Jawaid Bazyar bazyar@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.u... 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@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
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 <hw@gilawa.com mailto:hw@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 <bazyar@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@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 <bazyar@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@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
-- 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@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: