[SR-Users] handle_ruri_alias() and multiple aliases
Alex Balashov
abalashov at evaristesys.com
Mon May 31 19:57:17 CEST 2021
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210531/5a0e28c0/attachment.htm>
More information about the sr-users
mailing list