Hi! Please notice that such a TCP keepalive paket is often filtered by carrier-grade nat. So this would end in no keepalive packet for the client.
Kind regards, André Am 26.01.2018 um 10:58 schrieb marek cervenka: > +1 > > > Dne 24/01/2018 v 21:50 George Joseph napsal(a): >> So here's a proposal... >> >> We remove BOTH pjproject and asterisk keep-alives. >> We add the following parameters to pjsip transport: >> >> tcp_keepalives = <boolean> ; turn on or off tcp keepalives >> ; If tcp_keepalives = yes, the following parameters can be used to override >> the default kernel >> ; settings in /proc/sys/net/ipv4/tcp_keepalive_(time,intvl,probes) >> tcp_keepalive_time = <seconds> ; The number of seconds a connection can be >> idle before the first keepalive is sent. >> tcp_keepalive_interval = <seconds> ; Interval between keepalive probes. >> tcp_keepalive_probes = <number> ; Number of unacknowledged probes before a >> failure is reported. >> >> To preserve backward compatibility, the current keep_alive_interval setting >> in pjsip.conf/global >> would turn tcp keepalives on for tcp and tls transports with both >> tcp_keepalive_time and >> tcp_keepalive_interval set to keep_alive_interval and tcp_keepalive_probes >> set to 2. >> >> One advantage of this is that wireshark captures will clearly show these as >> tcp keepalives even on >> a tls connection. Another advantage is that we eliminate the competing >> keepalive mechanisms >> with their threading and locking baggage. >> >> No code changes to pjproject would be required for this change. We can turn >> off their keepalives >> in our config_site.h file. >> >> >> >> >> On Fri, Jan 5, 2018 at 9:07 AM, Ross Beer <[email protected] >> <mailto:[email protected]>> wrote: >> >> Could the operating system manage this also, for example with the >> following: >> >> sysctl.conf >> >> net.ipv4.tcp_fin_timeout = 60 >> net.ipv4.tcp_retries1 = 3 >> net.ipv4.tcp_syn_retries = 5 >> >> # Keep TCP connections alive >> net.ipv4.tcp_keepalive_time = 300 >> net.ipv4.tcp_keepalive_intvl = 60 >> net.ipv4.tcp_keepalive_probes = 20 >> >> From a chan_pjsip point of view, it would receive notification that the >> underlying connection has closed. >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> *From:* [email protected] >> <mailto:[email protected]> >> <[email protected] >> <mailto:[email protected]>> on behalf of Alexander Traud >> <[email protected] <mailto:[email protected]>> >> *Sent:* 05 January 2018 15:44 >> *To:* Asterisk Developers Mailing List >> *Subject:* Re: [asterisk-dev] Idle Timers and Keep-Alives >> >> > Do we even WANT an idle timer? >> >> I posted my concerns already in <http://gerrit.asterisk.org/6807 >> <http://gerrit.asterisk.org/6807>>: I have a device which crashes when it >> receives such a keepalive. I could live with a timer when Asterisk is not >> the registrar but registered somewhere else. But I do not _need_ that either. >> >> >> >> -- >> _____________________________________________________________________ >> -- 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 >> <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 >> <http://lists.digium.com/mailman/listinfo/asterisk-dev> >> >> >> >> >> -- >> George Joseph >> Digium, Inc. | Software Developer >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US >> Check us out at: www.digium.com <http://www.digium.com/> & www.asterisk.org >> <http://www.asterisk.org/> >> >> >> > > > -- Mit freundlichen Grüßen André Valentin Systemadministration - Projektkoordination -- MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18 URL: http://www.marcant.net <http://www.marcant.net/> | http://www.global-m2m.com <http://www.global-m2m.com/> Internet * Netzwerk * Mobile Daten Citrix Silver Solution Advisor Vorstand: Thorsten Hojas (Vorsitzender) Marc-Henrik Delker Dr. Anja-Christina Padberg Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238 ___________________________________________________________ Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung. Sie können natürlich auch gerne jederzeit unter [email protected] ein Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
smime.p7s
Description: S/MIME Cryptographic Signature
-- _____________________________________________________________________ -- 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
