In Asterisk 11, if the 'Originate' AMI command failed to connect the provided
Channel while in extension mode, a 'failed' extension would be looked up and
run. This was, I believe, unintentionally removed in 51b6c496. This patch
restores that behavior.

This also adds an enum for the various 'synchronous' modes in an attempt to
make them meaningful.

ASTERISK-26115 #close
Reported by: Nasir Iqbal

Change-Id: I8afbd06725e99610e02adb529137d4800c05345d

With 500+ queues and a reload every minute, a random queue disappears
upon reload. The cause is mususe of the 'dead' flag. Namely, all queues
were marked dead up front, and then "resurrected" by dropping this flag
for those found in the configuration. But a queue marked dead can be
removed also when control leaves the app entry point on a PBX thread.

With this change, the queue is marked only not found, and at the end of
reload only the queues that are still not found are actually marked as
dead, so the dead flag is never reset, and set only on positively dead
queues.

ASTERISK-26755

Change-Id: I3a4537aec9eb8d8aeeaa0193407e3523feb004bf

Some (voicemail-related) tests API symlinks beep.gsm and other files
from ast_config_AST_VAR_DIR. It should use ast_config_AST_DATA_DIR.

ASTERISK-26740 #close

Change-Id: Id49c56fb9e16df64b1a2b829693ca7601252df89

QueueLog did not log ringnoanswer when the caller abandoned call
before first timeout. It was impossible to get agent membername
and ringing duration for this short calls. After some discusions
it seems that the best way is to add new event RINGCANCELED,
which is generated after caller hangup during ringing.

ASTERISK-26665

Change-Id: Ic70f7b0f32fc95c9378e5bcf63865519014805d3

Add an application that allows tracking outbound calls
using app_queue.

ASTERISK-19862

Change-Id: Ia0ab64aed934c25b2a25022adcc7c0624224346e

Adds a new formula for SL2 and documentation

ASTERISK-26559

Change-Id: I0970c620460507cd9d45b0d43600779c8915e770

In some cases member is added to pending_members, and the channel
is hung up before any extension state change. So the member would
stay in pending_members forever. So when we call do_hang, we
should also remove member from pending.

ASTERISK-26621 #close

Change-Id: Iae476b5c06481db18ebe0fa594b3e80fdc9a7d54

Issue/patch ASTERISK-26587 was inspired by issue ASTERISK-22992
that requested ability to add callerid into app_originate.
Comments in that issue suggested that it was better solved by
adding an option to gosub prior to originating the call.  The
attached patch implements this much like app_dial with two
options one to gosub on the originating channel and one to gosub
on the newly created channel and behaves just like app_dial.
I have tested this patch by adding callerid info to the new
channel and also SIPAddHeader (to e.g. add header to force auto
answer) and confirmed it works.  Have also tested both 'exten'
and 'app' versions of app_originate.

Opened by: dkerr
Patch by: dkerr

Change-Id: I36abc39b58567ffcab4a636ea196ef48be234c57

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

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

sets the variable ABANDONED to TRUE if the call was not answered.

ASTERISK-26558

Change-Id: I4729af9bff4eba436d8a776afd3374065d0036d3

Given the scenario where multiple channels are dialed using Dial()
but the caller is picked up using PickupChan() all outgoing channels
except the channel specified to PickupChan() would be marked
as ringing until the call had been hung up.

When using the PickupChan application the channel executing the
application is swapped into place of another channel. As part
of this process the channel is answered. The Dial application
has explicit logic which checks if the channel is answered,
cancels all other outgoing channels, and bridges. This logic is
different than the normal logic that is executed when an outgoing
channel is answered. This different logic failed to publish dial
events stating that the other outgoing channels had been canceled.
As a result references to the outgoing channels were held onto by
the dial masquerade process until the call had been ended and
the channels had gone away. This would result in the channels
appearing in the "core show channels" list despite not being present
anymore and would also result in incorrect device state.

This change makes it so that this logic also publishes
dial events stating that the other outgoing channels have been
canceled.

ASTERISK-26549

