In ARI, the channels API allows to hangup a channel with a hangup reason.
This commit adds a new reason "answered_elsewhere".
When using a SIP channel, this will eventually allow Asterisk to add a proper
"Reason" header to a CANCEL message.

ASTERISK-26321

Change-Id: Ia97675bd4acd6a7f58eb467953dfb94559f6583d

A recent change attempted to optimize startup by not updating contact
status. Instead, code responsible for qualifying contacts updates the
status as it becomes known. The code even accounts for contacts/AORs
that are not set to be qualified.

The problem, though, is when there are no contacts associated with an
endpoint. A common case is when an endpoint is set to register its
contacts but has not done so yet. In this case, prior to registration,
the endpoint's device state will appear to be "not in use" and hints
associated with that device will appear to be "idle". In actuality, the
device state and hint should both appear as "unavailable". The reason
for the failure is that the optimization change made all persistent
endpoint states set to "unknown".

The fix here is to change the hard-coded "unknown" to be "offline"
instead. The default state will be offline until the qualifying code
determines that the contact is actually online. This way, if there are
no contacts at all, then the state stays as offline, and device state
and hints appear correctly.

ASTERISK-26269 #close
Reported by nappsoft

Change-Id: Ie99b84169393983453076f5e9c0d35ff313a456a

Previously, if context A was including context B and context B was including
context A, i.e. if there was a circular dependency between contexts, then
calling manager_show_dialplan_helper could lead to an infinite recursion,
resulting in a crash.

This commit applies the same solution as the one implemented in the
show_dialplan_helper function. The manager_show_dialplan_helper and
show_dialplan_helper functions contain lots of code in common, but the former
was missing the "infinite recursion avoidance" code.

ASTERISK-26226 #close

Change-Id: I1aea85133c21787226f4f8442253a93000aa0897

When dialing channels it is possible that they may not ever
leave the not in use state (Local channels in particular) by
the time we cancel them. If this occurs but we know they were
dialed we explicitly remove them from the pending members
container so that subsequent call attempts occur.

ASTERISK-26299 #close

Change-Id: I6ad0d17c36480c92cebf840626228ce3f7e4bd65

The reason for the disable is that while Asterisk works fine with older
libsrtp versions, newer versions of pjproject won't compile with them.
Debian 6 for instance, has libsrtp 1.4.4 which is older than what
pjproject is expecting.

We don't use most of pjmedia but we DO use it for SDP negotiation.
Luckily disabling srtp in pjmedia doesn't interfere with it's ability
to negitiate a secure channel.  The proper crypto attributes are
negotiated in both directions.

ASTERISK-26279 #close

Change-Id: Id25a92cdf3df97a26c53cffae65b6b82de33c8e2

In your Diaplan, if you specify
 same => n,Set(CHANNEL(secure_bridge_media)=1)
 same => n,Set(CHANNEL(secure_bridge_signaling)=1)
only the SIP channel driver chan_sip supports this. All other channels drivers
like res_pjsip fail. In case of failure, the original sRTP source code released
the whole channel, even if not hung-up, yet. This change does not release the
channel but instead hangs-up the channel.

ASTERISK-26306

Change-Id: I0489f0cb660fab6673b0db8af027d116e70a66db

We may check a global config option hundreds of times a second or more.
Asking sorcery for the global configuration from the config files backend
involves several allocations and container traversals.  Using realtime
without a memory cache is a lot worse because you have to lookup in the
realtime database each time to reconstitute the sorcery object.  With a
memory cache for realtime, there is about the same amount of overhead as
for config files.  Either way, it is still fairly expensive to access the
sorcery object that much.

* Cache the global config options so we can access them faster.  You must
now always perform a res_pjsip reload to change the global options.

Change-Id: Ice16c7a4cbca4614da344aaea21a072b86263ef7

ast_channel_get_t38_state() calls ast_channel_queryoption() with
AST_OPTION_T38_STATE.  If the passed in channel is a local channel then a
deadlock can happen if a channel lock is held when called.

* Made ast_channel_get_t38_state() callers not hold a channel lock before
calling.

* Update ast_channel_get_t38_state() doxygen to note that no channel locks
can be held when calling the function.

ASTERISK-26203 #close
Reported by: Etienne Lessard

ASTERISK-24822 #close
Reported by: David Brillert

ASTERISK-22732 #close
Reported by: Richard Mudgett

Change-Id: I49fd76fa9af628b4198009b5c0b82c8b03681214

ASTERISK-25980 added the FAXMODE channel variable to res_fax.c.
Unfortunately, it also introduced a deadlock potential because
set_channel_variables() which sets FAXMODE can be called during a
masquerade.  The ast_channel_get_t38_state() which gets the value used to
set FAXMODE cannot be called with the channel locked.  As a result, local
channels can deadlock because of how they must acquire the locks necessary
to operate.

The intent of FAXMODE is for dialplan to know how a fax was transferred
after the fax completes.  However, the previous patch sets FAXMODE to the
channel's current T.38 state AFTER the fax has completed and where T.38
may have already disconnected.

* Set FAXMODE based upon T.38 negotiations exchanged either with the fax
applications or the fax framehooks.

