asterisk

Commit Graph

Author	SHA1	Message	Date
Joshua Colp	e5899852cc	res_stasis: Enable transfers and provide events when they occur. This change enables transfers within ARI created bridges and adds events for when they occur. Unlike other events these will be received if any subscribed object is involved in the transfer. (closes issue ASTERISK-22984) Reported by: David M. Lee Review: https://reviewboard.asterisk.org/r/3120/ ........ Merged revisions 407153 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407154 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	3a5cc054ed	res_stasis: Expose event for call forwarding and follow forwarded channel. 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	12 years ago
Kevin Harwell	ed48377994	ARI: Implement device state API 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	12 years ago
Kinsey Moore	d9015a5356	ARI: Don't leak implementation details 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	12 years ago
David M. Lee	069da1e75a	stasis: add functions embarrassingly missing from r400522 I neglected to implement two of the endpoint subscription functions when I did the work. Normally, you'll only hit that when you unsubscribe from a specific endpoint. ........ Merged revisions 402276 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402277 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	7eea4ab872	You'd think that new files would be free of whitespace issues. But you would be wrong. ........ Merged revisions 402003 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402004 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	8d7873b836	ARI: Add subscription support This patch adds an /applications API to ARI, allowing explicit management of Stasis applications. * GET /applications - list current applications * GET /applications/{applicationName} - get details of a specific application * POST /applications/{applicationName}/subscription - explicitly subscribe to a channel, bridge or endpoint * DELETE /applications/{applicationName}/subscription - explicitly unsubscribe from a channel, bridge or endpoint Subscriptions work by a reference counting mechanism: if you subscript to an event source X number of times, you must unsubscribe X number of times to stop receiveing events for that event source. Review: https://reviewboard.asterisk.org/r/2862 (issue ASTERISK-22451) Reported by: Matt Jordan ........ Merged revisions 400522 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400523 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
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
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	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
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
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	13 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	13 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	13 years ago

15 Commits (5247a0d99078ecc0a108aba5ac24570f6f082f46)