We have seen a rash of test failures on a 32-bit build agent. Commit
48698a5e21 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
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
* 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
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 8458b8d441)
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
Commit 54b25c80c8 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 a24ce38 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
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
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
Matt Jordan
Mark Michelson
Joshua Colp
Benjamin Ford
Ashley Sanders
Richard Mudgett
Mark Duncan
Jonathan Rose
Elazar Broad
Rusty Newton
Michael Cargile
Patric Marschall