<div dir="auto">What you do?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 16 янв. 2021 г. в 2:55, LSV <<a href="mailto:basteon@gmail.com">basteon@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">What you do?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 12 янв. 2021 г. в 0:28, Joshua C. Colp <<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>>:<br></div></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jan 11, 2021 at 10:21 AM Michael Maier <<a href="mailto:m1278468@mailbox.org" target="_blank">m1278468@mailbox.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
I'm analyzing the transports opened by or for a Registration to an ISPs trunk. Here: transport type flow.<br>
<br>
I can reproducibly see, that on Asterisk start up are always two connections created to register a trunk. The first one looks like this:<br></blockquote><div><br></div><div><snip></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It differs in the log output already at the beginning:<br>
[2021-01-11 13:21:24] DEBUG[8570] pjproject:        tlsc0x7fa1d82efae8 TLS client transport created<br>
vs<br>
[2021-01-11 13:21:24] DEBUG[8570] pjproject:        tlsc0x7fa1d8324ec8 .TLS client transport created<br>
                                                                       ^<br>
What does this dot mean? Where is it coming from?<br></blockquote><div><br></div><div>This is a message from the PJSIP library itself forwarded up, not sure why there's a period there.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It is possible to tcpkill the first connection without being restarted:<br>
<br>
# tcpkill -i eth0 tcp port 54761<br>
[2021-01-11 14:42:15] DEBUG[8569] pjproject:        tlsc0x7fa1d82efae8 TLS connection closed<br>
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable transport 'tlsc0x7fa1d82efae8' state:DISCONNECTED<br>
[2021-01-11 14:42:15] DEBUG[8569] pjproject:           sip_transport.c Transport tlsc0x7fa1d82efae8 shutting down, force=0<br>
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable transport 'tlsc0x7fa1d82efae8' state:SHUTDOWN<br>
[2021-01-11 14:42:15] DEBUG[8569] res_pjsip/pjsip_transport_events.c: Reliable transport 'tlsc0x7fa1d82efae8' state:DESTROY<br>
[2021-01-11 14:42:15] DEBUG[8569] pjproject:        tlsc0x7fa1d82efae8 TLS transport destroyed with reason 120104: Connection reset by peer<br>
<br>
If you're doing the same against Telekom, they drop the first connect after 10 s (therefore no tcpkill is necessary)<br>
<br>
Any idea why there are 2 connections started though only one is necessary? This is really odd.<br></blockquote><div><br></div><div>Nope. The code itself wasn't explicitly designed or written for this usage, so there may be issues with it.</div><div> </div><div><snip></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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).<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div></div></div><div dir="ltr">-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><div><font color="#073763">Joshua C. Colp</font></div><div><font color="#073763">Asterisk Technical Lead</font></div><div><font color="#073763">Sangoma Technologies</font></div><div><font color="#073763">Check us out at <a href="http://www.sangoma.com/" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org/" target="_blank">www.asterisk.org</a></font></div></div></div></div></div></div></div></div></div></div></div></div>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a></blockquote></div></div>
</blockquote></div></div>