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@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@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