[SR-Users] Record-Route and received/rport parameters

[Asgaroth]

Hmm, maybe I've not explained this scenario properly.

The proxy that is sitting on the customer premises is calling via our 
proxy. I dont have access to the customer's proxy at all.

When their invite (via their proxy) hits our proxy the issue I explained 
originally is encountered. I believe they are only running a pure sip 
proxy, be it kamailio/opensips etc, and their ua's point to it for 
registration etc. When making a call it appears to just relay the invite 
but inserts a record route for their proxy. This causes issues with our 
b2b when it generates the bye message.

I doubt stun/turn/rtpengine will help me in this scenario, unless I'm 
misunderstanding you.

Will kamailio not honour the recieved/rport parameters in the route-header?


On 03/05/18 15:44, Amar Tinawi wrote:
> Then you may be use stun/turn solution or rtpengine
>
> Regards
>
> On Thu, May 3, 2018, 5:30 PM Asgaroth <00asgaroth00 at gmail.com 
> <mailto:00asgaroth00 at gmail.com>> wrote:
>
>     This would not work if I dont have access to the proxy that is
>     advertising a private address in the record-route header, thanks
>     for the tip though.
>
>
>
>     On 03/05/18 15:26, Amar Tinawi wrote:
>>     You may introduce advertise command  in the configuration files
>>     when defining the interfaces
>>
>>
>>     Like this way :
>>     listen=private ip  advertise public ip
>>
>>     On Thu, May 3, 2018, 4:52 PM Asgaroth <00asgaroth00 at gmail.com
>>     <mailto:00asgaroth00 at gmail.com>> wrote:
>>
>>         Hi All,
>>
>>         I've come accros a scenario where a proxy is sitting on a
>>         private
>>         address range and inserts a record-route specifying the the
>>         private address.
>>
>>         This causes issues whereby the BYE to an INVITE attempts to
>>         relay to the
>>         private address defined in record-route.
>>
>>         I was wondering, if we were inject a received and rport
>>         parameter into
>>         the record-route header of the original invite, whould
>>         kamailio relay
>>         the response (BYE) to the receive/rport destination instead
>>         of the uri
>>         defined in the record-route header.
>>
>>         As an example, initial invite comes in with a record-route as
>>         follows:
>>
>>         Record-Route: <sip:172.17.0.2:5062;lr;ftag=b4551d29>
>>
>>         If we injected received and rport as follows:
>>
>>         Record-Route:
>>         <sip:172.17.0.2:5062;lr;ftag=b4551d29;rport=33429;received=212.172.2.212>
>>
>>         and relayed the message to the B2B.
>>
>>         Then, I assume, when the B2B creates its BYE message, the
>>         Route header
>>         should look like this:
>>
>>         Route:
>>         <sip:172.17.0.2:5062;lr;ftag=b4551d29;rport=33429;received=212.172.2.212>
>>
>>         Once this hits the kamailio instance to relay to the last
>>         route header
>>         as mentioned above, would it set $du to received:rport like
>>         it does with
>>         Via headers?
>>
>>         Thanks
>>
>>         _______________________________________________
>>         Kamailio (SER) - Users Mailing List
>>         sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>         https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>     _______________________________________________
>     Kamailio (SER) - Users Mailing List
>     sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> 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/20180503/0cdc748e/attachment.html>