[asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination

[Joshua C. Colp]

On Sun, Jan 10, 2021 at 6:55 PM Michael Maier <m1278468 at mailbox.org> wrote:

<snip>


> The patch was vital!
>
> > Great! I'm testing it! I'll be back.
>
> Yeah! That's cool.
>
> myfw*CLI> pjsip show transports
>
> Transport:  <TransportId........>  <Type>  <cos>  <tos>
> <BindAddress....................>
>
> ==========================================================================================
>
> Transport:  0.0.0.0-tls               tls      3    184  0.0.0.0:5061
> Transport:  0.0.0.0-udp               udp      3    184  0.0.0.0:5060
> Transport:  tflow-001                 udp      3    184  0.0.0.0:0
> Transport:  tflow-002                 udp      3    184  0.0.0.0:0
> Transport:  tflow-003                 udp      3    184  0.0.0.0:0
>
> Besides the point that the type is not shown correctly - maybe use * or
> something else neutral, it's working as expected: no more useless listener
> ports and each trunk / number for
> ISP gets its own port and therefore connection. That was the goal.
>

Likely got missed when flow support was initially added.


>
> But: as long as there where those other normal tls transports, the port in
> the VIA and CONTACT has been always 5062 - even if the flow transports have
> been used. That's odd. Now it's
> 5061 (after those additional tls transports have been deleted) - not sure,
> where the 5061 is actually coming from :-). But most probably not from the
> correct source :-) - I think
> it's derived from 0.0.0.0-tls.
>

It would be derived from the underlying transport that is used to establish
the connection.

-- 
Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210110/7f9f494d/attachment.html>