Commit 39cc28f6 attempted to fix a
test failure observed on 32 bit test agents by ensuring that a cast from
a 32 bit unsigned integer to a 64 bit unsigned integer was happening in
a predictable place. As it turns out, this did not cause test runs to
succeed.

This commit adds several redundant debug messages that print the payload
lengths of websocket frames. The idea here is that this commit will not
cause tests to succeed for the faulty test agent, but we might deduce
where the fault lies more easily this way by observing at what point the
expected value (537) changes to some ungangly huge number.

If you are wondering why something like this is being committed to the
branch, keep in mind that in commit
39cc28f6 I noted that the observed test
failures only happen when automated tests are run. Attempts to run the
tests by hand manually on the test agent result in the tests passing.

Change-Id: I14a65c19d8af40dadcdbd52348de3b0016e1ae8d

We have seen a rash of test failures on a 32-bit build agent. Commit
48698a5e solved an obvious problem where
we were not encoding a 64-bit value correctly over the wire. This
commit, however, did not solve the test failures.

In the failing tests, ARI is attempting to send a 537 byte text frame
over a websocket. When sending a frame this small, 16 bits are all that
is required in order to encode the payload length on the websocket
frame. However, ast_websocket_write() thinks that the payload length is
greater than 65535 and therefore writes out a 64 bit payload length.
Inspecting this payload length, the lower 32 bits are exactly what we
would expect it to be, 537 in hex. The upper 32 bits, are junk values
that are not expected to be there.

In the failure, we are passing the result of strlen() to a function that
expects a uint64_t parameter to be passed in. strlen() returns a size_t,
which on this 32-bit machine is 32 bits wide. Normally, passing a 32-bit
unsigned value to somewhere where a 64-bit unsigned value is expected
would cause no problems. In fact, in manual runs of failing tests, this
works just fine. However, ast_websocket_write() uses the Asterisk
optional API, which means that rather than a simple function call, there
are a series of macros that are used for its declaration and
implementation. These macros may be causing some sort of error to occur
when converting from a 32 bit quantity to a 64 bit quantity.

This commit changes the logic by making existing ast_websocket_write()
calls use ast_websocket_write_string() instead. Within
ast_websocket_write_string(), the 64-bit converted strlen is saved in a
local variable, and that variable is passed to ast_websocket_write()
instead.

Note that this commit message is full of speculation rather than
certainty. This is because the observed test failures, while always
present in automated test runs, never occur when tests are manually
attempted on the same test agent. The idea behind this commit is to fix
a theoretical issue by performing changes that should, at the least,
cause no harm. If it turns out that this change does not fix the failing
tests, then this commit should be reverted.

Change-Id: I4458dd87d785ca322b89c152b223a540a3d23e67

* changes:
  rtp_engine.h: No sense allowing payload types larger than RFC allows.
  rtp_engine.c: Minor tweaks.
  rtp_engine.h: Misc comment fixes.

An http request can be sent to rotate a specified log channel.
If the channel does not exist, an error response will be
returned.

The command "curl -v -u user:pass -X PUT 'http://localhost:8088
/ari/asterisk/logging/logChannelName/rotate'" can be run in the
terminal to access this new functionality.

* Added the ability to rotate log files through ARI

ASTERISK-25252

Change-Id: Iaefa21cbbc1b29effb33004ee3d89c977e76ab01

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

A testsuite test recently failed due to a crash that occurred in the DNS
core. The problem was that the test could not resolve an address, did
not set a result on the DNS query, and then indicated the query was
completed. The DNS core does not handle the case of a query with no
result gracefully, and so there is a crash.

This changeset makes the DNS system resolver set a result with a
zero-length answer in the case that a DNS resolution failure occurs
early. The DNS core now also will accept such a response without
treating it as invalid input. A unit test was updated to no longer treat
setting a zero-length response as off-nominal.

Change-Id: Ie56641e22debdaa61459e1c9a042e23b78affbf6

* Tweaked add_static_payload() to not use magic numbers.

Change-Id: I1719ff0f6d3ce537a91572501eae5bcd912a420b

* Fix off nominial ref leak of new_type in
ast_rtp_codecs_payloads_set_m_type().

* No need to lock static_RTP_PT_lock in
ast_rtp_codecs_payloads_set_m_type() and
ast_rtp_codecs_payloads_set_rtpmap_type_rate() before the payload type
parameter sanity check.

* No need to create ast_rtp_payload_type ao2 objects with a lock since the
lock is not used.

Change-Id: I64dd1bb4dfabdc7e981e3f61448beac9bb7504d4

Change glue->update_peer() parameter from 0 to NULL to better indicate it
is a pointer.

Change-Id: I8ff2e5087f0e19f6998e3488a712a2470cc823bd

Change-Id: If98139264d5d97427b4685ecbdc54518f725bc43

Two testsuite tests crashed in the same place as a result of an INVITE
being CANCELed.

tests/channels/pjsip/resolver/srv/failover/in_dialog/transport_unspecified
tests/channels/pjsip/resolver/srv/failover/in_dialog/transport_tcp

The session pointer is no longer in the inv->mod_data[session_module.id]
location because the INVITE transaction has reached the terminated state.

ASTERISK-25297 #close
Reported by: Richard Mudgett

Change-Id: Idb75fdca0321f5447d5dac737a632a5f03614427

A test agent was continuously failing all ARI tests when run against
Asterisk 13. As it turns out, the reason for this is that on those test
runs, for some reason we decided to use the super extended 64 bit
payload length for websocket text frames instead of the extended 16 bit
payload length. For 64-bit payloads, the expected byte order over the
network is

7, 6, 5, 4, 3, 2, 1, 0

However, we were sending the payload as

3, 2, 1, 0, 7, 6, 5, 4

This meant that we were saying to expect an absolutely MASSIVE payload
to arrive. Since we did not follow through on this expected payload
size, the client would sit patiently waiting for the rest of the payload
to arrive until the test would time out.

With this change, we use the htobe64() function instead of htonl() so
that a 64-bit byte-swap is performed instead of a 32 bit byte-swap.

Change-Id: Ibcd8552392845fbcdd017a8c8c1043b7fe35964a

This event is necessary for the bridge_wait_e_options test to be able to
confirm that ringing is being played on the local channel that runs the
BridgeWait() application with the e(r) option.

ASTERISK-25292 #close
Reported by Kevin Harwell

Change-Id: Ifd3d3d2bebc73344d4b5310d0d55c7675359d72e

This will add ECDH support to Asterisk. It will
detect auto ECDH support in OpenSSL
(1.0.2b and above) during ./configure. If this is
available, it will use it,
otherwise it will fall back to prime256v1 (this
behavior is consistent with
other projects such as Apache and nginx).

This fixes WebRTC being broken in Firefox 38+ due
to Firefox now only supporting
ciphers with perfect forward secrecy.

ASTERISK-25265 #close

Change-Id: I8c13b33a2a79c0bde2e69e4ba6afa5ab9351465b

Currently, if a blank musiconhold.conf is used, musiconhold will fail
to start for a channel going into a holding bridge with an anticipation
of getting music on hold. That being the case, no frames will be written
to the channel and that can pose a problem for blind transfers in PJSIP
which may rely on frames being written to get past the REFER framehook.
This patch makes holding bridges start a silence generator if starting
music on hold fails and makes it so that if no music on hold functions
are installed that the ast_moh_start function will report a failure so
that consumers of that function will be able to respond appropriately.

ASTERISK-25271 #close

Change-Id: I06f066728604943cba0bb0b39fa7cf658a21cd99
(cherry picked from commit 8458b8d4)

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