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

[LSV]

What you do?

сб, 16 янв. 2021 г. в 2:55, LSV <basteon at gmail.com>:

> What you do?
>
> вт, 12 янв. 2021 г. в 0:28, Joshua C. Colp <jcolp at digium.com>:
>
>> On Mon, Jan 11, 2021 at 10:21 AM Michael Maier <m1278468 at mailbox.org>
>> wrote:
>>
>>> Hello!
>>>
>>> I'm analyzing the transports opened by or for a Registration to an ISPs
>>> trunk. Here: transport type flow.
>>>
>>> I can reproducibly see, that on Asterisk start up are always two
>>> connections created to register a trunk. The first one looks like this:
>>>
>>
>> <snip>
>>
>>
>>>
>>> It differs in the log output already at the beginning:
>>> [2021-01-11 13:21:24] DEBUG[8570] pjproject:        tlsc0x7fa1d82efae8
>>> TLS client transport created
>>> vs
>>> [2021-01-11 13:21:24] DEBUG[8570] pjproject:        tlsc0x7fa1d8324ec8
>>> .TLS client transport created
>>>                                                                        ^
>>> What does this dot mean? Where is it coming from?
>>>
>>
>> This is a message from the PJSIP library itself forwarded up, not sure
>> why there's a period there.
>>
>>
>>>
>>> It is possible to tcpkill the first connection without being restarted:
>>>
>>> # tcpkill -i eth0 tcp port 54761
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:        tlsc0x7fa1d82efae8
>>> TLS connection closed
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:           sip_transport.c
>>> Transport tlsc0x7fa1d82efae8 shutting down, force=0
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN
>>> [2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c:
>>> Reliable transport 'tlsc0x7fa1d82efae8' state:DESTROY
>>> [2021-01-11 14:42:15] DEBUG[8569] pjproject:        tlsc0x7fa1d82efae8
>>> TLS transport destroyed with reason 120104: Connection reset by peer
>>>
>>> If you're doing the same against Telekom, they drop the first connect
>>> after 10 s (therefore no tcpkill is necessary)
>>>
>>> Any idea why there are 2 connections started though only one is
>>> necessary? This is really odd.
>>>
>>
>> Nope. The code itself wasn't explicitly designed or written for this
>> usage, so there may be issues with it.
>>
>> <snip>
>>
>>
>>> It seems, that the first register is done through the first connection -
>>> all following registers are done by the second connection (can be seen in
>>> the tcpdump trace).
>>> Things would be much more analyzable btw, if asterisk pcap trace would
>>> contain the local port of the connection, too - or if it would tell, which
>>> connection it is using.
>>>
>>
>> Knowing what the source IP address and port that is in use at the point
>> of logging is difficult. Noone is actively working on changing that, but
>> nothing to say it couldn't change in the future.
>>
>> --
>> Joshua C. Colp
>> Asterisk Technical Lead
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210127/65a00ab8/attachment.html>