asterisk

Commit Graph

Author	SHA1	Message	Date
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
David M. Lee	4666079b05	Address unload order issues for res_stasis* modules I've noticed when doing a graceful shutdown that the res_stasis_http.so module gets unloaded before the modules that use it, which causes some asserts during their unload. While r386928 was a quick hack to get it to not assert and die, this patch increases the use counts on res_stasis.so and res_stasis_http.so properly. It's a bigger change than I expected, hence the review instead of just committing it. Review: https://reviewboard.asterisk.org/r/2489/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388350 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	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	13 years ago
David M. Lee	0cc9528f9d	Backported app_stasis fix from stasis-http branch. The hash and compare functions for the control container was reusing the wrong ones, causing some problems. I fixed it, but in the wrong branch. Oh well, it happens. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385116 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
David M. Lee	a2a53cc306	Stasis application WebSocket support This is the API that binds the Stasis dialplan application to external Stasis applications. It also adds the beginnings of WebSocket application support. This module registers a dialplan function named Stasis, which is used to put a channel into the named Stasis app. As a channel enters and leaves the Stasis diaplan application, the Stasis app receives a 'stasis-start' and 'stasis-end' events. Stasis apps register themselves using the stasis_app_register and stasis_app_unregister functions. Messages are sent to an application using stasis_app_send. Finally, Stasis apps control channels through the use of the stasis_app_control object, and the family of stasis_app_control_* functions. Other changes along for the ride are: * An ast_frame_dtor function that's RAII_VAR safe * Some common JSON encoders for name/number, timeval, and context/extension/priority Review: https://reviewboard.asterisk.org/r/2361/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384879 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago

7 Commits (cc06020f23fd175061a65a36c8b6809feca0cc18)