Based on bridge video AMI event changes, bump the minor version of AMI.

Change-Id: Idf84507354170400813cda780906c94c9f1b60b4

OpenBSD's 'find' doesn't take the -delete argument so you have to pipe
through 'xargs rm -rf'.

'echo -e' doesn't like \t starting a line. It just prints 't' which
causes the libasteriskpj.exports file to be garbage.  They were just
cosmetic so they were removed.

librt doesn't exist so the link of libasteriskpj.so fails. It's not
actually needed for linux anyway so -lrt was removed from the link.

res_rtp_asterisk was failing to load because of an undefined
DTLS_method. '|| defined(LIBRESSL_VERSION_NUMBER)' was added to the #if
so DTLSv1_method is used instead.

ASTERISK-26608

Change-Id: I926ec95b0b69633231e3ad1d6e803b977272c49c

res_format_attr_opus assumed that the string being passed into it was
empty. It tried to determine if the only thing it had written was

a=fmtp:<num>

And if it had, it would reset the string. Its calculation was off when
working with chan_sip, though. chan_sip passes the entire built SDP
rather than an empty string. This resulted in always putting an empty
fmtp line in the SDP.

ASTERISK-26520 #close
Reported by scgm11

Change-Id: Ib2e8712d26a47067e5f36d5973577added01dbb5

When Opus is negotiated but not loaded, the log is spammed with messages
because the system does not know how to calculate the number of samples in
a frame.

* Suppress the warning by supplying a function that assumes 20ms of
samples in the frame.  For pass through support it doesn't really seem to
matter what number of samples is returned anyway.

ASTERISK-26605 #close

Change-Id: Icf2273692f040dc2c45b01e72a790d11092f9e0f

Responding to authentication challenges leaks PJSIP memory pools.

The leak was introduced with a pjproject 2.5.5 API change.
https://trac.pjsip.org/repos/ticket/1929 changed the API usage of
pjsip_auth_clt_init() to require the new API pjsip_auth_clt_deinit() to
clean up cached authentication allocations that get allocated with
pjsip_auth_clt_reinit_req().

ASTERISK-26516 #close

Change-Id: I4473141b8c3961d0dc91c382beb3876b3efb45c8

One of the code paths in __ast_file_read_dirs will only get executed if
the OS doesn't support dirent->d_type OR if the filesystem the
particular file is on doesn't support it.  So, while standard Linux
systems support the field, some filesystems like XFS do not.  In this
case, we need to call stat() to determine whether the directory entry
is a file or directory so we append the filename to the supplied
directory path and call stat.  We forgot to truncate path back to just
the directory afterwards though so we were passing a complete file name
to the callback in the dir_name parameter instead of just the directory
name.

The logic has been re-written to only create a full_path if we need to
call stat() or if we need to descend into another directory.

Change-Id: I54e4228bd8355fad65200c6df3ec4c9c8a98dfba

fopencookie/funclose is a non-standard API and should not be used
in portable software. Additionally, the way FILE's fd is used in
non-blocking mode is undefined behaviour and cannot be relied on.

This introduces internal abstraction for io streams, that allows
implementing the desired virtualization of read/write operations
with necessary timeout handling.

ASTERISK-24515 #close
ASTERISK-24517 #close

Change-Id: Id916aef418b665ced6a7489aef74908b6e376e85

During the development of Asterisk 14 the behavior of
the Command AMI action was altered such that the result
was returned on lines with a prefix of "Output: ". While
this was documented in the UPGRADE.txt file it is also
reasonable that this should bump the AMI version number.

ASTERISK-26556

Change-Id: Idf1bf01608e53f7bfdf43ddb4d0683e53f74ee42

The PJ_ICE_MAX_CHECKS constant is used by pjproject to determine how
many pairs of local/remote candidates will be made. If for some reason
we reach this upper bound, ICE will generally fail and no media will
flow between the browser and Asterisk.

This patch makes PJ_ICE_MAX_CHECKS set to the total possible number of
pairs of candidates we'd theoretically allow, which is
PJ_ICE_MAX_CAND^2. Prior to this patch, we simply multiplied
PJ_ICE_MAX_CAND by two; on systems with multiple interfaces (I blame
Docker), this is far too low to allow WebRTC calls to succeed.

