36 Commits (9ede39700590629e60a7ae39e8c426c26b83dd6d)

Author	SHA1	Message	Date
Matthew Jordan	3d9c5e61af	Fix error in using ast_channel_snapshot_type before initialization ... Starting Asterisk would kick back an ERROR message stating that the Stasis message type ast_channel_snapshot_type was used prior to initialization. This occurred due to the caching topic being created prior to the message type that it depended on. This patch re-orders the start up such that the message type is initialized prior to the caching topic. It also checks the return value of the initialization of the agent login/logoff types. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397585 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	e47d3db365	Doxygen comment tweaks. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396857 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	f29d969a79	Stasis: address refcount races; implementation comments ... Change r395954 reordered some stasis object destruction, which should have been fine. Unfortunately, it caused some hard to reproduce issues related to objects being accessed after they had been destroyed. The patch in r396329 fixed the destruction order problem; this patch addresses the underlying issue. A few other stasis-related fixes were also added. * Add ref-bumps around areas where objects may get transitively destroyed. (For example, where we lock a topic, unref a subscription, which unrefs the topic, which explodes the topic when we try to unlock it.) * Wrote an extensive doxygen page about Stasis implementation, relationships between objects, lifecycles of objects, how the refcounting works, etc. Many other comments were added, corrected, or cleaned up. * Added an assert to the topic dtor to catch extra ref decrements. * Fixed type used after destruction errors for graceful shutdown in stasis_channels.c. * I added two unit tests in an attempt to catch destruction order issues. Since the underlying cause is a race condition, though, the tests rarely failed even when the code was wrong. * Fixed a leak in stasis_cache_pattern.c. (closes issue ASTERISK-22243) Review: https://reviewboard.asterisk.org/r/2746/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396842 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	03090a88ba	Fix documentation replication issues ... This prevents XML documentation duplication by expanding channel and bridge snapshot tags into channel and bridge snapshot parameter sets with a given prefix or defaulting to no prefix. This also prevents documentation from becoming fractured and out of date by keeping all variations of the documentation in template form such that it only needs to be updated once and keeps maintenance to a minimum. Review: https://reviewboard.asterisk.org/r/2708/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 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
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
Kinsey Moore	5a8f32703c	Filter channels used as internal mechanisms ... This adds new flags to the channel tech properties that flag it as different types of implementation detail used exclusively to provide a feature. Examples of channels that would have these flags include the announcement and recording channels used by confbridge which are the only two marked as such by this patch. Review: https://reviewboard.asterisk.org/r/2633/ (closes issue ASTERISK-21873) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394808 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	d43b17a872	Replace chan_agent with app_agent_pool. ... The ill conceived chan_agent is no more. It is now replaced by app_agent_pool. Agents login using the AgentLogin() application as before. The AgentLogin() application no longer does any authentication. Authentication is now the responsibility of the dialplan. (Besides, the authentication done by chan_agent did not match what the voice prompts asked for.) Sample extensions.conf [login] ; Sample agent 1001 login ; Set COLP for in between calls so the agent does not see the last caller COLP. exten => 1001,1,Set(CONNECTEDLINE(all)="Agent Waiting" <1001>) ; Give the agent DTMF transfer and disconnect features when connected to a caller. same => n,Set(CHANNEL(dtmf-features)=TX) same => n,AgentLogin(1001) same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS}) same => n,Hangup() [caller] ; Sample caller direct connect to agent 1001 exten => 800,1,AgentRequest(1001) same => n,NoOp(AGENT_STATUS is ${AGENT_STATUS}) same => n,Hangup() ; Sample caller going through a Queue to agent 1001 exten => 900,1,Queue(agent_q) same => n,Hangup() Sample queues.conf [agent_q] member => Local/800@caller,,SuperAgent,Agent:1001 Under the hood operation overview: 1) Logged in agents wait for callers in an agents holding bridge. 2) Caller requests an agent using AgentRequest() 3) A basic bridge is created, the agent is notified, and caller joins the basic bridge to wait for the agent. 4) The agent is either automatically connected to the caller or must ack the call to connect. 5) The agent is moved from the agents holding bridge to the basic bridge. 6) The agent and caller talk. 7) The connection is ended by either party. 8) The agent goes back to the agents holding bridge. To avoid some locking issues with the agent holding bridge, I needed to make some changes to the after bridge callback support. The after bridge callback is now a list of requested callbacks with the last to be added the only active callback. The after bridge callback for failed callbacks will always happen in the channel thread when the channel leaves the bridging system or is destroyed. (closes issue ASTERISK-21554) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2657/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394417 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	7c044acbd9	Refactor operations to access the stasis cache instead of objects directly when retrieving information. ... (closes issue ASTERISK-21883) Review: https://reviewboard.asterisk.org/r/2645/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393831 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	b193c2873d	Handle hangup logic in the Stasis message bus and consumers of Stasis messages ... 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	12 years ago
Matthew Jordan	4123b27f6f	Remove parkinglot from the channel snapshot ... 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	13 years ago
Richard Mudgett	02f55a36a0	Revert accidental overcommit. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393632 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	b4e9a3fc2f	Add BUGBUG note for ASTERISK-22009 ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393631 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	c9a3d4562d	Update events to use Swagger 1.3 subtyping, and related aftermath ... 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	13 years ago
Kinsey Moore	a1e219ef51	CEL refactoring cleanup ... 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	13 years ago
Matthew Jordan	6258bbe7bd	Update Asterisk's CDRs for the new bridging framework ... 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	13 years ago
Kinsey Moore	4f84e48028	Refactor CEL channel events on top of Stasis-Core ... 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	13 years ago
Matthew Jordan	41e4282751	Fix memory leaks in stasis_channels and bridge_native_rtp ... This patch fixes two memory leaks: * A memory leak in packing channels into a multi-channel blob payload when publishing dial messages. The multi-channel blob payload does not steal the references - this approach was chosen because it works well with the RAII_VAR macro. Unfortunately, this does mean that you actually have to use the RAII_VAR macro (or manually deref it yourself) * RTP instances returned as a result of one of the glue operations are ref counted and have to be de-ref'd appropriately. We now do that, as saying that we should do it and then not would be silly. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391479 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	dbdb2b1b3a	Add vtable and methods for to_json and to_ami for Stasis messages ... When a Stasis message type is defined in a loadable module, handling those messages for AMI and res_stasis events can be cumbersome. This patch adds a vtable to stasis_message_type, with to_ami and to_json virtual functions. These allow messages to be handled abstractly without putting module-specific code in core. As an example, the VarSet AMI event was refactored to use the to_ami virtual function. (closes issue ASTERISK-21817) Review: https://reviewboard.asterisk.org/r/2579/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391403 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	759a7e4a30	Rework stasis cache clear events ... Stasis cache clear message payloads now consist of a stasis_message representative of the message to be cleared from the cache. This allows multiple parallel caches to coexist and be cleared properly by the same cache clear message even when keyed on different fields. This change fixes a bug where multiple cache clears could be posted for channels. The cache clear is now produced in the destructor instead of ast_hangup. Additionally, dummy channels are no longer capable of producing channel snapshots. Review: https://reviewboard.asterisk.org/r/2596 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390830 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	1458a20e47	Refactor code and fix a reference leak ... Refactor some channel blob publishing code to use ast_channel_publish_blob now that it is available and fix a JSON reference leak that was occurring during varset publishing. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390317 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	ccc8cc5346	Fixup hold/unhold with attended and blind transfers. ... * DTMF attended and blind transfers have hold/unhold behavior restored. * External attended and blind transfers unhold the transfered party when the transfer is initiated. * Made prohibit blind transferring a bridge marked as masquerade only. (ConfBridge bridges) * Made running an application or playing a file inside a bridge post the hold/unhold messages if MOH is requested. Review: https://reviewboard.asterisk.org/r/2574/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390289 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	e1bff7958a	Add snapshot cache that indexes by channel name ... This adds a new channel snapshot cache in parallel to the existing cache; the difference being that it indexes the channel snapshots by channel name instead of channel uniqueid. Review: https://reviewboard.asterisk.org/r/2576 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390249 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	d81c846724	Avoid unnecessary cleanups during immediate shutdown ... This patch addresses issues during immediate shutdowns, where modules are not unloaded, but Asterisk atexit handlers are run. In the typical case, this usually isn't a big deal. But the introduction of the Stasis message bus makes it much more likely for asynchronous activity to be happening off in some thread during shutdown. During an immediate shutdown, Asterisk skips unloading modules. But while it is processing the atexit handlers, there is a window of time where some of the core message types have been cleaned up, but the message bus is still running. Specifically, it's still running module subscriptions that might be using the core message types. If a message is received by that subscription in that window, it will attempt to use a message type that has been cleaned up. To solve this problem, this patch introduces ast_register_cleanup(). This function operates identically to ast_register_atexit(), except that cleanup calls are not invoked on an immediate shutdown. All of the core message type and topic cleanup was moved from atexit handlers to cleanup handlers. This ensures that core type and topic cleanup only happens if the modules that used them are first unloaded. This patch also changes the ast_assert() when accessing a cleaned up or uninitialized message type to an error log message. Message type functions are actually NULL safe across the board, so the assert was a bit heavy handed. Especially for anyone with DO_CRASH enabled. Review: https://reviewboard.asterisk.org/r/2562/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390122 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	6851801a5e	Resolve a merge conflict ... When ast_channel_cached_blob_create was merged, ast_channel_blob_create_from_cache was partially removed in an unresolved merge conflict. This restores ast_channel_blob_create_from_cache and refactors usage of ast_channel_cached_blob_create (requires an ast_channel) to use ast_channel_blob_create_from_cache (requires a channel uniqueid) instead. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389974 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Jason Parker	154fbf8cae	Split Hold event into Hold/Unhold, and move it into core. ... (closes issue ASTERISK-21487) Review: https://reviewboard.asterisk.org/r/2565/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389746 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	06be8463b6	Migrate a large number of AMI events over to Stasis-Core ... This patch moves a number of AMI events over to the Stasis-Core message bus. This includes: * ChanSpyStart/Stop * MonitorStart/Stop * MusicOnHoldStart/Stop * FullyBooted/Reload * All Voicemail/MWI related events In addition, it adds some Stasis-Core and AMI support for generic AMI messages, refactors the message router in AMI to use a single router with topic forwarding for the topics that AMI cares about, and refactors MWI message types and topics to be more name compliant. Review: https://reviewboard.asterisk.org/r/2532 (closes issue ASTERISK-21462) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389733 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 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	13 years ago
David M. Lee	e1e1cc2dee	Fixed some extra field assertion when the event WebSocket is connected ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389343 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	b97c71bb11	Fix shutdown assertions in stasis-core ... In r388005, macros were introduced to consistently define message types. This added an assert if a message type was used either before it was initialized or after it had been cleaned up. It turns out that this assertion fires during shutdown. This actually exposed a hidden shutdown ordering problem. Since unsubscribing is asynchronous, it's possible that the message types used by the subscription could be freed before the final message of the subscription was processed. This patch adds stasis_subscription_join(), which blocks until the last message has been processed by the subscription. Since joining was most commonly done right after an unsubscribe, a stasis_unsubscribe_and_join() convenience function was also added. Similar functions were also added to the stasis_caching_topic and stasis_message_router, since they wrap subscriptions and have similar problems. Other code in trunk was refactored to join() where appropriate, or at least verify that the subscription was complete before being destroyed. Review: https://reviewboard.asterisk.org/r/2540 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	d04f1fd60a	Publish the outbound channel's application/data when dialing ... This patch does two things: * It fixes a bug where the outbound channel's application/data set by the dialing API/app_dial is not communicated until the channel is hung up. If that happens, AMI would incorrectly send a NewExten event immediately after a Hangup. This isn't really AMI's fault, as the dialing APIs never communicated the 'helpful' app/data on the outbound channel until it was hungup. * It makes public sending a stasis message about a change in channel state. This is useful enough that - for now at least - it should be public. If operations on a channel go to being more coarse-grained, this function could be made private again. Review: https://reviewboard.asterisk.org/r/2548 Note that this problem was found and reported by Matt DiMeo. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388976 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Kinsey Moore	7ce05bfb9b	Add channel events for res_stasis apps ... This change adds a framework in res_stasis for handling events from channel topics. JSON event generation and validation code is created from event documentation in rest-api/api-docs/events.json to assist in JSON event generation, ensure consistency, and ensure that accurate documentation is available for ALL events that are received by res_stasis applications. The userevent application has been refactored along with the code that handles userevent channel blob events to pass the headers as key/value pairs in the JSON blob. As a side-effect, app_userevent now handles duplicate keys by overwriting the previous value. Review: https://reviewboard.asterisk.org/r/2428/ (closes issue ASTERISK-21180) Patch-By: Kinsey Moore <kmoore@digium.com> git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388275 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	0eb4cf8c19	Remove required type field from channel blobs ... When we first introduced the channel blob types, the JSON blobs were self identifying by a required "type" field in the JSON object itself. This, as it turns out, was a bad idea. When we introduced the message router, it was useless for routing based on the JSON type. And messages had two type fields to check: the stasis_message_type() of the message itself, plus the type field in the JSON blob (but only if it was a blob message). This patch corrects that mistake by removing the required type field from JSON blobs, and introducing first class stasis_message_type objects for the actual message type. Since we now will have a proliferation of message types, I introduced a few macros to help reduce the amount of boilerplate necessary to set them up. Review: https://reviewboard.asterisk.org/r/2509 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	c599aca553	Moved core logic from app_stasis to res_stasis ... After some discussion on asterisk-dev, it was decided that the bulk of the logic in app_stasis actually belongs in a resource module instead of the application module. This patch does that, leaves the app specific stuff in app_stasis, and fixes up everything else to be consistent with that change. * Renamed test_app_stasis to test_res_stasis * Renamed app_stasis.h to stasis_app.h * This is still stasis application support, even though it's no longer in an app_ module. The name should never have been tied to the type of module, anyways. * Now that json isn't a resource module anymore, moved the ast_channel_snapshot_to_json function to main/stasis_channels.c, where it makes more sense. Review: https://reviewboard.asterisk.org/r/2430/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
David M. Lee	ff7ecd3dbf	Fixed manager channelvars support. ... For the events that have been ported to Stasis, this was broken in r384910, when a couple of lines of code was lost in a merge. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385236 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Matthew Jordan	b8d4e573f1	Add multi-channel Stasis messages; refactor Dial AMI events to Stasis ... This patch does the following: * A new Stasis payload has been defined for multi-channel messages. This payload can store multiple ast_channel_snapshot objects along with a single JSON blob. The payload object itself is opaque; the snapshots are stored in a container keyed by roles. APIs have been provided to query for and retrieve the snapshots from the payload object. * The Dial AMI events have been refactored onto Stasis. This includes dial messages in app_dial, as well as the core dialing framework. The AMI events have been modified to send out a DialBegin/DialEnd events, as opposed to the subevent type that was previously used. * Stasis messages, types, and other objects related to channels have been placed in their own file, stasis_channels. Unit tests for some of these objects/messages have also been written. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384910 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago