[SR-Users] Port 5060 omitted in Record-Route

[Lợi Đặng]

Hi all, want to add more info listing the sockets
MY_ADDR: 10.0.2.15
PUBLIC_NAT_ADDR: 192.168.1.50

kamcmd> corex.list_sockets
> {
>         PROTO: tls
>         NAME: 10.0.2.15
>         ADDRLIST: {
>                 ADDR: 10.0.2.15
>         }
>         PORT: 5060
>         MCAST: no
>         MHOMED: no
>         ADVERTISE: 10.0.2.15
> }
> {
>         PROTO: tls
>         NAME: 10.0.2.15
>         ADDRLIST: {
>                 ADDR: 10.0.2.15
>         }
>         PORT: 5061
>         MCAST: no
>         MHOMED: no
>         ADVERTISE: 192.168.1.50
> }


The inbound record route is `10.0.2.15;transport=tls` which is the problem
of mine.

rgds,
Loi Dang Thanh
Phone : +84. 774.735.448
Email : loi.dangthanh at gmail.com


On Fri, Mar 29, 2019 at 9:26 AM Lợi Đặng <loi.dangthanh at gmail.com> wrote:

> Hi Joel, thanks for verification, it was ok to me when using the default
> 5060 for udp/tcp with port omitted in the RR, the calls should be routed
> properly.
> But it don't work if i use the same port 5060 for tls (i know this is a
> bit weird, but i want to re-use the port due to customer firewall
> restriction), the port is still omitted and `ACK/BYE` routed wrongly to
> *MY_ADDR;transport=tls* (5061).
>
> I only want to make sure whether it is not able to explicitly add 5060
> port to the RR when using tls or i just make it wrong with my configuration.
>
> rgds,
> Loi Dang Thanh
> Phone : +84. 774.735.448
> Email : loi.dangthanh at gmail.com
>
>
> On Thu, Mar 28, 2019 at 10:19 PM Joel Serrano <joel at textplus.com> wrote:
>
>> By SIP definition if the port is the default (5060 for udp/tcp, 5061 for
>> tls) it's not mandatory, that's why if you choose any other port you
>> specifically see it in the RR.
>>
>>
>>
>>
>> On Thu, Mar 28, 2019 at 3:30 AM Lợi Đặng <loi.dangthanh at gmail.com> wrote:
>>
>>> Hi all, i was using kamailio 4.2.1 located in 2 networks
>>>
>>>> listen = tcp:MY_ADDR:5060 advertise MY_ADDR:5060
>>>> listen = tls:MY_ADDR:5061 advertise PUBLIC_NAT_ADDR:5061
>>>
>>>
>>> when the call made from the inside network to out side, running
>>> `record_route()` resulted in 2 Record-Route headers added
>>> (enable_double_rr=1)
>>>
>>> Record-Route: PUBLIC_NAT_ADDR:5061;transport=tls;lr
>>>> Record-Route: MY_ADDR;transport=tcp;lr
>>>
>>>
>>> That was totally fine omitting the port in the first Record-Route when
>>> using tcp (or udp) on the first realm, but when i start switching to tls,
>>> it caused trouble
>>>
>>> Record-Route: PUBLIC_NAT_ADDR:5061;transport=tls;lr
>>>> Record-Route: MY_ADDR;transport=tls;lr
>>>
>>>
>>> The client is then told to send ACK/BYE to `MY_ADDR;transport=tls`
>>> located at `MY_ADDR:5061` as per rfc3263, then the call would failed.
>>>
>>> I had another try with
>>> `record_route_preset("PUBLIC_NAT_ADDR:5061;transport=tls",
>>> "MY_ADDR:5060;transport=tls");`, it really did add what i want with
>>> explicit 5060 port on RR, `ACK/BYE` travel on the correct path, but
>>> `loose_route()` only consumes the local `Route` header (it should consume
>>> 2). So my assumption is to stick with `record_route()` function to make
>>> `loose_route()` work properly.
>>>
>>> I tried using another port on the local realm, e.g: 5062 and the port is
>>> explicitly added to the Record-Route header `MY_ADDR:5062;transport=tls;lr`
>>> So is `5060` couldn't be explicitly added to the inbound Record-Route,
>>> or i just missed something?
>>>
>>> Any help will be appreciated.
>>>
>>> P/S: I also tried 4.4.7 and it still omit my 5060 port in the RR.
>>>
>>> rgds,
>>> Loi Dang Thanh
>>> Phone : +84. 774.735.448
>>> Email : loi.dangthanh at gmail.com
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> 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/20190329/04449ade/attachment.html>