Prior to ASTERISK-24988, the WebSocket handshake was resolved before Stasis
applications were registered. This was done such that the WebSocket would be
ready when an application is registered. However, by creating the WebSocket
first, the client had the ability to make requests for the Stasis application
it thought had been created with the initial handshake request. The inevitable
conclusion of this scenario was the cart being put before the horse.

ASTERISK-24988 resolved half of the problem by ensuring that the applications
were created and registered with Stasis prior to completing the handshake
with the client. While this meant that Stasis was ready when the client
received the green-light from Asterisk, it also meant that the WebSocket was
not yet ready for Stasis to dispatch messages.

This patch introduces a message queuing mechanism for delaying messages from
Stasis applications while the WebSocket is being constructed. When the ARI
event processor receives the message from the WebSocket that it is being
created, the event processor instantiates an event session which contains a
message queue. It then tries to create and register the requested applications
with Stasis. Messages that are dispatched from Stasis between this point and
the point at which the event processor is notified the WebSocket is ready, are
stashed in the queue. Once the WebSocket has been built, the queue's messages
are dispatched in the order in which they were originally received and the
queue is concurrently cleared.

ASTERISK-25181 #close
Reported By: Matt Jordan

Change-Id: Iafef7b85a2e0bf78c114db4c87ffc3d16d671a17

This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold'
endpoint options. These allow the channel to be hung up if RTP
is not received from the remote endpoint for a specified number of
seconds.

ASTERISK-25259 #close

Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9

Change-Id: I5f62d0c5684f8b2335f9f8ac2d79ee04fbdafb19

Commit 54b25c80 solved an issue where a
specific scenario involving local channels and a native local RTP bridge
could result in ringback still being heard on a calling channel even
after the call is bridged.

That commit caused many tests in the testsuite to fail with alarming
consequences, such as not sending DialBegin and DialEnd events, and
giving incorrect hangup causes during calls.

This commit reverts the previous commit and implements and alternate
solution. This new solution involves only passing AST_CONTROL_RINGING
frames across local channels if the local channel is in AST_STATE_RING.
Otherwise, the frame does not traverse the local channels. By doing
this, we can ensure that a playtones generator does not get started on
the calling channel but rather is started on the local channel on which
the ringing frame was initially indicated.

ASTERISK-25250 #close
Reported by Etienne Lessard

Change-Id: I3bc87a18a38eb2b68064f732d098edceb5c19f39

Previous changes to sample rate support in audiohooks accidentally
removed code responsible for allowing the manipulate audiohooks
to work. Without this code the manipulated frame would be dropped
and not used. This change restores it.

ASTERISK-25253 #close

Change-Id: I3ff50664cd82faac8941f976fcdcb3918a50fe13

Control frames with a -1 payload are used as a special signal to stop
playtones generators on channels. This indication is sent both by
app_dial as well as by ast_answer() when a call is answered in case any
tones were being generated on a calling channel.

This control frame type was made to stop traversing local channel pairs
as an optimization, because it was thought that it was unnecessary to
send these indications, and allowing such unnecessary control frames to
traverse the local channels would cause the local channels to optimize
away less quickly.

As it turns out, through some special magic dialplan code, it is
possible to have a tones being played on a non-local channel, and it is
important for the local channel to convey that the tones should be
stopped. The result of having tones continue to be played on the
non-local channel is that the tones play even once the channel has been
bridged. By not blocking the -1 control frame type, we can ensure that
this situation does not happen.

ASTERISK-25250 #close
Reported by Etienne Lessard

Change-Id: I0bcaac3d70b619afdbd0ca8a8dd708f33fd2f815

Due to changes in audiohooks to support different sample rates the
underlying storage of samples is in the format of the audiohook
itself and not of the format being requested. This means that if a
channel is using G722 the samples stored will be at 16kHz. If
something subsequently reads from the audiohook at a format which
is not the same sample rate as the audiohook the number of samples
needs to be adjusted.

Given the following example:
1. Channel writing into audiohook at 16kHz (as it is using G722).
2. Chanspy reading from audiohook at 8kHz.

The original code would read 160 samples from the audiohook for
each 20ms of audio. This is incorrect. Since the audio in the
audiohook is at 16kHz the actual number needing to be read is 320.
Failure to read this much would cause the audiohook to reset
itself constantly as the buffer became full.

This change adjusts the requested number of samples by determining
the duration of audio requested and then calculating how many
samples that would be in the audiohook format.

ASTERISK-25247 #close

Change-Id: Ia91ce516121882387a315fd8ee116b118b90653d

Commit a24ce38e added support for the use of quoted indentifiers when inserting
CDR records into the database. However, the if statement logic responsible for
determining whether to use those identifiers is reversed, resulting in a
reference to the quoted identifier character buffer which will be null, hence
null terminating the SQL query, resulting in a truncated statement which
fails to execute.

ASTERISK-25263 #close
Reported by: Elazar Broad
Tested by: Elazar Broad

