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

POSIX defines signal.h. sys/signal.h should not be used as it is
c-library internal header which may or may not exist. Notably with
musl it generates warning of being incorrect.

Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc

Icelandic has some weird grammar rules when dealing with dates and
numbers. There are different genders used depending on which number
you're dealing with, and only a handful of numbers do change depending
on the gender. There is also an implied gender in several cases.

This patch was originally written for asterisk 1.6, and has been in use
for several years without crashes. I cleaned it up a bit and rewrote
what was necessary for Asterisk 13.

The functions were copied from other similar languages and modified
where appropriate. If i recall correctly, the German and Danish
functions were used as a base.

ASTERISK-26087
Reported by: Örn Arnarson
Tested by: Örn Arnarson

Change-Id: Ib7d8bd7b0fede5767921ed821315b5b508c0e665

Added a new channel variable FORWARDERNAME which indicates which
channel was responsible for a forwarding requests received on dial attempt.

Fixed a bug in the app_queue: FORWARD_CONTEXT is not used.

ASTERISK-26059 #close

Change-Id: I34e93e8c1b5e17776a77b319703c48c8ca48e7b2

Dial events up to this point have come in two flavors
* A Dial event with no status to indicate that dialing has begun
* A Dial event with a status to indicate that dialing has ended

With this change, Dial events have been expanded to also give
intermediate events, such as "RINGING", "PROCEEDING", and "PROGRESS".
This is especially useful for ARI dialing, as it gives the application
writer the opportunity to place a channel into an early bridge when
early media is detected.

AMI handles these in-progress dial events by sending a new event called
"DialState" that simply indicates that dial state has changed but has
not ended. ARI never distinguished between DialBegin and DialEnd, so no
change was made to the event itself.

Another change here relates to dial forwards. A forward-related event
was previously only sent when a channel was successfully able to forward
a call to a new channel. With this set of changes, if forwarding is
blocked, we send a Dial event with a forwarding destination but no
forwarding channel, since we were prevented from creating one. This is
again useful for ARI since application writers can now handle call
forward attempts from within their own application.

ASTERISK-25925 #close
Reported by Mark Michelson

Change-Id: I42cbec7730d84640a434d143a0d172a740995543

Fixed some bugs:
- create dirpath when save downloading message from IMAP storage.
- create IMAP folder if not exists when saving to IMAP storage
- check if file successfully opened before write to it
- some IMAP checks
- remove non-standard flag 'Unseen'
etc

Change to debug IMAP mm_status log instead of verbose.

Remove unused X-Asterisk-VM-Caller-channel message header
for security reason. The clients should not know name of peer/endpoint.

ASTERISK-26045 #close

Change-Id: I7f83d88b69b36934e2539c114b9fb612deed971b

Add the option 'enable_callee_prompt' to followme.conf. Enabled by
default. If disabled, a callee is not prompted to accept or reject
the forwarded call.

ASTERISK-26064 #close

Change-Id: I0a8b19d4cf95c86a07c992813babb9e4a4acfff5
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

FollowMe with the option a records the name of the caller and plays it
to the callee. However it has failed to clean up that recorded file
as it tried to delete the file name without the '.sln' extension.

ASTERISK-26008 #close

Change-Id: I79d7b1be7d5cde57bf076d9389e2a8a4422776ec
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>

This patch allows for having app_confbridge register the name of the
conference as an extension into a specific context, similar to
regcontext for chan_sip.  This variant is not quite as involved as the
one in chan_sip and doesn't allow for multiple contexts or custom
extensions, you can only specify the context and the conference name
will always be used as the extension to register.

ASTERISK-25989 #close

Change-Id: Icacf94d9f2b5dfd31ef36f6cb702392619a7902f

When option 'o' was not set, ChanSpy created its audiohook with the flag
AST_AUDIOHOOK_MUTE_WRITE, which caused ChanSpy to listen audio from one
direction only.

ASTERISK-25866 #close

Change-Id: I5c745855eea29a3fbc4e4aed0b0c0f53580535e0

