The test uses 4 threads to grow, count, lookup and shrink 15K objects
in a container.  If there's only 1 execution engine available, the test
will complete in <50ms.  If each threads gets its own execution engine,
the test may timeout after 60 seconds because the count thread does a
locked ao2_callback on the whole container in a tight loop with only
a sched_yield to give up time.  The lock contention makes the test
execution times wildly variable and mostly timeout.  2 execution
engines are OK, 3 results in about 33% failure rate and >=4 causes
a 80% failure rate.

To fix, the sched_yield was changed to a usleep(500).

Also, the number of buckets specified for the container was an even
number so that was changed to the next prime number greater than
(MAX_HASH_ENTRIES / 100).  That's 151 currently.

Change-Id: I50cd2344161ea61bfe4b96d2a29a6ccf88385c77

* CFLAGS is now properly set when using older gcc.
* All third-party pjproject targets have been removed.  This fixes
  an issue with older libsrtp in some distros.
* Manually removing the source directory now causes a rebuild.
* EXTERNALS_CACHE_DIR is now properly checked.
* Whitespace fixes.

Change-Id: I98fec6847efc5602a9f41cb95096fd660a49fa60

Change-Id: I7c1f4eb051177ee22cbe97e063d4a3effe29be30

This change adds support for dual stack automatically. No
configuration is required and the IP address and version
in the SIP messages and SDP will be automatically changed
based on the transport over which the message is being
sent. RTP usage has also been changed to listen on both
IPv4 and IPv6 simultaneously to allow media to flow, and
to allow ICE support on both simultaneously. This also
allows failover between IPv6 and IPv4 to work as expected.

ASTERISK-26309 #close

Change-Id: I235a421d8f9a326606d861b449fa6fe3a030572d

This is similar to what is done for origination, but for the 14 and up
channel creation method. When attempting to create a channel, if a
channel ID is specified and a channel already exists with that ID, then
a 409 is returned.

Change-Id: I77f9253278c6947939c418073b6b31065489187c

ARI and AMI allow for an explicit channel ID to be specified
when originating channels. Unfortunately, there is nothing in
place to prevent someone from using the same ID for multiple
channels. Further complicating things, adding ID validation to channel
allocation makes it impossible for ARI to discern why channel allocation
failed, resulting in a vague error code being returned.

The fix for this is to institute a new method for channel errors to be
discerned. The method mirrors errno, in that when an error occurs, the
caller can consult the channel errno value to determine what the error
was. This initial iteration of the feature only introduces "unknown" and
"channel ID exists" errors. However, it's possible to add more errors as
needed.

ARI uses this feature to determine why channel allocation failed and can
return a 409 error during origination to show that a channel with the
given ID already exists.

ASTERISK-26421

Change-Id: Ibba7ae68842dab6df0c2e9c45559208bc89d3d06

ASTERISK-26444 #close

Change-Id: I91d645b7e6e5dba35f8c410df2be77a8c0e3acb8

Introduces ice_blacklist configuration in rtp.conf. Subnets listed in the
form ice_blacklist = <subnet spec>, e.g. ice_blacklist =
192.168.1.0/255.255.255.0, are excluded from ICE host, srflx and relay
discovery. This is useful for optimizing the ICE process where a system
has multiple host address ranges and/or physical interfaces and certain
of them are not expected to be used for RTP. Multiple ice_blacklist
configuration lines may be used. If left unconfigured, all discovered
host addresses are used, as per previous behavior.

Documention in rtp.conf.sample.

ASTERISK-26418 #close

Change-Id: Ibee88f80d7693874fda1cceaef94a03bd86012c9

CDRs form chains. When the root of the chain is destroyed, it then
unreferences the next CDR in the chain. That CDR is destroyed, and it
then unreferences the next CDR in the chain. This repeats until the end
of the chain is reached. While this typically does not cause any sort of
problems, it is possible in strange scenarios for the CDR chain to grow
way longer than expected. In such a scenario, the destruction pattern
can result in a stack overflow.

This patch fixes the problem by switching from a recursive pattern to an
iterative pattern for destruction. When the root CDR is destroyed, it is
responsible for iterating over the rest of the CDRs and unreferencing
each one. Other CDRs in the chain, since they are not the root, will
simply destroy themselves and be done. This causes the stack depth not
to increase.