Change-Id: I40da47309b67cc1572207b1515dcc08ec9b1f644

 * In sip.conf.sample fix sentence where we said that WS or WSS are supported
   transports for use in an outbound register definition. They are not
   supported in that case.
 * In func_cdr.c made it clear that the Disable option for CDR_PROP can be used
   to enable CDR on a channel.

ASTERISK-24867 #close
Reported by: Rusty Newton

ASTERISK-24853 #close
Reported by: PSDK

Change-Id: I3d698bc6302b9d00a0a995b5c4ad9a42d69b48ca

This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the
chan_sip option, this specifies an interval, in seconds, at which we
will send RTP comfort noise frames. This can be useful for keeping RTP
sessions alive as well as keeping NAT associations alive during lulls.

ASTERISK-25242 #close
Reported by Mark Michelson

Change-Id: I3b9903d99e35fe5d0b53ecc46df82c750776bc8d

Change-Id: Ifdfbd0b97cf31478d29923ec30aabce28d01740b

Misconfiguring sorcery.conf with a 'config' wizard with no extra data
will currently crash Asterisk on startup, as the wizard requires a comma
delineated list to parse. This patch updates res_sorcery_config to check
for the presence of the data before it starts manipulating it.

Change-Id: I4c97512e8258bc82abe190627a9206c28f5d3847

Receipt of an RTP packet currently causes the formats on an PJSIP channel to
change to the format of the RTP packet. In some off-nominal cases it's possible
for this to be a format that has not been configured or negotiated. This change
makes it so only formats explicitly configured on the endpoint are allowed.

ASTERISK-25258 #close

Change-Id: If93d641fb6418a285928839300d7854cab8c1020

ASTERISK-25256 #close
Reported by: Richard Mudgett

Change-Id: I0b6be720b66fa956f6a798cd22ef8934eb0c0ff3

In channels/sig_pri.h, struct sig_pri_span, the field
force_restart_unavailable_chans is only defined if

#if defined(HAVE_PRI_MCID) is true.

All other occurences of force_restart_unavailable_chans are outside of the

#if defined(HAVE_PRI_MCID)
endif

scope.

ASTERISK-25257 #close
Reported by: Patric Marschall

Change-Id: I071de89cc2cd0d85927a013036e235851f672549

This patch adds support for push configuration of dynamic, i.e.,
sorcery, objects in Asterisk. It adds three new REST API calls to the
'asterisk' resource:
 * GET /asterisk/{configClass}/{objectType}/{id}: retrieve the current
   object given its ID. This returns back a list of ConfigTuples, which
   define the fields and their present values that make up the object.
 * PUT /asterisk/{configClass}/{objectType}/{id}: create or update an
   object. A body may be passed with the request that contains fields to
   populate in the object. The same format as what is retrieved using
   the GET operation is used for the body, save that we specify that the
   list of fields to update are contained in the "fields" attribute.
 * DELETE /asterisk/{configClass}/{objectType}/{id}: remove a dynamic
   object from its backing storage.

Note that the success/failure of these operations is somewhat
configuration dependent, i.e., you must be using a sorcery wizard that
supports the operation in question. If a sorcery wizard does not support
the create or delete mechanisms, then the REST API call will fail with a
403 forbidden.

ASTERISK-25238 #close

Change-Id: I28cd5c7bf6f67f8e9e437ff097f8fd171d30ff5c

Fixes for issues with the ASTERISK-24934 patch.

* Fixed ast_escape_alloc() and ast_escape_c_alloc() if the s parameter is
an empty string.  If it were an empty string the functions returned NULL
as if there were a memory allocation failure.  This failure caused the AMI
VarSet event to not get posted if the new value was an empty string.

* Fixed dest buffer overwrite potential in ast_escape() and
ast_escape_c().  If the dest buffer size is smaller than the space needed
by the escaped s parameter string then the dest buffer would be written
beyond the end by the nul string terminator.  The num parameter was really
the dest buffer size parameter so I renamed it to size.

* Made nul terminate the dest buffer if the source string parameter s was
an empty string in ast_escape() and ast_escape_c().

* Updated ast_escape() and ast_escape_c() doxygen function description
comments to reflect reality.

* Added some more unit test cases to /main/strings/escape to cover the
empty source string issues.

ASTERISK-25255 #close
Reported by: Richard Mudgett

Change-Id: Id77fc704600ebcce81615c1200296f74de254104

Change-Id: I8797238c71563e243c48c6145b4f1ae58f91f775

setup_park_common_datastore() was assuming that a non-NULL string returned
for the ATTENDEDTRANSFER and BLINDTRANSFER channel variables are not empty
strings.  Things got crashy as a result.

* Made setup_park_common_datastore() treat the channel variable values the
same whether they are NULL or empty for ATTENDEDTRANSFER and
BLINDTRANSFER.

ASTERISK-25254 #close
Reported by: Richard Mudgett

Change-Id: I9a9c174b33f354f35f82cc6b7cea8303adbaf9c2

Change-Id: I9e115dee74bd72e06081d0ee73ecdeb886caa5fb

Change-Id: I742aeeaf5f760593f323a00fb691affe22e35743

Change-Id: I09928297927ee85f7655289acee3a586816466bc