ASTERISK-26203
Reported by: Etienne Lessard

ASTERISK-24822
Reported by: David Brillert

ASTERISK-22732
Reported by: Richard Mudgett

Change-Id: Id525747254b64c1efe8b1b5973d52ff9719c2ae1

fax_gateway_indicate_t38() calls ast_indicate_data() which cannot be
called with any channel locks already held.  A deadlock can happen if the
function is operating on a local channel.

* Made fax_gateway_indicate_t38() unlock the channel before calling
ast_indicate_data() since fax_gateway_indicate_t38() is always called with
the channel locked.

* Made fax_gateway_indicate_t38() return void since nothing cared about
its return value.

ASTERISK-26203
Reported by: Etienne Lessard

ASTERISK-24822
Reported by: David Brillert

ASTERISK-22732
Reported by: Richard Mudgett

Change-Id: I701ff2d26c5fc23e0d5a48a3fd98759a9fd09407

Change-Id: Ic10ae434536bbf7fb7055d6ab36cc50b8748a4e7

The framehook container could become corrupted if the channel lock is not
held before calling.

Change-Id: If0a1c7ba0484ed3a191106a7516526b905952584

The framehook container could become corrupted if the channel lock is not
held before calling.

Change-Id: I1a6b957a1f7b899eb29a186915f8cccab886a438

As described in issue ASTERISK-26282 the AEL parser creates macros with
extension '~~s~~'.  app_macro searches only for extension 's' so the
created extension cannot be found.  with this patch app_macro searches for
both extensions and performs the right extension.

ASTERISK-26282 #close

Change-Id: I939aa2a694148cc1054dd75ec0c47c47f47c90fb

Starting from draft 2 of RFC 5456 (October 23, 2006) plaintext auth
is not supported in IAX2 protocol. Please refer to section 8.6.13 of
RFC 5456.

But plaintext auth is still supported by Asterisk implementation of IAX2.
This support should be dropped.

Patch, based on asterisk-dev discussion, adds deprecation warning on
startup if 'auth' is set to 'plaintext', changes default values of
'auth' from 'md5, plaintext' to 'md5'.

Patch is safe in terms of backwards compatibility, will work even if
remote peers have auth=plaintext and we have defaults.

auth=plaintext setting will remain deprecated in Asterisk 14 and 15,
and IAX2 plaintext support will be removed in Asterisk 16.

ASTERISK-22820 #close

Change-Id: I5d2f3830cb57645604818f87518916e8a5c317bf

ast_multicast_rtp_create_options now checks for NULL or empty options

Change-Id: Ib845eae46a67a9787e89a87ebd1027344e5e0362

NOTE: This patch was submitted earlier and reverted because of a failing
test. The test has been patched so that it adjusts for the changes here,
so this is being resubmitted for review.

One feature that confbridge has is the ability to play sounds to all
participants in the conference. Prior to this commit, the algorithm for
this was as follows:

* Grab the playback lock
* Push the conference announcer channel into the bridge
* Play back the sound
* Pull the conference announcer channel from the bridge
* Release the playback lock

The issue here is that the act of adding the playback channel to the
bridge and removing it for each announcement is expensive. Amongst the
expenses:

* The announcer channel is imparted into the bridge, meaning a new
  thread is spun up for each playback.
* When the announcer is added or removed from the bridge, it results
  in the BRIDGEPEER channel variable being set on all channels in the
  bridge. This requires keeping the bridge locked and locking each
  individual channel in order to set it.
* There's also just the general overhead of adding the channel and
  removing it from the bridge. The bridge potentially has to reconfigure
  every single time

With this commit, the paradigm for playing back announcements has
shifted.

* The announcer channel is now added to the bridge when the conference
  is allocated, and it is hung up when the conference is destroyed.
* A taskprocessor is used to queue playbacks onto the announcer channel.
  This keeps the behavior from before where playbacks do not overlap.
* The announcer channel is no longer placed into the bridge as
  departable. Since we are not constantly removing the channel from
  the bridge, it is safe to add the channel using an independent thread
  and simply hang the channel up when it is time for the conference to
  be destroyed.

The use of the taskprocessor for playbacks opens up the interesting
possibility of having asynchronous announcements played. In this commit,
however, the behavior is still exactly the same as it previously was.

ASTERISK-26289
Reported by Mark Michelson

Change-Id: Ica9fa4907c2f3728cdd1cf0bc564ef4eb40754a0

This reverts commit 5aa87730.

Change-Id: I9ab45776e54a54ecf1bac9ae62d976dec30ef491

The compilation failed for devmode
--enable DONT_OPTIMIZE
--enable BETTER_BACKTRACES
--enable DO_CRASH
--enable TEST_FRAMEWORK

res_pjsip/pjsip_configuration.c: In function dtls_handler:
res_pjsip/pjsip_configuration.c:974:20: error:
back may be used uninitialized in this function [-Werror=maybe-uninitialized]
int size = strlen(front);
           ^
cc1: all warnings being treated as errors

Change-Id: I7f082ead0312792a577ec7c73015ba64dabca580