[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