Change-Id: Iea7168e6e82f7d4609ec0366153804e4f55ea64f

ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.

Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename

This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled.  This variable was only used in lock.c so it
is now initialized in that file only.

ASTERISK-26480 #close

Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966

When executing the MailboxExists dialplan application and
MAILBOX_EXISTS dialplan function the passed in temporary voice
mailbox was not cleared, causing it to try to free garbage.

ASTERISK-26503 #close

Change-Id: Ie21ccfa1b80b9c59318e596f6b8e17da2b5a7cb3

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

ASTERISK-26292

Change-Id: I59dfcb8e55fe1df4ef32045882fea5bb58fc71db

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

Added needed UTF-8 checks before constructing json objects in various
files for strings obtained outside the system.  In this case string values
from a channel driver's peer and not from the user setting channel
variables.

* aoc.c: Fixed type mismatch in s_to_json() for time and granularity json
object construction.

ASTERISK-26466
Reported by: Richard Mudgett

Change-Id: Iac2d867fa598daba5c5dbc619b5464625a7f2096

Change-Id: I082b239022fac462666e52a14a44304748908dc0

The pause reason is not always cleared when it should be cleared.

* Made set_queue_member_pause() always clear pause reason if not pausing
with a reason string.

Change-Id: I993dad19626ec017478a230e980989438b778c53

The "Q" option will set the cause on the unanswered channels when
another channel answers.  It overrides the default of
ANSWERED_ELSEWHERE.

NOTE:  chan_sip does not support setting the cause on a CANCEL to
anything other than ANSWERED_ELSEWHERE.

ASTERISK-26446 #close

Change-Id: I71742e0919aaa16784c30a2b2e73fbeed7672e47

Previously, when reloading the members of a queue, the members added statically
(i.e. defined in queues.conf) would see their "ringinuse" value updated but not
the members added dynamically.

This change makes dynamic members ringuse value to be updated on reload.

Note that it's impossible to add a dynamic member with a specific ringinuse
value. For both static and dynamic members, the ringinuse value can always be
changed later on with command like "queue set ringinuse" or with the AMI action
"QueueMemberRingInUse". So it's possible this commit could break a user workflow
if he was changing the ringinuse value of dynamic members via such commands and
was also relying on the fact that a queue reload would not update the dynamic
members ringinuse value.

ASTERISK-26330

Change-Id: I3745cc9a06ba7e02c399636f1ee9e58c04081f3f

The output of CLI "queue show" and AMI Queues action is truncated and
"failed to extend from 240 to 327" messages are generated if the queue
member and interface names are lengthy.

* Increase the string buffer size from 240 to 512 in order to accommodate
for more information fields added to the output since v1.8.

ASTERISK-26360 #close
Reported by: Richard Mudgett

Change-Id: Id99c03cf5362453b80491a4b3b0434cb67aa966d

