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

[Michael Maier]

On 10.01.21 at 22:18 Michael Maier wrote:
>>> Aha, I remembered at the PJSIP level a feature[1] got added when the
>>> Google Voice patch was done. It hasn't been exposed to be explicitly
>>> configurable in Asterisk though.
>>>
>>> [1]
>>> https://www.pjsip.org/pjsip/docs/html/structpjsip__tpselector.htm#a1622f416d48eb173aed22b750aa28dfa
>>>
>>
>> In fact the flow functionality[1] may get you closer to how you need
>> things. There was a bug though with it, so either 18 branch needs to be
>> used or this change[2] included.
>>
>> [1]
>> https://github.com/asterisk/asterisk/blob/master/configs/samples/pjsip.conf.sample#L161
>> [2] https://gerrit.asterisk.org/c/asterisk/+/15256

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.

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.


Thanks
Michael