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

Last time I checked, it's "Sangoma", not "Samgoma". Thanks to Brian
(GameGamer43) for pointing that out.

Change-Id: I43d7b196f6d7a2b2517b84915e3a8dfbc2894106

Changed the unload mode to AST_FORCE_SOFT from AST_FORCE_FIRM,
which would unload a module even if it was in use.

* Changed unload mode to proper mode

ASTERISK-25173

Change-Id: If2402487b5bce05d9770f25f65f5c8e292ad5533

The crash fix for ASTERISK-25183 backported some code from master to try
to make sure that a BYE response is processed by the same serializer used
by the BYE request.  The identified race condition causing that backport
was the BYE request code had not finished processing after sending the BYE
before the BYE response came in for processing under a different thread.
Unfortunately, there is still a race condition.  Now the race condition is
between destroying the call session's serializer in
ast_taskprocessor_unreference() and using ast_taskprocessor_get() to get a
reference to the serializer for a BYE response.  Even worse, the new race
condition is a design limitation of the taskprocessor implementation that
didn't matter in versions before v12.  Back then, taskprocessors were only
destroyed when a module unloaded.  Now res_pjsip can destroy them when a
call ends.

However, as noted on the ASTERISK-25183 commit,
session_inv_on_state_changed() is disassociating the dialog from the
session when the invite dialog state becomes PJSIP_INV_STATE_DISCONNECTED.
This is a tad too soon because our BYE request transaction has not
completed yet.

* Split session_end() that is called by session_inv_on_state_changed() to
hold off session destruction until the BYE transaction timeout occurs or a
failed initial INVITE transaction timeout occurs in
session_inv_on_tsx_state_changed().

ASTERISK-25201 #close
Reported by: Matt Jordan

Change-Id: Iaf8dc8485fd8392a2a3ee4ad3b7f7f04a0dcc961

An http request can be sent to reload an Asterisk module. If the
module can not be reloaded or is not already loaded, an error
response will be returned.

The command "curl -v -u user:pass -X PUT 'http://localhost:8088
/ari/asterisk/modules/{moduleName}'" (or something similar, based
on configuration) can be run in the terminal to access this new
functionality.

For more information, see:
https://wiki.asterisk.org/wiki.display/~bford/Asterisk+ARI+Resource

* Added new ARI functionality
* Asterisk modules can be reloaded through http requests

ASTERISK-25173

Change-Id: I289188bcae182b2083bdbd9ebfffd50b62f58ae1