28 Commits (66c46fba24ccfa782339e3ef2722ea53b5573d17)

Author	SHA1	Message	Date
Matthew Jordan	66c46fba24	CDRs: fix a variety of dial status problems, h/hangup handler creating CDRs ... This patch fixes a number of small-ish problems that were noticed when witnessing the records that the FreePBX dialplan produces: (1) Mid-call events (as well as privacy options) have the ability to change the overall state of the Dial operation after the called party answers. This means that publishing the DialEnd event when the called party is premature; we have to wait for the execution of these subroutines to complete before we can signal the overall status of the DialEnd. This patch moves that publication and adds handlers for the mid-call events. (2) The AST_FLAG_OUTGOING channel flag is cleared if an after bridge goto datastore is detected. This flag was preventing CDRs from being recorded for all outbound channels that had a 'continue' option enabled on them by the Dial application. (3) The CDR engine now locks the 'Dial' application as being the CDR application if it detects that the current CDR has entered that app. This is similar to the logic that is done for Parking. In general, if we entered into Dial, then we want that CDR to record the application as such - this prevents pre-dial handlers, mid-call handlers, and other shenaniganry from changing the application value. (4) The CDR engine now checks for the AST_SOFTHANGUP_HANGUP_EXEC in more places to determine if the channel is in hangup logic or dead. In either case, we don't want to record changes in the channel. (5) The default option for "endbeforehexten" has been changed to "yes". In general, you don't want to see CDRs in the 'h' exten or in hangup logic. Since the semantics of that option changed in 12, it made sense to update the default value as well. (6) Finally, because we now have the ability to synchronize on the messages published to the CDR topic, on shutdown the CDR engine will now synchronize to the messages currently in flight. This helps to ensure that all in-flight CDRs are written before shutting down. (closes issue ASTERISK-23164) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/3154 ........ Merged revisions 407084 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407085 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 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
Matthew Jordan	33e7b76d1d	Hide the Surrogate channels from external consumers; kill Masquerade events ... This patch does three things: 1. It provides a Surrogate channel technology with a consolidated "implementation detail flag" on the channel technology. This tells consumers of Stasis that the creation of this channel is an implementation detail in Asterisk and can be ignored (if they so choose). This consolidates the conference recorder/announcer flags as well - these flags had no additional meaning beyond "ignore this channel please". 2. It modifies allocation of a channel in two ways: (a) If a channel technology can be determined from the name, we set it directly in the allocation routine. This prevents the initial publication of the message from going out with a NULL channel technology where possible. This lets Stasis consumers get the right channel technology on the first publication. (b) It reorganizes allocation to make use of the 'finalized' property on the channel. This was already used to know that a channel had completely finished its construction in the masquerade routine; now we also use it to know whether or not the setting of certain channel properties is occurring during or post construction. The various set routines were modified accordingly as well. 3. The masquerade event is now dead, Jim. It no longer served any purpose whatsoever - if you perform a call pickup you'll get a Pickup event; if you perform an attended transfer you will still get those events; if you steal a channel to put it elsewhere you'll get the corresponding NewExten or BridgeEnter events. Review: https://reviewboard.asterisk.org/r/2740 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396392 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
David M. Lee	fec667646f	Fix bridge/channel AMI event ordering issues ... The stasis_cache_update messages are somewhat cumbersome to handle with the stasis_message_router. Since all updates have the same message type, they are normally handled with the same route. Since caching itself is a first class component of stasis-core, it makes sense for the router to handle the cache update messages itself. This patch adds stasis_message_router_add_cache_update() and stasis_message_router_remove_cache_update() to handle the routing of stasis_cache_update messages. This patch also corrects an issue with manager_{bridging,channels}.c, where events might be reordered. The reordering occurs because the components use different message routers, which they needed because they both needed to route cache update messages. They now both use manager's router, and add cache routes for just the cache updates they are interested in. (closes issue ASTERISK-22038) Review: https://reviewboard.asterisk.org/r/2677/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395118 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
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	50d81a58e8	Prevent sending a NewExten event after a Hangup during a stack restore ... When a channel is originated, its application is typically set to AppDial2, indicating that it was a dialed channel through the Dial API. Asterisk during an originate will perform a stack execute to direct the outgoing channel to a particular place in the dialplan or application. When the stack returns, the previous application (AppDial2) is restored. Unfortunately, in the case of an originated channel, the stack restore happens after hangup. A stasis message is sent notifying everyone that the application was restored, and this causes a NewExten event to go out after the Hangup event, violating the basic contract consumers have of the channel lifetime. While we could preclude the message from going out, restoring the channel's state before it executed the next higher frame in the stack has to occur, and other places in the code depend on this behavior. Since we know that channel hung up (it's a ZOMBIE!), this patch simply checks to see if the channel has been zombified before sending a NewExten event. Note that this will fix a number of bouncing tests in the Test Suite. Go tests. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392005 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 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	12 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	12 years ago
David M. Lee	a36d38ab38	Fixed refcounting problems with chanspy AMI support. ... The ast_multi_channel_blob_get_channel function does not bump the refcount on the channel snapshot that it returns. This is typical for Stasis message payloads, since being immutable means that the object won't get unreffed out from underneath you. The manager code for chanspy was unreffing the snapshots it got out of the multi-channel blob, which was one unref too many. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390584 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 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	12 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	12 years ago
Richard Mudgett	3d63833bd6	Merge in the bridge_construction branch to make the system use the Bridging API. ... Breaks many things until they can be reworked. A partial list: chan_agent chan_dahdi, chan_misdn, chan_iax2 native bridging app_queue COLP updates DTMF attended transfers Protocol attended transfers git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Joshua Colp	4e38a4eb64	Move origination to use the dialing API and send Stasis messages on dial begin and end. ... (closes issue ASTERISK-21549) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2512/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389053 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 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	12 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	12 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	12 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	12 years ago
David M. Lee	2450722f52	DTMF events are now published on a channel's stasis_topic. AMI was ... refactored to use these events rather than producing the events directly in channel.c. Finally, the code was added to app_stasis to produce DTMF events on the WebSocket. The AMI events are completely backward compatible, including sending events on transmitted DTMF, and sending DTMF start events. The Stasis-HTTP events are somewhat simplified. Since DTMF start and DTMF send events are generally less useful, Stasis-HTTP will only send events on received DTMF end. (closes issue ASTERISK-21282) (closes issue ASTERISK-21359) Review: https://reviewboard.asterisk.org/r/2439 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385734 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	7f885dc31d	Expose channel snapshot manager blob generation ... These functions are already used in one branch (jrose's parking branch) and will soon be used in other branches as well. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385522 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 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	12 years ago
Kinsey Moore	71206544a7	Break the world. Stasis message type accessors should now all be named correctly. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384261 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Kinsey Moore	f073c27b60	Fix typo ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383754 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	4a6237b231	Move NewCallerid, HangupRequest and SoftHangupRequest to Stasis ... HangupRequest and SoftHangupRequest are now ast_channel_blob Stasis messages, with the cause code as an optional field in the blob. NewCallerid now simply watches for changes in the callerid information in channel snapshots, and creates the AMI event appropriately. Since the original NewCallerid event honored the channelvars setting in manager.conf, the channel variables configured there had to become a part of the channel snapshot. These are now a part of every snapshot based event, making the configuration description "every time a channel-oriented event is emitted" less of a lie. There a a few other changes wrapped up in here as well. * When ast_channel_topic() is given NULL for a channel, it returns the ast_channel_topic_all() topic instead of NULL. This can clean up a lot of NULL checking we're doing currently. * The fields Cause and Cause-txt were removed from the base channel information and put only on the Hangup events, since those fields are meaningless outside of a Hangup event. * Removed the pipe-delimiter processing of the channelvars field, since that's been deprecated forever. (closes issue ASTERISK-21096) Review: https://reviewboard.asterisk.org/r/2405/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383726 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
David M. Lee	cf9324b25e	Move more channel events to Stasis; move res_json.c to main/json.c. ... This patch started out simply as fixing the bouncing tests introduced in r382685, but required some other changes to give it a decent implementation. To fix the bouncing tests, the UserEvent and Newexten AMI events needed to be refactored to dispatch via Stasis. Dispatching directly to AMI resulted in those events sometimes getting ahead of the associated Newchannel events, which would understandably confuse anyone. I found that instead of creating a zillion different message types and structures associated with them, it would be preferable to define a message type that has a channel snapshot and a blob of structured data with a small bit of additional information. The JSON object model provides a very nice way of representing structured data, so I went with that. * Move JSON support from res_json.c to main/json.c * Made libjansson-dev a required dependency * Added an ast_channel_blob message type, which has a channel snapshot and JSON blob of data. * Changed UserEvent and Newexten events so that they are dispatched via ast_channel_blob messages on the channel's topic. * Got rid of the ast_channel_varset message; used ast_channel_blob instead. * Extracted the manager functions converting Stasis channel events to AMI events into manager_channel.c. (issue ASTERISK-21096) Review: https://reviewboard.asterisk.org/r/2381/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383579 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago