31 May
2021
31 May
'21
8:51 p.m.
Hello!
I need help understanding how the *handle_ruri_alias()* function works.
*Call-flow:* Upstream operator -> Kamailio Proxy -> Edpoint.
The upstream operator in the initial SIP INVITE in the Contact field sends
us an alias parameter, in turn, our Kamailio Proxy adds its own too.
The Contact after the Proxy looks something like this:
*Contact:
<sip:10.0.0.115:5060;alias=10.0.0.115~5060~1;alias=3.3.3.3~5060~1>*
When the Endpoint sends us a SIP BYE, then the *handle_ruri_alias()*
absorbs not the last alias, but the first one, and this leads to the
incorrect formation of a $du.
The RURI after the Proxy looks something like this:
*Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0*
The first thing that comes to mind is a modification of the original
Contact field with storing it's within a dialogue ...
Is it possible to elegantly solve this problem?
--
BR,
Denys Pozniak
31 May
31 May
8:57 p.m.
I don’t think the handle_ruri_alias() concept was created to handle such complications.
Usually you would not have two layers of NAT...
—
Sent from mobile, with due apologies for brevity and errors.
On May 31, 2021, at 1:53 PM, Denys Pozniak
<denys.pozniak(a)gmail.com> wrote:
Hello!
I need help understanding how the handle_ruri_alias() function works.
Call-flow: Upstream operator -> Kamailio Proxy -> Edpoint.
The upstream operator in the initial SIP INVITE in the Contact field sends us an alias
parameter, in turn, our Kamailio Proxy adds its own too.
The Contact after the Proxy looks something like this:
Contact: <sip:10.0.0.115:5060;alias=10.0.0.115~5060~1;alias=3.3.3.3~5060~1>
When the Endpoint sends us a SIP BYE, then the handle_ruri_alias() absorbs not the last
alias, but the first one, and this leads to the incorrect formation of a $du.
The RURI after the Proxy looks something like this:
Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0
The first thing that comes to mind is a modification of the original Contact field with
storing it's within a dialogue ...
Is it possible to elegantly solve this problem?
--
BR,
Denys Pozniak
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
9:09 p.m.
If there are two proxies involved, only one should handle aliases (the
one that is communicating directly with the endpoint).
If a Contact has a private IP, but the request is coming from a proxy
that is in charge of NAT, then the Contact should not be altered. When
you route back in dialog requests, it is ok to have a private IP in
RURI and proper Route headers, The next SIP hop (the other proxy) will
take care of properly routing the request.
Regards,
Ovidiu Sas
On Mon, May 31, 2021 at 1:53 PM Denys Pozniak <denys.pozniak(a)gmail.com> wrote:
Hello!
I need help understanding how the handle_ruri_alias() function works.
Call-flow: Upstream operator -> Kamailio Proxy -> Edpoint.
The upstream operator in the initial SIP INVITE in the Contact field sends us an alias
parameter, in turn, our Kamailio Proxy adds its own too.
The Contact after the Proxy looks something like this:
Contact: <sip:10.0.0.115:5060;alias=10.0.0.115~5060~1;alias=3.3.3.3~5060~1>
When the Endpoint sends us a SIP BYE, then the handle_ruri_alias() absorbs not the last
alias, but the first one, and this leads to the incorrect formation of a $du.
The RURI after the Proxy looks something like this:
Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0
The first thing that comes to mind is a modification of the original Contact field with
storing it's within a dialogue ...
Is it possible to elegantly solve this problem?
--
BR,
Denys Pozniak
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
--
VoIP Embedded, Inc.
http://www.voipembedded.com
10:04 p.m.
Thanks, Alex and Ovidiu,
Yes, I agree that *set_contact_alias ()* should only be used once.
The essence of the problem is that all external connections are processed
as for NAT by default in my script.
Is there any reason for improving the *handle_ruri_alias ()* function so
that we can specify the ordinal number of the alias parameter?
пн, 31 мая 2021 г. в 21:10, Ovidiu Sas <osas(a)voipembedded.com>om>:
If there are two proxies involved, only one should
handle aliases (the
one that is communicating directly with the endpoint).
If a Contact has a private IP, but the request is coming from a proxy
that is in charge of NAT, then the Contact should not be altered. When
you route back in dialog requests, it is ok to have a private IP in
RURI and proper Route headers, The next SIP hop (the other proxy) will
take care of properly routing the request.
Regards,
Ovidiu Sas
On Mon, May 31, 2021 at 1:53 PM Denys Pozniak <denys.pozniak(a)gmail.com>
wrote:
--
BR,
Denys Pozniak
Hello!
I need help understanding how the handle_ruri_alias() function works.
Call-flow: Upstream operator -> Kamailio Proxy -> Edpoint.
The upstream operator in the initial SIP INVITE in the Contact field
sends us an
alias parameter, in turn, our Kamailio Proxy adds its own too.
The Contact after the Proxy looks something like
this:
Contact: <sip:10.0.0.115:5060
;alias=10.0.0.115~5060~1;alias=3.3.3.3~5060~1>
When the Endpoint sends us a SIP BYE, then the handle_ruri_alias()
absorbs not the
last alias, but the first one, and this leads to the
incorrect formation of a $du.
The RURI after the Proxy looks something like
this:
Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0
The first thing that comes to mind is a modification of the original
Contact field
with storing it's within a dialogue ...
Is it possible to elegantly solve this problem?
--
BR,
Denys Pozniak
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
--
VoIP Embedded, Inc.
http://www.voipembedded.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
1 Jun
1 Jun
1:27 a.m.
You can adjust your script to use aliases only when needed. We want clean
and simple signalling.
-ovidiu
On Mon, May 31, 2021 at 15:05 Denys Pozniak <denys.pozniak(a)gmail.com> wrote:
Thanks, Alex and Ovidiu,
Yes, I agree that *set_contact_alias ()* should only be used once.
The essence of the problem is that all external connections are processed
as for NAT by default in my script.
Is there any reason for improving the *handle_ruri_alias ()* function so
that we can specify the ordinal number of the alias parameter?
пн, 31 мая 2021 г. в 21:10, Ovidiu Sas <osas(a)voipembedded.com>om>:
--
VoIP Embedded, Inc.
http://www.voipembedded.com
If there are two proxies involved, only one
should handle aliases (the
one that is communicating directly with the endpoint).
If a Contact has a private IP, but the request is coming from a proxy
that is in charge of NAT, then the Contact should not be altered. When
you route back in dialog requests, it is ok to have a private IP in
RURI and proper Route headers, The next SIP hop (the other proxy) will
take care of properly routing the request.
Regards,
Ovidiu Sas
On Mon, May 31, 2021 at 1:53 PM Denys Pozniak <denys.pozniak(a)gmail.com>
wrote:
--
BR,
Denys Pozniak
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
Hello!
I need help understanding how the handle_ruri_alias() function works.
Call-flow: Upstream operator -> Kamailio Proxy -> Edpoint.
The upstream operator in the initial SIP INVITE in the Contact field
sends us an
alias parameter, in turn, our Kamailio Proxy adds its own too.
The Contact after the Proxy looks something like
this:
Contact: <sip:10.0.0.115:5060
;alias=10.0.0.115~5060~1;alias=3.3.3.3~5060~1>
When the Endpoint sends us a SIP BYE, then the handle_ruri_alias()
absorbs not the
last alias, but the first one, and this leads to the
incorrect formation of a $du.
The RURI after the Proxy looks something like
this:
Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0
The first thing that comes to mind is a modification of the original
Contact field
with storing it's within a dialogue ...
Is it possible to elegantly solve this problem?
--
BR,
Denys Pozniak
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
--
VoIP Embedded, Inc.
http://www.voipembedded.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
1:32 a.m.
On 5/31/21 6:27 PM, Ovidiu Sas wrote:
You can adjust your script to use aliases only when
needed. We want
clean and simple signalling.
I strongly agree with Ovidiu. This is really the solution.
--
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/
10:38 a.m.
Hello,
I also agree that it should be fixed in signalling processing rules, the
proxy that is not next hop after NAT route should not add alias parameter.
However, I also faced similar multi-alias issues a few times in the
past, when the proxy I controlled was the one that had to add the alias
and had to do some tricks in the config to get it working until the
issue was mitigated between companies. Iirc, in my case the issue was
more complex as the other proxy didn't consume it properly always.
Anyhow, from that moment I had it in my to-do list to check what takes
to add a mode to consume either first or last alias parameter, and since
same issue surfaced again in another corner of the world, I just looked
and updating the code was not complex. Therefore I just added in master
branch an optional mode parameter to handle_ruri_alias() to be able to
specify which one (first or last) should be consumed.
Testing and feedback is very appreciated!
Cheers,
Daniel
On 01.06.21 00:32, Alex Balashov wrote:
On 5/31/21 6:27 PM, Ovidiu Sas wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online - June 7-10, 2021 (America Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
You can adjust your script to use aliases only
when needed. We want
clean and simple signalling.
I strongly agree with Ovidiu. This is really the solution.
--
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/
2 Jun
2 Jun
11:01 p.m.
Thank you!
I will report on the results of the testing.
вт, 1 июн. 2021 г. в 10:39, Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
I also agree that it should be fixed in signalling processing rules, the
proxy that is not next hop after NAT route should not add alias parameter.
However, I also faced similar multi-alias issues a few times in the
past, when the proxy I controlled was the one that had to add the alias
and had to do some tricks in the config to get it working until the
issue was mitigated between companies. Iirc, in my case the issue was
more complex as the other proxy didn't consume it properly always.
Anyhow, from that moment I had it in my to-do list to check what takes
to add a mode to consume either first or last alias parameter, and since
same issue surfaced again in another corner of the world, I just looked
and updating the code was not complex. Therefore I just added in master
branch an optional mode parameter to handle_ruri_alias() to be able to
specify which one (first or last) should be consumed.
Testing and feedback is very appreciated!
Cheers,
Daniel
On 01.06.21 00:32, Alex Balashov wrote:
--
BR,
Denys Pozniak
On 5/31/21 6:27 PM, Ovidiu Sas wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online - June 7-10, 2021 (America Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
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
You can adjust your script to use aliases only
when needed. We want
clean and simple signalling.
I strongly agree with Ovidiu. This is really the solution.
--
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/
1269
days inactive
1271
days old
7 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Denys Pozniak -
Ovidiu Sas