Re: [asterisk-dev] Compiler feature requirements

[Corey Farrell]

This will definitely break any compilers older than gcc-4.1.2, but no 
major distribution (that I know of) has a supported release with this.  
CentOS 6 is the only major distro that will even use the __sync [1] 
methods. All other major distro's have gcc >= 4.7.0 which implements 
__atomic built-ins.


I tested OSX El Capitain, the configure script detected __atomic 
built-ins so this will not create any new issues for Mac.


[1] https://gist.github.com/coreyfarrell/c096dd335afee5502a6faee2a507b012

On 01/26/2018 03:20 PM, Matt Fredrickson wrote:

On Wed, Jan 24, 2018 at 3:50 PM, Corey Farrell  wrote:

I've posted ASTERISK-27619 [1] proposing that we drop support for GCC
versions older than 4.1.2.  Specifically we'd be requiring that either
__sync or __atomic builtin functions be available (I'm unsure what this will
do to clang requirements).  gcc-4.1.2 was released in February 2007 and was
the version provided by CentOS 5.  I've posted a PR to the jansson project
[2] which will make reference counting thread safe, but I'm getting
push-back on the parts needed to provide a replacement function for old
compilers.  Since reference counting in jansson was never thread safe before
I think they'd rather just leave it as is for old compilers.

Obviously this proposal is for Asterisk 16+ only.  Does this matter to any
distributions that will be supported beyond this October?

[1] https://issues.asterisk.org/jira/browse/ASTERISK-27619
[2] https://github.com/akheron/jansson/pull/389

As long as we don't impact any major, currently supported
distributions that may use earlier versions than gcc-4.1.2, I'm ok
with moving things forward as suggested.  Especially since this is
isolated to master/proposed-16.

Anybody else have any thoughts?




--
_
-- 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

Re: [asterisk-dev] Idle Timers and Keep-Alives

[André Valentin]

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 =  ; 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 =  ; The number of seconds a connection can be 
>> idle before the first keepalive is sent.
>> tcp_keepalive_interval =  ; Interval between keepalive probes.
>> tcp_keepalive_probes =  ; 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 > > 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:* asterisk-dev-boun...@lists.digium.com 
>>  
>> > > on behalf of Alexander Traud 
>> >
>> *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 > >: 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 
>> 
>>
>> --
>> _
>> -- 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 
>> 
>>
>>
>>
>>
>> -- 
>> George Joseph
>> Digium, Inc. | Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: www.digium.com  &