What you do? сб, 16 янв. 2021 г. в 2:55, LSV <bast...@gmail.com>:
> What you do? > > вт, 12 янв. 2021 г. в 0:28, Joshua C. Colp <jc...@digium.com>: > >> On Mon, Jan 11, 2021 at 10:21 AM Michael Maier <m1278...@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 > >
-- _____________________________________________________________________ -- 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
