An http request can be sent to get the existing Asterisk logs.
The command "curl -v -u user:pass -X GET 'http://localhost:8088
/ari/asterisk/logging'" can be run in the terminal to access the
newly implemented functionality.
* Retrieve all existing log channels
ASTERISK-25252
Change-Id: I7bb08b93e3b938c991f3f56cc5d188654768a808
An http request can be sent to create a log channel
in Asterisk.
The command "curl -v -u user:pass -X POST
'http://localhost:088/ari/asterisk/logging/mylog?
configuration=notice,warning'" can be run in the terminal
to access the newly implemented functionality for ARI.
* Ability to create log channels using ARI
ASTERISK-25252
Change-Id: I9a20e5c75716dfbb6b62fd3474faf55be20bd782
An http request can be sent to delete a log channel
in Asterisk.
The command "curl -v -u user:pass -X DELETE 'http://localhost:8088
/ari/asterisk/logging/mylog'" can be run in the terminal
to access the newly implemented functionally for ARI.
* Able to delete log channels using ARI
ASTERISK-25252
Change-Id: Id6eeb54ebcc511595f0418d586ff55914bc3aae6
Commit 39cc28f6ea 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
39cc28f6ea 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
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
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
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
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
An http request can be sent to unload an Asterisk module. If the
module can not be unloaded or is already unloaded, an error response
will be returned.
The command "curl -v -u user:pass -X DELETE 'http://localhost:8088
/ari/asterisk/modules/{moduleName}'" (or something similar, depending
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 unloaded through http requests
ASTERISK-25173
Change-Id: I535a95f5676deb02651522761ecbdc0b00b5ac57
An http request can be sent to load an Asterisk module. If the
module can not be loaded or is loaded already, an error response
will be returned.
The command curl -v -u user:pass -X POST 'http://localhost:8088/ari
/asterisk/modules/{moduleName}'" (or something similar, depending 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 loaded through http requests
ASTERISK-25173
Change-Id: I9e05d5b8c5c666ecfef341504f9edc1aa84fda33
An http request can be sent to retrieve information on a single
module, including the resource name, description, use count, status,
and support level.
The command "curl -v -u user:pass -X GET 'http://localhost:8088/ari
/asterisk/modules/{moduleName}'" (or something similar, depending 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
* Information on a single module can now be retrieved
ASTERISK-25173
Change-Id: Ibce5a94e70ecdf4e90329cf0ba66c33a62d37463
An http request can be sent to retrieve a list of all existing modules,
including the resource name, description, use count, status, and
support level.
The command "curl -v -u user:pass -X GET 'http://localhost:8088/ari/
asterisk/modules" (or something similar, depending 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
* Information on modules can now be retrieved
Change-Id: I63cbbf0ec0c3544cc45ed2a588dceabe91c5e0b0
Prior to this patch, when a WebSocket connection is made, ARI would not
be informed of the connection until after the WebSocket layer had
accepted the connection. This created a brief race condition where the
ARI client would be notified that it was connected, a channel would be
sent into the Stasis dialplan application, but ARI would not yet have
registered the Stasis application presented in the HTTP request that
established the WebSocket.
This patch resolves this issue by doing the following:
* When a WebSocket attempt is made, a callback is made into the ARI
application layer, which verifies and registers the apps presented in
the HTTP request. Because we do not yet have a WebSocket, we cannot
have an event session for the corresponding applications. Some
defensive checks were thus added to make the application objects
tolerant to a NULL event session.
* When a WebSocket connection is made, the registered application is
updated with the newly created event session that wraps the WebSocket
connection.
ASTERISK-24988 #close
Reported by: Joshua Colp
Change-Id: Ia5dc60dc2b6bee76cd5aff0f69dd53b36e83f636
Missed this module in the previous commit. res_ari_bridges uses symbols
from res_stasis_playback and res_stasis_recording.
ASTERISK-25027 #close
Reported by: Corey Farrell
Change-Id: I90bf756abd25adfc4920d2869ebe7feb636b8c5f
The res_ari_device_states module depends on res_stasis_device_state,
not res_stasis_device_states.
Change-Id: I26e02ad37f9e36bcc859867e2fad1b90452ec3de
ARI modules that are generated by 'make ari-stubs' are all dependent on
res_ari_model. Additionally some of the same modules depend on one or more
res_stasis_* modules.
ASTERISK-25027 #close
Reported by: Corey Farrell
Change-Id: I8e07fe7e81fedacb87232f2b6f8b5f47927b4153
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
When the ChannelHold event was added, the 'musicclass' parameter was
erroneously removed. This caused the ChannelHold events to be rejected as
they failed model validation. This patch updates the Swagger schema such that
it now properly reflects the event that is being created.
Hooray for tests that catch things like this.
........
Merged revisions 434597 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434598 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes autological comparison warnings in the following:
* chan_skinny: letohl may return a signed or unsigned value, depending on the
macro chosen
* func_curl: Provide a specific cast to CURLoption to prevent mismatch
* cel: Fix enum comparisons where the enum can never be negative
* enum: Fix comparison of return result of dn_expand, which returns a signed
int value
* event: Fix enum comparisons where the enum can never be negative
* indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
negative
* presencestate: Use the actual enum value for INVALID state
* security_events: Fix enum comparisons where the enum can never be negative
* udptl: Don't bother to check if the return value from encode_length is less
than 0, as it returns an unsigned int
* translate: Since the parameters are unsigned int, don't bother checking
to see if they are negative. The cast to unsigned int would already blow
past the matrix bounds.
* res_pjsip_exten_state: Use a temporary value to cache the return of
ast_hint_presence_state
* res_stasis_playback: Fix enum comparisons where the enum can never be
negative
* res_stasis_recording: Add an enum value for the case where the recording
operation is in error; fix enum comparisons
* resource_bridges: Use enum value as opposed to -1
* resource_channels: Use enum value as opposed to -1
Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4533.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.
One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.
In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.
Review: https://reviewboard.asterisk.org/r/4549/
ASTERISK-24922 #close
........
Merged revisions 434216 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Switch logger callid's from AO2 objects to simple integers.
This helps in two ways. Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead. This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.
ASTERISK-24833 #comment Committed callid conversion to trunk.
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sending the following ARI commands caused Asterisk to crash if the JSON
body 'variables' object passes values of types other than strings.
POST /ari/channels
POST /ari/channels/{channelid}
PUT /ari/endpoints/sendMessage
PUT /ari/endpoints/{tech}/{resource}/sendMessage
* Eliminated RAII_VAR usage in ast_ari_channels_originate_with_id(),
ast_ari_channels_originate(), ast_ari_endpoints_send_message(), and
ast_ari_endpoints_send_message_to_endpoint().
ASTERISK-24751 #close
Reported by: jeffrey putnam
Review: https://reviewboard.asterisk.org/r/4447/
........
Merged revisions 432404 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432405 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes it so that if a channel variable is requested and it does not exist
a 404 response will be returned instead of an allocation failed response. This makes
it easier to debug and figure out what is going on for a user.
ASTERISK-24677 #close
Reported by: Joshua Colp
........
Merged revisions 432154 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One of the canonical reasons for hanging up a channel is because the far end
failed to answer - or because someone else answered, and we want to get rid of
this channel. This patch adds the missing value to the 'reason' query parameter
for the DELETE /channels operation.
Review: https://reviewboard.asterisk.org/r/4400
ASTERISK-24745 #close
Reported by: Ben Merrills
patches:
add_no_answer_ari_hangup_cause.diff uploaded by Ben Merrills (License 6678)
........
Merged revisions 431622 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch improves the documentation of ARI on the wiki. Specifically, it
addresses the following:
* Allowed values and allowed ranges weren't documented. This was particularly
frustrating, as Asterisk would reject query parameters with disallowed values
- but we didn't tell anyone what the allowed values were.
* The /play/id operation on /channels and /bridges failed to document all of
the added media resource types.
* Documentation for creating a channel into a Stasis application failed to
note when it occurred, and that creating a channel into Stasis conflicts with
creating a channel into the dialplan.
* Some other minor tweaks in the mustache templates, including italicizing the
parameter type, putting the default value on its own sub-bullet, and some
other nicities.
Review: https://reviewboard.asterisk.org/r/4351
........
Merged revisions 431145 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431148 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this changeset, posting to the: /ari/bridges/{bridgeId} endpoint without specifying a value for the [name] query parameter, would crash Asterisk if the bridge you are attempting to create (or update) had the same ID as an existing bridge. The internal mechanism of the POST operation interpreted a null value for name, thus resulting in an error condition that crashed Asterisk.
ASTERISK-24560 #close
Reported By: Kinsey Moore
Review: https://reviewboard.asterisk.org/r/4349/
........
Merged revisions 430818 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this patch, the following two ARI commands
POST /channels
POST /channels/{id}/continue
Accept a new parameter, label, that can be used to continue to or originate
to a priority label in the dialplan.
Because this is adding a new parameter to ARI commands, the API version of
ARI has been bumped from 1.6.0 to 1.7.0.
This patch comes courtesy of Nir Simionovich from Greenfield Tech. Thanks!
ASTERISK-24412 #close
Reported by Nir Simionovich
Review: https://reviewboard.asterisk.org/r/4285
........
Merged revisions 430337 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a blind transfer occurs that is forced to create a local channel
pair to satisfy the transfer request, information about the local
channel pair is not published. This adds a field to describe that
channel to the blind transfer message struct so that this information
is conveyed properly to consumers of the blind transfer message.
This also fixes a bug in which Stasis() was unable to properly identify
the channel that was replacing an existing Stasis-controlled channel
due to a blind transfer.
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3921/
........
Merged revisions 421537 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421538 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r421311 | mjordan | 2014-08-17 20:11:28 -0500 (Sun, 17 Aug 2014) | 9 lines
res/ari/resource_channels: Don't return allocation failure on failed function
If a function fails to execute, it is most likely due to one of two reasons:
(1) The function doesn't exist or can't be read from
(2) The function is dangerous and is restricted based on the user's permissions
Currently we return allocation failure, which is incorrect. This updates the
reason code to more accurately reflect why the request failed.
ASTERISK-24215
........
r421312 | mjordan | 2014-08-17 20:13:41 -0500 (Sun, 17 Aug 2014) | 4 lines
res/ari/resource_channels: Fix compilation issue
Forgot a parameter. Whoops.
........
Merged revisions 421311-421312 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421313 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a few issues:
1) The order of Dial events have been changed when performing a call forward.
The order has now been altered to
1) Dial begins dialing channel A.
2) When A forwards the call to B, we issue the dial end event to channel
A, indicating the dial is being canceled due to a forward to B.
3) When the call to channel B occurs, we then issue a new dial begin to
channel B.
2) Call forwards are now reported on the calling channel, not the peer channel.
3) AMI DialEnd events have been altered to display the extension the call is
being forwarded to when relevant.
4) You can now get the values of channel variables for channels that are not
currently in the Stasis application. This brings the retrieval of channel
variables more in line with the rest of channel read operations since they
may be performed on channels not in Stasis.
ASTERISK-24134 #close
Reported by Matt Jordan
ASTERISK-24138 #close
Reported by Matt Jordan
Patches:
forward-shenanigans.diff uploaded by Matt Jordan (License #6283)
Review: https://reviewboard.asterisk.org/r/3899
........
Merged revisions 420794 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r419565 | mjordan | 2014-07-25 09:41:23 -0500 (Fri, 25 Jul 2014) | 21 lines
ARI: report duration values in LiveRecording objects
This patch adds three new fields to the LiveRecording model:
- total_duration: the total length of the live recording
- talking_duration: optional. The duration of talking energy that was
detected while the recording was made.
- silence_duration: optional. The duration of silence that was detected while
the recording was made.
These values are reported in the RecordingFinished ARI event.
When a DSP is enabled on the channel during the recording - which occurs when
the recording is created with max_silence_seconds (indicating that the user
actually cares about how much silence is in the file), we will report the
talking_duration and silence_duration in addition to the total_duration.
Review: https://reviewboard.asterisk.org/r/3770/
ASTERISK-24037 #close
Reported by: Samuel Galarneau
........
r419566 | mjordan | 2014-07-25 09:46:15 -0500 (Fri, 25 Jul 2014) | 1 line
Update CHANGES for r419565
........
Merged revisions 419565-419566 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419567 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new operation for stored recordings, copy. It takes an
existing stored recording and makes a copy of it in the same directory
or a relative directory under the stored recording directory.
/ari/recordings/stored/{recordingName}/copy?destinationRecordingName={copy_name}
This is particularly useful for voicemail-esque applications, which may need to
copy or move recordings around a directory structure.
Review: https://reviewboard.asterisk.org/r/3768/
ASTERISK-24036 #close
Reported by: Sam Galarneau
Tested by: Sam Galarneau
........
Merged revisions 419021 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two bugs:
1. When originating a channel into a Stasis application, we already create a
subscription for the channel that is going into our Stasis app.
Unfortunately, when you create a Local channel and pass it off to a Stasis
app, you really aren't creating just one channel: you're creating two. This
patch snags the second half of the Local channel pair (assuming it is a
Local channel pair, but luckily core_local is kind about such assumptions)
and subscribes to it as well.
2. Subscriptions are a bit sticky right now. If a subscription is made, the
'interest' count gets bumped on the Stasis subscription - but unless
something explicitly unsubscribes the channel, said subscription sticks
around. This is not much of a problem is a user is creating the subscription
- if they made it, they must want it. However, when we are creating
implicit subscriptions, we need to make sure something clears them out.
This patch takes a pessimistic approach: it watches the cache updates
coming from Stasis and, if we notice that the cache just cleared out an
object, we delete our subscription object. This keeps our ao2 container of
Stasis forwards in an application from growing out of hand; it also is a
bit more forgiving for end users who may not realize they were supposed to
unsubscribe from that channel that just hung up.
Review: https://reviewboard.asterisk.org/r/3710/
#ASTERISK-23939 #close
........
Merged revisions 418089 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The variables body parameter under the originate and originate with id
operations of the channel resource showed invalid JSON in its description.
The variables body parameter under the userEvent operation of the event
resource made no mention that the custom key/value pairs should be wrapped
in a variables key in order to be added to the custom user event.
ASTERISK-23975 #close
Review: https://reviewboard.asterisk.org/r/3692/
........
Merged revisions 417878 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.
#ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
........
Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new channel function TALK_DETECT that, when set on a
channel, causes events indicating the start/stop of talking on a channel to be
emitted to both AMI and ARI clients.
The function allows setting both the silence threshold (the length of silence
after which we decide no one is talking) as well as the talking threshold (the
amount of energy that counts as talking). Parameters can be updated on a channel
after talk detection has been enabled, and talk detection can be removed at
any time.
The events raised by the function use a nomenclature similar to existing AMI/ARI
events.
For AMI: ChannelTalkingStart/ChannelTalkingStop
For ARI: ChannelTalkingStarted/ChannelTalkingFinished
Review: https://reviewboard.asterisk.org/r/3563/
#ASTERISK-23786 #close
Reported by: Matt Jordan
........
Merged revisions 414934 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414935 65c4cc65-6c06-0410-ace0-fbb531ad65f3
User events can now be generated from ARI. Events can be signalled with
arbitrary json variables, and include one or more of channel, bridge, or
endpoint snapshots. An application must be specified which will receive
the event message (other applications can subscribe to it). The message
will also be delivered via AMI provided a channel is attached. Dialplan
generated user event messages are still transmitted via the channel, and
will only be received by a stasis application they are attached to or if
the channel is subscribed to.
This change also introduces the multi object blob mechanism used to send
multiple snapshot types in a single message. The dialplan app UserEvent
was also changed to use multi object blob, and a new stasis message type
created to handle them.
ASTERISK-22697 #close
Review: https://reviewboard.asterisk.org/r/3494/
........
Merged revisions 414405 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds a tones URI type to the playback resource. The tone can be specified by
name (from indications.conf) or by a tone pattern. In addition, tonezone can
be specified in the URI (by appending ;tonezone=<zone>). Tones must be
stopped manually in order for a stasis control to move on from playback of
the tone. Tones may be paused, resumed, restarted, and stopped. They may
not be rewound or fast forwarded (tones can't be controlled in a way that
lets you skip around from note to note and pausing and resuming will also
restart the tone from the beginning). Tests are currently in development
for this feature (https://reviewboard.asterisk.org/r/3428/).
(closes issue ASTERISK-23433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3427/
........
Merged revisions 412535 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove unused RAII_VAR() declarations. The compiler cannot catch these
because the cleanup function "references" the unused variable. Some
actually allocated and released resources that were never used.
* Fixed some whitespace issues in stasis_bridges.c.
........
Merged revisions 412399 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix memory leak in ast_unreal_new_channels(). Made it generate the ;2
uniqueid on a stack variable instead of mallocing it.
* Made send error response to ARI and AMI requests instead of just logging
excessive uniqueid length and allowing truncation. action_originate() and
ari_channels_handle_originate_with_id().
* Fixed minor truncating uniqueid hole when generating the ;2 uniqueid
string length. Created public and internal lengths of uniqueid. The
internal length can handle a max public uniqueid plus an appended ;2.
* free() and ast_free() are NULL tolerant so they don't need a NULL test
before calling.
* Made use better struct initialization format instead of the position
dependent initialization format. Also anything not explicitly initialized
in the struct is initialized to zero by the compiler.
* Made ast_channel_internal_set_fake_ids() use the safer
ast_copy_string() instead of strncpy().
Review: https://reviewboard.asterisk.org/r/3371/
........
Merged revisions 410949 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change turns the bridge type field into a comma separated list of attributes.
These attributes include: mixing, holding, dtmf_events, and proxy_media. By setting
the various attributes a user can control the type of bridge created with the
behavior they need for their application.
(closes issue ASTERISK-23437)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3359/
........
Merged revisions 410904 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed off-nominal json ref counting issue with using the following API
calls: ast_json_object_set() and ast_json_array_append().
* Fixed off-nominal error reporting in ast_ari_endpoints_list().
* Fixed some miscellaneous off-nominal json ref counting issues in
report_receive_fax_status() and dial_to_json().
........
Merged revisions 408713 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408714 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch tweaks the behaviour of POST /channels with channel variables such
that the variables are passed into the pbx.c routines that perform the
origination. This allows the variables to be assigned to the newly created
channels immediately upon their construction, as opposed to be assigned after
the originate has completed.
The upshot of this is that the variables are available on the channels if
they execute in the dialplan, as opposed to only being available once the
channels are answered.
Review: https://reviewboard.asterisk.org/r/3183/
........
Merged revisions 407937 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds back in support for specifying channel variables during an
originate without compromising the ability to specify query parameters
in the JSON body. This was accomplished by generating the body-parsing
code in a separate function instead of being integrated with the URI
query parameter parsing code such that it could be called by paths with
body parameters. This is transparent to the user of the API and
prevents manual duplication of code or data structures.
(closes issue ASTERISK-23051)
Review: https://reviewboard.asterisk.org/r/3122/
Reported by: Matt Jordan
........
Merged revisions 406003 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds the following AMI commands:
PUT mailboxes/mailboxName
modifies mailbox state and implicitly creates new mailboxes
GET mailboxes/mailboxName
retrieves a JSON representation of a single mailbox if it exists
GET mailboxes
retrieves a JSON array of all mailboxes
DELETE mailbox/mailboxName
deletes a mailbox
Note that res_mwi_external must be loaded for these functions to
actually do anything.
Review: https://reviewboard.asterisk.org/r/3117/
........
Merged revisions 405553 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a few memory leaks that were found based
on a mailing list post.
1. Some JSON response messages were never freed. This was
caused by the documentation stating that message references
were stolen when in reality they were not. The code now follows
the documentation and usage has been updated.
2. HTTP response headers were never freed.
3. The variable list for wildcards paths was never freed.
(closes issue ASTERISK-23128)
Reported by: Kenneth Watson (on list)
Review: https://reviewboard.asterisk.org/r/3119/
........
Merged revisions 405325 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we added support for specifying channel variables for an
origination, we didn't consider how that would interact with another
feature, namely specifying request parameters in a JSON request body.
The method of specifying channel variables (as a flat JSON object passed
in the JSON body) interferes with parsing parameters out of the request
body.
Unfortunately, fixing this would be a backward incompatible change. In
the interest of keeping the API sane and keeping our release schedule,
we're dropping the feature for specifying channel variables in the
origination request.
We will bring the feature back soon, as a backward compatible addition
to the API.
(closes issue ASTERISK-23051)
Review: https://reviewboard.asterisk.org/r/3088
........
Merged revisions 404509 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation for ARI already specifies that the device state resource when
used for subscribing for events is "deviceState", not "device_state". The code,
however, used "device_state"; although this was inconsistent as well in doxygen
comments in resource_applications.
Because the actual resource being subscribed to is /deviceStates/{device}/, it
makes sense for the resource type specifier to be deviceState.
Note that the key value in the events is still "device_state".
........
Merged revisions 404437 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bridges have two new optional properties, a creator and a name.
Certain consumers of bridges will automatically provide bridges that
they create with these properties. Examples include app_bridgewait,
res_parking, app_confbridge, and app_agent_pool. In addition, a name
may now be provided as an argument to the POST function for creating
new bridges via ARI.
(closes issue AFS-47)
Review: https://reviewboard.asterisk.org/r/3070/
........
Merged revisions 404042 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404043 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When creating channels via ARI, the current code fails to provide any default
format capabilities. For non-virtual channels this isn't really a problem -
the channels typically receive their capabilities as a result of the
underlying channel driver configuration. For virtual channels (such as Local
channels), the lack of any format capabilities causes the Asterisk core to
make some 'odd' choices with respect to the translation paths. The issue
reporter had some paths that had 3 hops on each channel leg, causing multiple
transcodings and some really crappy audio/performance.
By specifying a baseline of SLIN, we prevent that from occurring. Note that
this is what AMI does when it performs an Originate, as does res_clioriginate.
Review: https://reviewboard.asterisk.org/r/3068/
(issue ASTERISK-22962)
Reported by: Matt DiMeo
........
Merged revisions 403993 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an event for when an originated call is redirected to
another target. This event contains the original channel and the newly
created channel. If a stasis subscription exists on the original originated
channel for a stasis application then a new subscription will also be
created on the stasis application to the redirected channel. This allows
the application to follow the call path completely.
(closes issue ASTERISK-22719)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/3054/
........
Merged revisions 403808 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability to specify channel variables when creating/originating a
channel in ARI. The variables are sent in the body of the request and should
be formatted as a single level JSON object. No nested objects allowed.
For example: {"variable1": "foo", "variable2": "bar"}.
(closes issue ASTERISK-22872)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3052/
........
Merged revisions 403752 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability to have rules that are checked when adding and/or removing
channels to/from a bridge. In this case, if a channel is currently recording
and someone attempts to add it to a bridge an "is recording" rule is checked,
fails, and a 409 conflict is returned.
Also command functions now return an integer value that can be descriptive of
what kind of problems, if any, occurred before or during execution.
(closes issue ASTERISK-22624)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2947/
........
Merged revisions 403749 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403750 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Created a data model and implemented functionality for an ARI device state
resource. The following operations have been added that allow a user to
manipulate an ARI controlled device:
Create/Change the state of an ARI controlled device
PUT /deviceStates/{deviceName}&{deviceState}
Retrieve all ARI controlled devices
GET /deviceStates
Retrieve the current state of a device
GET /deviceStates/{deviceName}
Destroy a device-state controlled by ARI
DELETE /deviceStates/{deviceName}
The ARI controlled device must begin with 'Stasis:'. An example controlled
device name would be Stasis:Example. A 'DeviceStateChanged' event has also
been added so that an application can subscribe and receive device change
events. Any device state, ARI controlled or not, can be subscribed to.
While adding the event, the underlying subscription control mechanism was
refactored so that all current and future resource subscriptions would be
the same. Each event resource must now register itself in order to be able
to properly handle [un]subscribes.
(issue ASTERISK-22838)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3025/
........
Merged revisions 403134 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change prevents channels used as implementation details from
leaking out to ARI. It does this by preventing creation of JSON blobs
of channel snapshots created from those channels and sanitizing JSON
blobs of bridge snapshots as they are created. This introduces a
framework for excluding information from output targeted at Stasis
applications on a consumer-by-consumer basis using channel sanitization
callbacks which could be extended to bridges or endpoints if necessary.
This prevents unhelpful error messages from being generated by
ast_json_pack.
This also corrects a bug where BridgeCreated events would not be
created.
(closes issue ASTERISK-22744)
Review: https://reviewboard.asterisk.org/r/2987/
Reported by: David M. Lee
........
Merged revisions 403069 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Was returning a 404 on a valid technology with an empty list of endpoints.
Now checking against the channel tech to make sure the tech itself is valid
and not just an empty list of endpoints.
(issue ASTERISK-22803)
Reported by: David M. Lee
........
Merged revisions 402793 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Implementation listing endpoints by technology returned an empty array if no
matching endpoints were found. Fixed so a "404 Not Found" will be returned
instead.
(closes issue ASTERISK-22803)
Reported by: David M. Lee
........
Merged revisions 402787 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While working on building client libraries from the Swagger API, I
noticed a problem with the nicknames.
channel.deleteChannel()
channel.answerChannel()
channel.muteChannel()
Etc. We put the object name in the nickname (since we were generating C
code), but it makes OO generators redundant.
This patch makes the nicknames more OO friendly. This resulted in a lot
of name changing within the res_ari_*.so modules, but not much else.
There were a couple of other fixed I made in the process.
* When reversible operations (POST /hold, POST /unhold) were made more
RESTful (POST /hold, DELETE /unhold), the path for the second operation
was left in the API declaration. This worked, but really the two
operations should have been on the same API.
* The POST /unmute operation had still not been REST-ified.
Review: https://reviewboard.asterisk.org/r/2940/
........
Merged revisions 402528 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ring operation sends ringing to the specified channel it is invoked on.
The dtmf operation can be used to send DTMF digits to the specified channel
of a specific length with a wait time in between. Finally hangup reasons
allow you to specify why a channel is being hung up (busy, congestion).
Early media behavior has also been tweaked slightly. When playing media to a channel
it will no longer automatically answer. If it has not been answered a progress indication
is sent instead.
(closes issue ASTERISK-22701)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2916/
........
Merged revisions 402358 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a Stasis application is specified an implicit subscription is done on the originated
channel. This was previously done with the channel lock held which is dangerous as the
underlying code locks the container and iterates items. This change releases the lock
on the originated channel before subscribing occurs.
(closes issue ASTERISK-22768)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2979/
........
Merged revisions 402346 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