Voicemail email addresses can be corrupt or voicemail
emails can end up being sent to the wrong email address if asterisk is
reading voicemail.conf during a reload and processing an email at the
same time. This patch always copies the struct that would otherwise only
be copied once.

ASTERISK-24463 #close
Reported by: John Campbell
Tested by: Etienne Lessard
Tested by: Andrew Nagy
Change-Id: I3a0643813116da84e2617291903d0d489b7425fb

ChanSpy was creating its audiohook with the flags AST_AUDIOHOOK_TRIGGER_SYNC
and AST_AUDIOHOOK_SMALL_QUEUE, which caused audio frames to be lost when
queues grow too large or when read and write queues go out of sync.
Now these flags are set conditionally:
- AST_AUDIOHOOK_TRIGGER_SYNC is not set if the option "o" is set
- a new option "l" is created: if set, AST_AUDIOHOOK_SMALL_QUEUE will not
be set on the audiohook

ASTERISK-25866

Change-Id: I9c7652f41d9fa72c8691e4e70ec4fd16b047a4dd

When unloading the app_queue module the members in each queue are
destroyed and as part of this they are removed from the pending
members container. Unfortunately a crash would occur as the container
was destroyed before the members were removed.

This change tweaks ordering so the container destruction occurs
after the members are destroyed.

ASTERISK-16115

Change-Id: I48c728668c55aee3d05b751a5d450fb57e87f44b

ASTERISK-25954 #close
Reported by: Javier Acosta

Change-Id: I00be83d45cc7e8385de2523012bd196aafeeb256
(cherry picked from commit c0688a63)

It was possible for a queue member that is a member of at least 2 or more
queues to receive mulitiple calls at the same time. This happened because
of a race between when a member was being rung and when the device state
notified the other queue(s) member object of the state change.

This patch makes it so when a queue member is being rung it gets added to
a global pool of queue members. If that same member is tried again, e.g.
from another queue, and it is found to already exist in the pending member
container then it will not ring that member.

ASTERISK-16115 #close

Change-Id: I546dd474776d158c2b6be44205353dee5bac7e48

You cannot reference the passed in features struct after calling
ast_bridge_impart().  Even if the call fails.

Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21

This module is used as part of testsuite tests to confirm
stuff works. I'm accordingly marking it as core as it is
required by those tests.

Change-Id: I558e7af7679b22b8ed641d7dd37ee4ca35b11e88

ASTERISK-25888 #close

Change-Id: I007a2f2dd99823e04fb5be3ff01f02b0a2956117

The test_voicemail_notify_endl test checks the end-of-line
characters of an email message to confirm that they are consistent.
The test wrongfully assumed that reading from the email message
into a buffer will always result in more than 1 character being
read. This is incorrect. If only 1 character was read the test
would go outside of the buffer and access other memory causing
a crash.

The test now checks to ensure that 2 or more characters are read
in ensuring the test stays within the buffer.

ASTERISK-25874 #close

Change-Id: Ic2c89cea6e90f2c0bc2d8138306ebbffd4f8b710

If try to move message to Cust1 (number 5)
the function 'save_to_folder' tries to create Greeting folder instead of Cust1.

This patch fixed it by setting GREETINGS_FOLDER = -1

ASTERISK-24927 #close

Change-Id: I03d1a761894bcc2d130ec9b003bbcddc28e25c51

Sometimes uw-imap function 'mail_fetchbody' returns huge len
which then pass to uw-imap function 'rfc822_base64'.
uw-imap tries to allocate huge memory and abort() on fail.

This patch check the len.
If the len more than max size (128 Mbytes) log error.
This patch also set variables len, newlen to avoid uninizialezed len.
This patch also check pointer returned by rfc822_base64.

ASTERISK-25899 #close

Change-Id: I4a0e7d655f11abef6a5224e2169df6d5c1f1caca

This eliminates some casts that I made a note saying v10 and above
would no longer need them.

Better late than never :)

Change-Id: I346cdb3032b6478ceb40eb6fe732978b54035572