[asterisk-dev] Asterisk / pjsip: Bug or feature? TCP/TLS connection is endless after unregistering the last trunk to the destination
Joshua C. Colp
jcolp at digium.com
Mon Jan 11 08:27:26 CST 2021
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20210111/0f8b8ae6/attachment.html>
More information about the asterisk-dev
mailing list