[SR-Users] handle_ruri_alias() and multiple aliases

[Ovidiu Sas]

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 at 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 at 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 at 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 at 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 at 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
>>
>
>
> --
>
> BR,
> Denys Pozniak
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210531/7c5cdf64/attachment.htm>