* Make ast_format_cap_get_names() NULL tolerant.

ASTERISK-26331 #close
Reported by: CGI.NET

Change-Id: Id67e93936dc8ec2a33a9d33655843d43b59285a3

Create ao2_alloc_with_lockobj function to support shared locking.

Change-Id: Iba687eb9843922be7e481e23a32c0700ecf88a80

Previously, the buffer used for MP3 streamed from HTTP servers had a size of
1 MB. For 8 kHz mono audio at 16 bit resolution, such a buffer covers about 1
minute. Only when the buffer is full does audio start to play.
For MP3 files streamed from a server, that is usually not a big deal as long as
the connection to the server is fast enough to supply that much data within a
second or two. For MP3 live streams however, it takes 1 minute to download 1
minute of audio, so without this change, app_mp3 wasn't really usable for MP3
live streams.
This commit changes the buffer size so that it covers 6 seconds of an MP3 file
streamed from a server and 0.5 seconds of an MP3 live stream. The latter is
identified by the use of a .m3u file extension.

app_mp3 so far only supported 8 kHz audio.
Now it always runs at the sample rate of the channel.

ASTERISK-26085 #close

Change-Id: Id1ee274733cd804a0edecf7450329b72f1235af0

If the PJSIP endpoint's AOR with the permanent contact
was deleted from the realtime storage the res_pjsip module
continues trying to qualify this contact.
The error 'Unable to find an endpoint to qualify contact'
appeares every 'qualify_frequency' seconds.
This patch deletes this contact in this case.

The PJSIP endpoint's AOR with the permanent contact
is never qualified if it is added to realtime storage
after asterisk started.
This patch adds qualifying for the AOR's permanent contacts
on the first handling of this AOR.

ASTERISK-26319 #close

Change-Id: Ib93dded9121edb113076903d1aa95402f799f8fe

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

When using the migration script sip_to_pjsip.py, and your sip.conf is
configured with bindaddr=::, two transports are written to pjsip.conf, one for
0.0.0.0 (IPv4) and one for [::] (IPv6). That way, PJProject listens on the IPv4
and IPv6 wildcards; a IPv4/IPv6 Dual Stack configuration on a single interface
like in chan_sip.

Furthermore, the script internal functions "build_host" and "split_hostport"
did not parse Literal IPv6 addresses as expected (like [::1]:5060). This change
makes sure, even such addresses are parsed correctly.

ASTERISK-26309

Change-Id: Ia4799a0f80fc30c0550fc373efc207c3330aeb48

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