ASTERISK-26421 #close
Reported by Andrew Nagy

Change-Id: I3ca90c2b8051f3b7ead2e0e43f60d2c18fb204b8

ASTERISK-26470

Change-Id: I9c386f7a1c7d969161b28f189eb6298bbc5b7541

configuire.ac was only checking for the existence of pkg-config
and not the gtk2 package itself.  Now it calls AST_PKG_CONFIG_CHECK
for gtk+-2.0.

ASTERISK-26356 #close

Change-Id: I93e9d0166341f0e7f84b52955bb6f81da42f2ef6

Since Asterisk 1.8, the command "core set debug" on the command-line interface
asks not for a file (.c) but a module name. This change shows modules (.so) on
the auto-completion via a tabulator or the question mark. Now, when you
partially type a module name, TAB or ?, you get the correct candidiates.

ASTERISK-26480

Change-Id: I1213f1dd409bd4ff8de08ad80cb0c73cafb1bae0

Adds setting to confbridge.conf (binaural_active) that determines if binaural
synthesis can be available in bridge_softmix.

ASTERISK-26292

Change-Id: I59dfcb8e55fe1df4ef32045882fea5bb58fc71db

Addresses crashes when an attempt is made to operate on an SSL socket
after the socket has been closed.

ASTERISK-26477 #close

Change-Id: I421305b357558b4f9e690210dc0f4831ef4b3002

When using Asterisk Realtime Architecture, empty fields are skipped and the
default values are used. If the "context" parameter in queue was set and then
cleared from the database, the old value remains in memory and it continues
to be used. This change initialize the "context" parameter with an empty value,
allowing clearing the parameter.

ASTERISK-26462 #close

Change-Id: I64be73d5044ce38dd02408bd0e53de965ef65905

This patch adds the Asterisk EID field to all outgoing ARI events.
Because this field should be added to all events as they are
transmitted, it is appended to the JSON message just prior to it being
handed off to the application message handler. This makes it somewhat
resilient to both new events being added to ARI, as well as other
potential event transport mechanisms.

ASTERISK-26470 #close

Change-Id: Ieff0ecc24464e83f3f44e9c3e7bd9a5d70b87a1d

ASTERISK-26439

Change-Id: I7f5ee2eeba8906e9ecb3293dbe3a747770bb5011

ast_set_default_eid was searching for ethX, emX, enoX, ensX and even
pciD#U interface names.  While this was a good attempt, it wasn't
inclusive enough to capture interfaces like enp6s0 or ens6d1, etc.

Rather than relying on interface names, we now simply find the first
interface returned by the OS that has a hardware address and that
address isn't all 0x00 or all 0xff.  The code IS different for BSD,
Solaris and Linux based on what method is available for enumerating
interfaces.

Tested on:
FreeBSD9
CentOS6
Ubuntu14
Fedora24

I was unable to test on Solaris at this time but the code for Solaris
is used elsewhere at Digium.

Change-Id: Iaa6db87ca78a9a375e47d70e043ae08c1448cb72

Previously, the settings videosupport=always and videosupport=yes behaved
identically and unconditionally caused a video offer to be sent in the SDP on
an outgoing call. This was a regression introduced with commit
5a1d90e1 in Asterisk 1.6.1.

This commit restores correct behavior: videosupport=always causes a video offer
to be sent unconditionally, while videosupport=yes will only offer video on an
outbound channel if the incoming channel it is bridged to also supports video.
That way, the device receiving the outgoing call can display the correct user
interface elements for audio or video and will not unnecessarily show a blank
video window on an audio-only call.

ASTERISK-17470 #close

Change-Id: I782f4409d436114dbc97061c3570c0cd24f7c3ae

Previously when testing I had a preexisting makeopts in ASTTOPDIR.  The
ordering of configure.ac causes --with-externals-cache to be processed
after third-party configure.  In cases where the Asterisk clone is
cleaned it would cause pjproject to be downloaded to /tmp.  This
moves processing of the externals cache and sounds cache to happen
before third-party configure.

This also addresses a possible issue with the third-party Makefile.  If
TMPDIR is set by the environment it would override the path given to
--with-externals-cache.

ASTERISK-26416

Change-Id: Ifab7f35bfcd5a31a31a3a4353cc26a68c8c6592d