Setting this to be PJ_ICE_MAX_CAND^2 allowed WebRTC calls to succeed
even when the system Asterisk was running on had quite a few virtual
interfaces.

Change-Id: Icd4f17de0ac9d3a83dddfc8bf1cb7616bc107d55

In 9785e8d0, app_echo was updated to relay video source updates to the
channel for the purposes of displaying video in WebRTC tests.
Unfortunately, this can cause a Kafkaesque nightmare if two or more
Local channels are in a bridge together where their ends are in
app_echo. When this situation occurs, a video update sent into app_echo
will cause the video update to be relayed to the other Local channels,
causing another round of video updates, etc. In not much time at all,
the channel length queues will be overwhelmed, channel alert pipes will
fail, and all hell will break loose as Asterisk merrily continues to
throw more video update requests onto the channels.

This patch updates app_echo to *only* relay a single video update. Once
a video update has been made, all further video updates are dropped.
This meets the intended purpose of the original patch: if we get a video
update and we're in app_echo, go ahead and ask the sender to update
themselves. However, once we've got that video stream sync'd up, don't
keep spamming the world.

Change-Id: I9210780b08d4c17ddb38599d1c64453adfc34f74

In multi-party bridges, Asterisk currently supports two video modes:
 * Follow the talker, in which the speaker with the most energy is shown
   to all participants but the speaker, and the speaker sees the
   previous video source
 * Explicitly set video sources, in which all participants see a locked
   video source

Prior to this patch, ARI had no ability to manipulate the video source.
This isn't important for two-party bridges, in which Asterisk merely
relays the video between the participants. However, in a multi-party
bridge, it can be advantageous to allow an external application to
manipulate the video source.

This patch provides two new routes to accomplish this:
(1) setVideoSource: POST /bridges/{bridgeId}/videoSource/{channelId}
    Sets a video source to an explicit channel
(2) clearVideoSource: DELETE /bridges/{bridgeId}/videoSource
    Removes any explicit video source, and sets the video mode to talk
    detection

ASTERISK-26595 #close

Change-Id: I98e455d5bffc08ea5e8d6b84ccaf063c714e6621

ASTERISK-26343

Change-Id: I06dbf7366e26028251964143454a77d017bb61c8
(cherry picked from commit 0be46aaf6b8b9eb5b0160ec591cdc2c6e1802a6d)

This reverts commit e5365dad.

Change-Id: Icc40cf0c7687454760762912dd29e4ae79e8e9ee

This reverts commit edca6911.

Change-Id: I76030b87333a2c390cd05392b74b75678d78ddfa

This reverts commit 6bce938c.

Change-Id: Iadbf462bf2a52e8b2fa9ebc75b37b1f688ba51d9

This reverts commit fa749866.

Change-Id: Idcd1b88fa0766b1326dcc87d8905dbc314c71bd7

This works the same as for AMI manager variables. Set
"channelvars=foo,bar" in your ari.conf general section, and then the
channel variables "foo" and "bar" (along with their values), will
appear in every Stasis websocket channel event.

ASTERISK-26492 #close
patches:
  ari_vars.diff submitted by Mark Michelson

Change-Id: I5609ba239259577c0948645df776d7f3bc864229

Libedit 3.1 is not build with unicode on as a default and so the
prototype for the el_gets callback changed from expecting a char buffer
to accepting a wchar buffer.  If ast_el_read_char isn't changed,
the cli reads garbage from teh terminal.

Added a configure test for (*el_rfunc_t)(EditLine *, wchar_t *) and
updated ast_el_read_char to use the HAVE_ define to detemrine whether
to use char or wchar.

ASTERISK-26592 #close

Change-Id: I9099b46f68e06d0202ff80e53022a2b68b08871a

When optimistic SRTP was on it was possible for us to still
set up a call without an audio stream if an offer was received
with required SRTP.

This change makes it so this scenario will now fail with a 488
response.

ASTERISK-26575

Change-Id: I7d14187037681f48879bd20319ac79d0877318f3