asterisk

Commit Graph

Author	SHA1	Message	Date
Richard Mudgett	3f724fa493	Make bridge snapshots use prefixes. * Changed ast_manager_build_bridge_state_string() to assume an empty prefix string just like ast_manager_build_channel_state_string(). * Created ast_manager_build_bridge_state_string_prefix() to work just like ast_manager_build_channel_state_string_prefix(). * Made BridgeMerge AMI event use To/From prefixes. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396417 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
Matthew Jordan	2977846f0a	Don't unsubscribe from the AMI message router from manager_bridges The AMI message router is owned wholly by manager.c. Previously, each of the manager_{item} source files had their own message router and they unsubscribed from each; once they moved over to using a single message router only a single unsubscribe became necessary. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396158 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	328e99f41d	Make a couple of changes to help AMI events to be more clear in what is occurring. * BridgeEnter now contains the unique ID of the channel that is to be swapped out, if applicable. * There is a ParkedCallSwap event that is sent when a parked channel has a new channel take its place. (closes issue ASTERISK-22193) reported by Mark Michelson Review: https://reviewboard.asterisk.org/r/2712 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396107 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	56a90d435c	Fix incorrect reference to stasis/bridging.h git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395381 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

8 Commits (b7ec25ec2e98e5e4bb26edacb855602541e30b7f)