Confbridge announcements tend to block a channel while they are being
played. In some circumstances, this is warranted since you want that
particular channel not to hear the announcement (Example: "John Doe has
entered the conference"). For others it makes less sense.

This change first introduces methods for playing sounds asynchronously
into the conference. This is very similar to how synchronous sounds are
played, except the channel initiating the playback does not wait for the
sound to complete before moving on.

Asynchronous announcements are used for two circumstances:
* Sounds played for a user after they have left the bridge
* Sounds that play first to a single user and then the rest of the
  conference (if the channel and conference use the same language)

ASTERISK-26289 #close
Reported by Mark Michelson

Change-Id: Ie486bb3de1646d50894489030326a423e594ab0a

In any scenario in which the callee is not connected to the caller, the
current code in app_dial will crash due to raising a Dial End Stasis
Message after the callee channel has been hung up. This patch corrects
the error by simply moving the explicit hangup of the callee (peer)
channel until after the dial end message.

ASTERISK-25691 #close

Change-Id: I816a414014424d0d8c80e2a3cbef13ef8c63798d

If the callee selects option '5' using the Dial application's privacy
(P) option, the DIALSTATUS is erroneously set to ANSWER. This option
reflects the callee sending the caller to VoiceMail one time; the call
is definitely *not* ANSWERed in such a scenario. With this patch, the
DIALSTATUS is instead set to NOANSWER, which is the same DIALSTATUS that
is set when the 'send to VoiceMail every time' option is set.

ASTERISK-25691

Change-Id: Iaf0c9f0fa00545e7366443875e2bb7d9a89a1358

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

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

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

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

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: Ic5cd2c4b98a1eaa1715eb7a5b35d62f1a76d78a5

Some configuration directives were not initialized on reload, and hence
were not reset to default if they were removed from followme.conf.

ASTERISK-26288 #close

Change-Id: Ief829e16374ad1e0ecfd63e6ee4923b5a1d1c150

* Add some helpful <literal> and other embedded paragraph tags

* Document some of the lesser known channel variables set by Dial

* Add examples for some common Dial uses, along with some more
  challenging but useful options

Change-Id: Ib2fb9301e8e044d14fbb2815ec64161f19bbfbc1

Change-Id: I80f8a981f62f50e74609c69c49edcaca6c95efa4

When a call forward attempt is made from a Queue member, the current
code will hang up the forwarding channel in an off-nominal condition
prior to raising the Stasis events informing the rest of Asterisk that
the call was forwarded. This will result in a slew of dreaded FRACKs,
most likely leading to a crash.

This patch modifies the code such that we don't hang up the forwarding
channel even in an off-nominal condition until we've safely raised the
Stasis messages.

ASTERISK-25797 #close

Change-Id: Ife5abed351691fd79105321636eaa8ea8dcdba38

On heavy loaded system with IMAP or DB storage,
'app_voicemail' taskprocessor queue could reach 500 scheduled tasks.
It could happen when the IMAP or DB server dies or is unreachable.
It could happen on startup when there are many (thousands)
realtime endpoints configured with unsolicited mwi.
If the taskprocessor queue reaches the high water level
then the alert is triggered and pjsip stops processing new requests
until the queue reaches the low water level to clear the alert.

This patch adds 2 new 'general' configuration options
to tune taskprocessor alert levels:
'tps_queue_high' - Taskprocessor high water alert trigger level.
'tps_queue_low' - Taskprocessor low water clear alert level

ASTERISK-26229 #close

Change-Id: I766294fbffedf64053c0d9ac0bedd3109f043ee8

If AST_TEST_DEFINE is not conditional to TEST_FRAMEWORK it produces dead
code.  This places all existing unit tests into a conditional block if
they weren't already.

ASTERISK-26211 #close

Change-Id: I8ef83ee11cbc991b07b7a37ecb41433e8c734686

This changes context includes from a linked list to a vector, makes
'struct ast_include' opaque to pbx.c.

Although ast_walk_context_includes is maintained the procedure is no
longer efficient except for the first call (inc==NULL).  This
functionality is replaced by two new functions implemented by vector
macros.
* ast_context_includes_count (AST_VECTOR_SIZE)
* ast_context_includes_get (AST_VECTOR_GET)

As with ast_walk_context_includes callers of these functions are
expected to have locked contexts.  Only a few places in Asterisk walked
the includes, they have been converted to use the new functions.

const have been applied where possible to parameters for ast_include
functions.

Change-Id: Ib5c882e27cf96fb2aec67a39c18b4c71c9c83b60

It is possible for a not in use state change to occur multiple
times causing a queue member to be removed from the pending call
container prematurely.

The first not in use state change will remove the queue member
from the container. At this moment the member may be called and
placed in the pending container. After this another not in use
state change can be received which will remove it from the
container. Despite being called at this point the code will
incorrectly see that there are no pending calls to it.

This change only removes it from the pending container if the
state has actually changed.

ASTERISK-26133 #close
patches:
  app_queue.diff submitted by Richard Miller (license 5685)

Change-Id: Ie5a7f17a44f98e9159e9b85009ce3f8393aa78c0

Fix compile error introduced by the patch for
ASTERISK-26045

Change-Id: I5b02876266f2824f4cec2b54d6ff4db5de5778d3