126 Commits (f821e8107180e7c49c00c16ae8f998e12b51e79a)

Author	SHA1	Message	Date
David M. Lee	2de42c2a25	Multiple revisions 399887,400138,400178,400180-400181 ... ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines Optimize how Stasis forwards are dispatched This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines Remove dispatch object allocation from Stasis publishing While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	2a371cd80b	Restore Dial, Queue, and FollowMe 'I' option support. ... The Dial, Queue, and FollowMe applications need to inhibit the bridging initial connected line exchange in order to support the 'I' option. * Replaced the pass_reference flag on ast_bridge_join() with a flags parameter to pass other flags defined by enum ast_bridge_join_flags. * Replaced the independent flag on ast_bridge_impart() with a flags parameter to pass other flags defined by enum ast_bridge_impart_flags. * Since the Dial, Queue, and FollowMe applications are now the only callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the calling contract to require the initial COLP exchange to already have been done by the caller. * Made all callers of ast_bridge_impart() check the return value. It is important. As a precaution, I also made the compiler complain now if it is not checked. * Did some cleanup in parking_tests.c as a result of checking the ast_bridge_impart() return value. An independent, but associated change is: * Reduce stack usage in ast_indicate_data() and add a dropping redundant connected line verbose message. (closes issue ASTERISK-22072) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/2845/ ........ Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	53dbe10f5c	Fix build warnings ... When AST_DEVMODE is not defined, ast_asserts are not compiled into the binary. In some cases, this means variables are not referenced or are set but unused which causes warnings to show up. (closes issue ASTERISK-22446) Reported by: Jason Parker (qwell) ........ Merged revisions 398521 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398522 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	451993f4f5	ARI: WebSocket event cleanup ... Stasis events (which get distributed over the ARI WebSocket) are created by subscribing to the channel_all_cached and bridge_all_cached topics, filtering out events for channels/bridges currently subscribed to. There are two issues with that. First was a race condition, where messages in-flight to the master subscribe-to-all-things topic would get sent out, even though the events happened before the channel was put into Stasis. Secondly, as the number of channels and bridges grow in the system, the work spent filtering messages becomes excessive. Since r395954, individual channels and bridges have caching topics, and can be subscribed to individually. This patch takes advantage, so that channels and bridges are subscribed to on demand, instead of filtering the global topics. The one case where filtering is still required is handling BridgeMerge messages, which are published directly to the bridge_all topic. Other than the change to how subscriptions work, this patch mostly just moves code around. Most of the work generating JSON objects from messages was moved to .to_json handlers on the message types. The callback functions handling app subscriptions were moved from res_stasis (b/c they were global to the model) to stasis/app.c (b/c they are local to the app now). (closes issue ASTERISK-21969) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2754/ ........ Merged revisions 397816 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397820 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	7a581537e8	ARI: Correct error codes for bridge operations ... This patch adds error checking to ARI bridge operations, when adding/removing channels to/from bridges. In general, the error codes fall out as follows: * Bridge not found - 404 Not Found * Bridge not in Stasis - 409 Conflict * Channel not found - 400 Bad Request * Channel not in Stasis - 422 Unprocessable Entity * Channel not in this bridge (on remove) - 422 Unprocessable Entity (closes issue ASTERISK-22036) Review: https://reviewboard.asterisk.org/r/2769/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397565 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	f5cca5e41e	res_stasis: remove call to missing function control_continue. ... In the shuffling around of res_stasis, control_continue was renamed to stasis_app_control_continue, but the call in res_stasis wasn't updated. In looking into it, it turns out it wasn't really the right thing to do in res_stasis anyways. This patch changes the handling of received a AST_CONTROL_HANGUP frame to be the same as receiving a NULL frame, and removed the declaration of control_continue(), since it doesn't exist any more. (closes issue ASTERISK-22292) Reported by: Denis Smirnov git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397295 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	987fdfb444	ARI: allow other operations to happen while bridged ... This patch changes ARI bridging to allow other channel operations to happen while the channel is bridged. ARI channel operations are designed to queue up and execute sequentially. This meant, though, that while a channel was bridged, any other channel operations would queue up and execute only after the channel left the bridge. This patch changes ARI bridging so that channel commands can execute while the channel is bridged. For most operations, things simply work as expected. The one thing that ended up being a bit odd is recording. The current recording implementation will fail when one attempts to record a channel that's in a bridge. Note that the bridge itself may be recording; it's recording a specific channel in the bridge that fails. While this is an annoying limitation, channel recording is still very useful for use cases such as voice mail, and bridge recording makes up much of the difference for other use cases. (closes issue ASTERISK-22084) Review: https://reviewboard.asterisk.org/r/2726/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396568 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	e47794ead1	ARI: bridges/{bridgeID}/addChannel: add roles parameter ... Roles are now cleared with each entry into a bridge with addChannel. If the roles parameter is present, the role specified will be applied to all channels being added with the addChannel command. (closes issue ASTERISK-21973) Reported by: Matt Jordan https://reviewboard.asterisk.org/r/2691/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396182 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	38236e54a8	Remove dead code from features.c; refactor pickup code into pickup.c ... This patch does the following: * It moves the pickup code out of features.c and into pickup.c * It removes the vast majority of dead code out of features.c. In particular, this includes the parking code. (issue ASTERISK-22134) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	e1b959ccbb	Split caching out from the stasis_caching_topic. ... In working with res_stasis, I discovered a significant limitation to the current structure of stasis_caching_topics: you cannot subscribe to cache updates for a single channel/bridge/endpoint/etc. To address this, this patch splits the cache away from the stasis_caching_topic, making it a first class object. The stasis_cache object is shared amongst individual stasis_caching_topics that are created per channel/endpoint/etc. These are still forwarded to global whatever_all_cached topics, so their use from most of the code does not change. In making these changes, I noticed that we frequently used a similar pattern for bridges, endpoints and channels: single_topic ----------------> all_topic ^ | single_topic_cached ----+----> all_topic_cached | +----> cache This pattern was extracted as the 'Stasis Caching Pattern', defined in stasis_caching_pattern.h. This avoids a lot of duplicate code between the different domain objects. Since the cache is now disassociated from its upstream caching topics, this also necessitated a change to how the 'guaranteed' flag worked for retrieving from a cache. The code for handling the caching guarantee was extracted into a 'stasis_topic_wait' function, which works for any stasis_topic. (closes issue ASTERISK-22002) Review: https://reviewboard.asterisk.org/r/2672/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	b6f9b39830	Fix /stasis/res/app_replaced unit test. ... A typo in recent changes caused the JSON ApplicationReplaced message to fail to build, so the message wasn't being sent out the WebSocket. Related, the replaced application would also unregister itself when it disconnected, which would actually unregister the new application. This was also fixed. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395527 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	cafc115896	A great big renaming patch ... This patch renames the bridging* files to bridge*. This may seem pedantic and silly, but it fits better in line with current Asterisk naming conventions: * channel is not "channeling" * monitor is not "monitoring" etc. A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is the act of using a bridge on a set of channels - and the API that fulfills that role is more than just the action. (closes issue ASTERISK-22130) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	f6a227a451	Continue events when ARI WebSocket reconnects ... This patch addresses a bug in the /ari/events WebSocket in handling reconnects. When a Stasis application's associated WebSocket was disconnected and reconnected, it would not receive events for any channels or bridges it was subscribed to. The fix was to lazily clean up Stasis application registrations, instead of removing them as soon as the WebSocket goes away. When an application is unregistered at the WebSocket level, the underlying application is simply deactivated. If the application WebSocket is reconnected, the application is reactivated for the new connection. To avoid memory leaks from lingering, unused application, the application list is cleaned up whenever new applications are registered/unregistered. (closes issue ASTERISK-21970) Review: https://reviewboard.asterisk.org/r/2678/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395120 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	a6329a3acf	ARI: MOH start and stop for a channel ... (issue ASTERISK-21974) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2680/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394810 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	17c546173f	ARI: Bridge Playback, Bridge Record ... Adds a new channel driver for creating channels for specific purposes in bridges, primarily to act as either recorders or announcers. Adds ARI commands for playing announcements to ever participant in a bridge as well as for recording a bridge. This patch also includes some documentation/reponse fixes to related ARI models such as playback controls. (closes issue ASTERISK-21592) Reported by: Matt Jordan (closes issue ASTERISK-21593) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2670/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394809 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jason Parker	c1a7567d24	ARI: Add support for suppressing media streams. ... Also convert res_mutestream to use the core feature behind this. (closes issue ASTERISK-21618) Review: https://reviewboard.asterisk.org/r/2652/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394715 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	7ee5b025f4	Fix building. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393807 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jason Parker	87973eecff	ARI: Add support for getting/setting channel and global variables. ... This allows for reading and writing of functions on channels. (closes issue ASTERISK-21868) Review: https://reviewboard.asterisk.org/r/2641/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393806 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jason Parker	f820d24db1	ARI: Implement channel hold/unhold. ... This puts the channel on hold (rather than queueing a frame from the channel). (closes issue ASTERISK-21619) Review: https://reviewboard.asterisk.org/r/2647/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393332 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jason Parker	f41faf0b7d	ARI: Implement channel dial. ... This creates a new outbound channel, and bridges it to a channel already in the Stasis application. (closes issue ASTERISK-21620) Review: https://reviewboard.asterisk.org/r/2634/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393326 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jason Parker	609c42c854	ARI: Add support for continuing to a different location in dialplan. ... This allows going elsewhere in the dialplan, so that the location can be specified after exiting the Stasis application. (closes issue ASTERISK-21870) Review: https://reviewboard.asterisk.org/r/2644/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392987 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	a5bbc790e7	Stasis-HTTP: Flesh out bridge-related capabilities ... This adds support for Stasis applications to receive bridge-related messages when the application shows interest in a given bridge. To supplement this work and test it, this also adds support for the following bridge-related Stasis-HTTP functionality: * GET stasis/bridges * GET stasis/bridges/{bridgeId} * POST stasis/bridges * DELETE stasis/bridges/{bridgeId} * POST stasis/bridges/{bridgeId}/addChannel * POST stasis/bridges/{bridgeId}/removeChannel Review: https://reviewboard.asterisk.org/r/2572/ (closes issue ASTERISK-21711) (closes issue ASTERISK-21621) (closes issue ASTERISK-21622) (closes issue ASTERISK-21623) (closes issue ASTERISK-21624) (closes issue ASTERISK-21625) (closes issue ASTERISK-21626) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391199 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	557125664d	This patch adds support for controlling a playback operation from the ... Asterisk REST interface. This adds the /playback/{playbackId}/control resource, which may be POSTed to to pause, unpause, reverse, forward or restart the media playback. Attempts to control a playback that is not currently playing will either return a 404 Not Found (because the playback object no longer exists) or a 409 Conflict (because the playback object is still in the queue to be played). This patch also adds skipms and offsetms parameters to the /channels/{channelId}/play resource. (closes issue ASTERISK-21587) Review: https://reviewboard.asterisk.org/r/2559 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389603 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	10ba6bf8a8	This patch implements the REST API's for POST /channels/{channelId}/play ... and GET /playback/{playbackId}. This allows an external application to initiate playback of a sound on a channel while the channel is in the Stasis application. /play commands are issued asynchronously, and return immediately with the URL of the associated /playback resource. Playback commands queue up, playing in succession. The /playback resource shows the state of a playback operation as enqueued, playing or complete. (Although the operation will only be in the 'complete' state for a very short time, since it is almost immediately freed up). (closes issue ASTERISK-21283) (closes issue ASTERISK-21586) Review: https://reviewboard.asterisk.org/r/2531/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389587 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	15945a7185	Fixed inverted logic in app_add_channel(). ... Also added some missing doc comments for stasis/app.h. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388896 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	e8f4ac6c61	Break res_stasis into smaller files. ... When implementing playback for stasis-http, the monolithicedness of res_stasis really started to get in my way. This patch breaks the major components of res_stasis.c into individual files. * res/stasis/app.c - Stasis application tracking * res/stasis/control.c - Channel control objects * res/stasis/command.c - Channel command object This refactoring also allows res_stasis applications to be loaded as independent modules, such as the new res_stasis_answer module. The bulk of this patch is simply moving code from one file to another, adjusting names and adding accessors as necessary. Review: https://reviewboard.asterisk.org/r/2530/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388729 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago