This patch does the following:
* It adds a new soft hangup flag AST_SOFTHANGUP_HANGUP_EXEC that is set when a
channel is executing dialplan hangup logic, i.e., the 'h' extension or a
hangup handler. Stasis messages now also convey the soft hangup flag so
consumers of the messages can know when a channel is executing said
hangup logic.
* It adds a new channel flag, AST_FLAG_DEAD, which is set when a channel is
well and truly dead. Not just a zombie, but dead, Jim. Manager, CEL, CDRs,
and other consumers of Stasis have been updated to look for this flag to
know when the channel should by lying six feet under.
* The CDR engine has been updated to better handle a channel entering and
leaving a bridge. Previously, a new CDR was automatically created when a
channel left a bridge and put into the 'Pending' state; however, this
way of handling CDRs made it difficult for the 'endbeforehexten' logic to
work correctly - there was always a new CDR waiting in the hangup logic
and, even if 'ended', wouldn't be the CDR people wanted to inspect in the
hangup routine. This patch completely removes the Pending state and instead
defers creation of the new CDR until it gets a new message that requires
a new CDR.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
information in the RTCP events. Because Stasis provides a cache, Jaco's
patch was modified to pass the channel uniqueid to the RTP layer as
opposed to a pointer to the channel. This has the following benefits:
(1) It keeps the RTP engine 'clean' of references back to channels
(2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages.
Potentially, other implementations (such as res_rtp_multicast) could also
raise RTCP information. The engine provides structs to represent RTCP headers
and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk was done to try and tame the
RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an
assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
raise an event when we sent a RR report.
Note that this work will be of use to others who want to monitor call quality
or build modules that report call quality statistics. Since the events are now
moving across the Stasis message bus, this is far easier to accomplish. It is
also a first step (though by no means the last step) towards getting Olle's
pinefrog work incorporated.
Again: note that the patch by Jaco Kroon was modified slightly for this work;
however, he did all of the hard work in finding the right places to set the
channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
for his hard work here.
Review: https://reviewboard.asterisk.org/r/2603/
(closes issue ASTERISK-20574)
Reported by: Jaco Kroon
patches:
asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
(closes issue ASTERISK-21471)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Legacy channel drivers often include the ability to set a default parking lot
on an endpoint basis; when channels are created for that endpoint, they inherit
the parkinglot option. Parking used to use this option more frequently; while
it is still supported, other options (such as using channel variables or
creation of a custom parkinglot) are supported. More importantly, conveying the
parkinglot information through a channel snapshot isn't terribly useful - it
is rarely (if ever) changed on a channel and some consumers of channel
snapshots, such as ARI, will never use the information.
(closes issue ASTERISK-21968)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This process also involved a large amount of rework regarding how to redial
the Parker when a channel leaves a parking lot due to timeout. An attended
transfer channel variable has been added to attended transfers to extensions
that will eventually park (but haven't at the time of transfer) as well.
This resolves one of the two BUGBUG comments remaining in res_parking.
(issues ASTERISK-21877)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2638/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The OneTouchRecord feature has historically been a toggle. This patch
adds the ability to make the OneTouchRecord hook optionally start/stop
recording only. If OneTouchRecord is already doing what is requested then
only the invoker hears the courtesy tone and/or start/stop recording
message.
The new feature is written so we could easily add explicit start/stop
recording DTMF hooks for Monitor and MixMonitor.
The majority of the changes in bridge_builtin_features.c is a refactoring
of the OneTouchRecord code (Monitor and MixMonitor versions) so it is easy
to direct the toggle/start/stop functionality.
Review: https://reviewboard.asterisk.org/r/2655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the first step in adding recording support to the
Asterisk REST Interface.
Recordings are stored in /var/spool/recording. Since recordings may be
destructive (overwriting existing files), the API rejects attempts to
escape the recording directory (avoiding issues if someone attempts to
record to ../../lib/sounds/greeting, for example).
(closes issue ASTERISK-21594)
(closes issue ASTERISK-21581)
Review: https://reviewboard.asterisk.org/r/2612/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393550 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The appropriate settings for the Stasis threadpool is very system
specific, depending upon both workload and system configuration.
This patch adds a stasis.conf file which can be used to configure the
key attributes of the threadpool for the Stasis message bus.
(closes issue ASTERISK-21280)
Review: https://reviewboard.asterisk.org/r/2651/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started with the simple idea of changing the /events data
model to be more sane. The original model would send out events like:
{ "stasis_start": { "args": [], "channel": { ... } } }
The event discriminator was the field name instead of being a value in
the object, due to limitations in how Swagger 1.1 could model objects.
While technically sufficient in communicating event information, it was
really difficult to deal with in terms of client side JSON handling.
This patch takes advantage of a proposed extension[1] to Swagger which
allows type variance through the use of a discriminator field. This had
a domino effect that made this a surprisingly large patch.
[1]: https://groups.google.com/d/msg/wordnik-api/EC3rGajE0os/ey_5dBI_jWcJ
In changing the models, I also had to change the swagger_model.py
processor so it can handle the type discriminator and subtyping. I took
that a big step forward, and using that information to generate an
ari_model module, which can validate a JSON object against the Swagger
model.
The REST and WebSocket generators were changed to take advantage of the
validators. If compiled with AST_DEVMODE enabled, JSON objects that
don't match their corresponding models will not be sent out. For REST
API calls, a 500 Internal Server response is sent. For WebSockets, the
invalid JSON message is replaced with an error message.
Since this took over about half of the job of the existing JSON
generators, and the .to_json virtual function on messages took over the
other half, I reluctantly removed the generators.
The validators turned up all sorts of errors and inconsistencies in our
data models, and the code. These were cleaned up, with checks in the
code generator avoid some of the consistency problems in the future.
* The model for a channel snapshot was trimmed down to match the
information sent via AMI. Many of the field being sent were not
useful in the general case.
* The model for a bridge snapshot was updated to be more consistent
with the other ARI models.
Another impact of introducing subtyping was that the swagger-codegen
documentation generator was insufficient (at least until it catches up
with Swagger 1.2). I wanted it to be easier to generate docs for the API
anyways, so I ported the wiki pages to use the Asterisk Swagger
generator. In the process, I was able to clean up many of the model
links, which would occasionally give inconsistent results on the wiki. I
also added error responses to the wiki docs, making the wiki
documentation more complete.
Finally, since Stasis-HTTP will now be named Asterisk REST Interface
(ARI), any new functions and files I created carry the ari_ prefix. I
changed a few stasis_http references to ari where it was non-intrusive
and made sense.
(closes issue ASTERISK-21885)
Review: https://reviewboard.asterisk.org/r/2639/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393529 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch moves the RESTful URL's around to more appropriate
locations for release.
The /stasis URL's are moved to /ari, since Asterisk REST Interface was
a more appropriate name than Stasis-HTTP. (Most of the code still has
stasis_http references, but they will be cleaned up after there are no
more outstanding branches that would have merge conflicts with such a
change).
A larger change was moving the ARI events WebSocket off of the shared
/ws URL to its permanent home on /ari/events. The Swagger code
generator was extended to handle "upgrade: websocket" and
"websocketProtocol:" attributes on an operation.
The WebSocket module was modified to better handle WebSocket servers
that have a single registered protocol handler. If a client
connections does not specify the Sec-WebSocket-Protocol header, and
the server has a single protocol handler registered, the WebSocket
server will go ahead and accept the client for that subprotocol.
(closes issue ASTERISK-21857)
Review: https://reviewboard.asterisk.org/r/2621/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I ended up using a bridge blob, so this structure was
unused. Keeping it in the header would just cause confusion.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If no matching endpoint is found for the incoming request Asterisk will respond
with a 401 Unauthorized (rejecting the request), but will first challenge if
no authorization creditials are given.
Changes also included moving ACL options into a new global 'security'
configuration section in res_sip.conf.
(closes issue ASTERISK-21433)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2554/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393442 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds several unit tests for CEL functionality and provides the
requisite framework for creating additional unit tests.
This also cleans up some reference leaks that were occurring in
Stasis-Core message callback code.
Review: https://reviewboard.asterisk.org/r/2646/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability to send unsolicited NOTIFY requests to a particular endpoint
with a configured payload. Added both CLI and AMI support. For a given
endpoint, this module will iterate over all its contacts sending the appropriate
NOTIFY request to each.
(closes issue ASTERISK-21436)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2623/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The originate APIs allow callers to provide a pointer to a channel that will
point to the originated channel if the function call succeeds. This is used by AMI
to provide channel information when the originate is performed synchronously.
Unfortunately, if the originate fails in certain ways, the outbound channel is
already disposed of during the dialing itself. This results in the channel being
improperly dereferenced by the internal originate function in pbx.c.
This patch ref bumps the channel to prevent this from occurring. Callers must now
unlock and unref the channel (which is more in line with general channel management
guidelines anyway).
This only affects manager, as it is the only consumer of this API function that
actually passes in a channel pointer.
Review: https://reviewboard.asterisk.org/r/2617/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In addition to porting those features, they now enjoy greater feature parity
with one another. Specifically, AutoMixMon now has a start and stop
message that can be specified with TOUCH_MIXMONITOR_MESSAGE_START and
TOUCH_MIXMONITOR_MESSAGE_STOP.
(closes issue ASTERISK-21553)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2620/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393309 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Things may no longer behave in an unexpected fashion. Local channel
optimization to holding bridges will work again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Parking typically occurs when a channel is transferred to a parking extension.
When this occurs, the channel never actually hits the dialplan if the extension
it was transferred to was a "parking extension", that is, the extension in
the first priority calls the Park application. Instead, the channel is
immediately sent into the holding bridge acting as the parking bridge.
This is problematic.
Because we never go out to the dialplan, the CDRs won't transition properly
and the application field will not be set to "Park". CDRs typically swallow
holding bridges, so the CDR itself won't even be generated.
This patch handles this by pulling out the holding bridge handling into its
own CDR state. CDRs now have an explicit parking state that accounts for this
specific subclass of the holding bridge. In addition, we handle the parking
stasis message to set application specific data on the CDR such that the
last known application for the CDR properly reflects "Park".
This is a bit sad since we're working around the odd internal implementation
of parking that exists in Asterisk (and that we had to maintain in order to
continue to meet some odd use cases of parking), but at least the code to
handle that is where it belongs: in CDRs as opposed to sprinkled liberally
throughout the codebase.
This patch also properly clears the OUTBOUND channel flag from a channel when
it leaves a bridge, and tweaks up dialing handling to properly compare the
correct CDR with the channel calling/being dialed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add config framework OPT_CHAR_ARRAY_T and OPT_STRINGFIELD_T non-empty
requirement option. There are cases were you don't want a config option
string to be empty. To require the option string to be non-empty, just
set the aco_option_register() flags parameter to non-zero.
* Updated some config framework enum aco_option_type comments.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a misunderstanding about ast_bridge_impart()'s handling of the
imparted channel's reference. The channel reference is passed by the
caller unless ast_bridge_impart() returns an error.
* Fixed a memory leak in conf_announce_channel_push() if the impart
failed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change removes AST_CEL_BRIDGE_UPDATE since it should no longer be
used because masquerade situations are now accounted for in other ways.
This also refactors usage of AST_CEL_FORWARD to be produced by a Dial
message which has been extended with a "forward" field.
(closes issue ASTERISK-21566)
Review: https://reviewboard.asterisk.org/r/2635/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds support for stasis/sounds and stasis/sounds/{ID} queries via
the Asterisk RESTful Interface (ARI, formerly Stasis-HTTP).
The following changes have been made to accomplish this:
* A modular indexer was created for local media.
* A new function to get an ast_format associated with a file extension
was added.
* Modifications were made to the built-in HTTP server so that URI
decoding could be deferred to the URI handler when necessary.
* The Stasis-HTTP sounds JSON documentation was modified to handle
cases where multiple languages are installed in different formats.
* Register and Unregister events for formats were added to the system
topic.
(closes issue ASTERISK-21584)
(closes issue ASTERISK-21585)
Review: https://reviewboard.asterisk.org/r/2507/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sorcery specific object information is now opaque and allocated with the object.
This means that modules do not need to be recompiled if the sorcery specific part
is changed. It also means that sorcery can store additional information on objects
and ensure it is freed or the reference count decreased when the object goes away.
To facilitate the above a generic sorcery allocator function has been added which
also ensures that allocated objects do not have a lock.
Extended fields have been added thanks to all of the above which allows specific fields
to be marked as extended, and thus simply stored as-is within the object. Type safety
is *NOT* enforced on these fields. A consumer of them has to query and ultimately perform
their own safety check. What does this mean? Extra modules can extend already defined
structures without having to modify them.
Tests have also been included to verify extended field functionality.
Review: https://reviewboard.asterisk.org/r/2585/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. Security events
2. Websocket support
3. Diversion header + redirecting support
4. An anonymous endpoint identifier
5. Inbound extension state subscription support
6. PIDF notify generation
7. One touch recording support (special thanks Sean Bright!)
8. Blind and attended transfer support
9. Automatic inbound registration expiration
10. SRTP support
11. Media offer control dialplan function
12. Connected line support
13. SendText() support
14. Qualify support
15. Inband DTMF detection
16. Call and pickup groups
17. Messaging support
Thanks everyone!
Side note: I'm reminded of the song "How Far We've Come" by Matchbox Twenty.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Extract a useful routine from the softmix bridge technology for other
technologies. Make other technologies use it if they can.
* Made native and 1-1 bridges write to all parties if the bridge channel
writing the frame into the bridge is NULL. Softmix will also do the same
for frame types that make sense.
* Tweak the bridge write routine return value meaning and adjust the
bridge technologies to match.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge frame queue functions need to return an error status if the
frame failed to be queued because of an error condition. The main calls
that needed to return the status are:
ast_bridge_channel_queue_action_data() and
ast_bridge_channel_write_action_data(). The other return changes are
ripple effects.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This finishes moving all CEL linkedid tracking entirely within cel.c
since that is now possible with channel snapshots.
This also removes another CEL linkedid manipulation function from cel.h
that has already been internalized and is neither called nor available
to link against.
Review: https://reviewboard.asterisk.org/r/2632/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While very handy, this macro didn't occur until a later version of libjansson.
We'd prefer to be compatible with older versions still - as such, iteration
over key/value pairs in a JSON object have to be done with a little bit more
manual work.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This pulls bridge-related CEL event triggers out of the code in which
they were residing and pulls them into cel.c where they are now
triggered by changes in bridge snapshots. To get access to the
Stasis-Core parking topic in cel.c, the Stasis-Core portions of parking
init have been pulled into core Asterisk init.
This also adds a new CEL event (AST_CEL_BRIDGE_TO_CONF) that indicates
a two-party bridge has transitioned to a multi-party conference. The
reverse cannot occur in CEL terms even though it may occur in actuality
and two party bridges which receive a AST_CEL_BRIDGE_TO_CONF will be
treated as multi-party conferences for the duration of the bridge.
Review: https://reviewboard.asterisk.org/r/2563/
(closes issue ASTERISK-21564)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses the channel state change events from Stasis-Core to determine
when channel-related CEL events should be raised. Those refactored in
this patch are:
* AST_CEL_CHANNEL_START
* AST_CEL_ANSWER
* AST_CEL_APP_START
* AST_CEL_APP_END
* AST_CEL_HANGUP
* AST_CEL_CHANNEL_END
Retirement of Linked IDs is also refactored.
CEL configuration has been refactored to use the config framework.
Note: Some HANGUP events are not generated correctly because the bridge
layer does not propagate hangupcause/hangupsource information yet.
Review: https://reviewboard.asterisk.org/r/2544/
(closes issue ASTERISK-21563)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391622 65c4cc65-6c06-0410-ace0-fbb531ad65f3