What you do? вт, 12 янв. 2021 г. в 0:28, Joshua C. Colp <[email protected]>:
> On Mon, Jan 11, 2021 at 10:21 AM Michael Maier <[email protected]> > 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
