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

[LSV]

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/20210116/1e68c103/attachment-0001.html>