asterisk

Commit Graph

Author	SHA1	Message	Date
Mark Michelson	b8b5d52b5e	ConfBridge: Rework announcer channel methodology NOTE: This patch was submitted earlier and reverted because of a failing test. The test has been patched so that it adjusts for the changes here, so this is being resubmitted for review. One feature that confbridge has is the ability to play sounds to all participants in the conference. Prior to this commit, the algorithm for this was as follows: * Grab the playback lock * Push the conference announcer channel into the bridge * Play back the sound * Pull the conference announcer channel from the bridge * Release the playback lock The issue here is that the act of adding the playback channel to the bridge and removing it for each announcement is expensive. Amongst the expenses: * The announcer channel is imparted into the bridge, meaning a new thread is spun up for each playback. * When the announcer is added or removed from the bridge, it results in the BRIDGEPEER channel variable being set on all channels in the bridge. This requires keeping the bridge locked and locking each individual channel in order to set it. * There's also just the general overhead of adding the channel and removing it from the bridge. The bridge potentially has to reconfigure every single time With this commit, the paradigm for playing back announcements has shifted. * The announcer channel is now added to the bridge when the conference is allocated, and it is hung up when the conference is destroyed. * A taskprocessor is used to queue playbacks onto the announcer channel. This keeps the behavior from before where playbacks do not overlap. * The announcer channel is no longer placed into the bridge as departable. Since we are not constantly removing the channel from the bridge, it is safe to add the channel using an independent thread and simply hang the channel up when it is time for the conference to be destroyed. The use of the taskprocessor for playbacks opens up the interesting possibility of having asynchronous announcements played. In this commit, however, the behavior is still exactly the same as it previously was. ASTERISK-26289 Reported by Mark Michelson Change-Id: Ica9fa4907c2f3728cdd1cf0bc564ef4eb40754a0	9 years ago
Joshua Colp	d5d7cbfcfb	Revert "ConfBridge: Rework announcer channel methodology" This reverts commit `0cdeb2bfb0`. Change-Id: I18ba73b6d4dc0b994f4ffb01ae0b6cfad36ac636	9 years ago
Mark Michelson	0cdeb2bfb0	ConfBridge: Rework announcer channel methodology One feature that confbridge has is the ability to play sounds to all participants in the conference. Prior to this commit, the algorithm for this was as follows: * Grab the playback lock * Push the conference announcer channel into the bridge * Play back the sound * Pull the conference announcer channel from the bridge * Release the playback lock The issue here is that the act of adding the playback channel to the bridge and removing it for each announcement is expensive. Amongst the expenses: * The announcer channel is imparted into the bridge, meaning a new thread is spun up for each playback. * When the announcer is added or removed from the bridge, it results in the BRIDGEPEER channel variable being set on all channels in the bridge. This requires keeping the bridge locked and locking each individual channel in order to set it. * There's also just the general overhead of adding the channel and removing it from the bridge. The bridge potentially has to reconfigure every single time With this commit, the paradigm for playing back announcements has shifted. * The announcer channel is now added to the bridge when the conference is allocated, and it is hung up when the conference is destroyed. * A taskprocessor is used to queue playbacks onto the announcer channel. This keeps the behavior from before where playbacks do not overlap. * The announcer channel is no longer placed into the bridge as departable. Since we are not constantly removing the channel from the bridge, it is safe to add the channel using an independent thread and simply hang the channel up when it is time for the conference to be destroyed. The use of the taskprocessor for playbacks opens up the interesting possibility of having asynchronous announcements played. In this commit, however, the behavior is still exactly the same as it previously was. ASTERISK-26289 Reported by Mark Michelson Change-Id: Ic5cd2c4b98a1eaa1715eb7a5b35d62f1a76d78a5	9 years ago
Richard Mudgett	1e93f3d723	Bridge system: Fix memory leaks and double frees on impart failure. You cannot reference the passed in features struct after calling ast_bridge_impart(). Even if the call fails. Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21	10 years ago
Richard Mudgett	1900bae7b6	app_confbridge: Add missing destructor call to announcer channel destructor. ........ Merged revisions 410671 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410672 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Scott Griepentrog	80ef9a21b9	uniqueid: channel linkedid, ami, ari object creation with id's Much needed was a way to assign id to objects on creation, and much change was necessary to accomplish it. Channel uniqueids and linkedids are split into separate string and creation time components without breaking linkedid propgation. This allowed the uniqueid to be specified by the user interface - and those values are now carried through to channel creation, adding the assignedids value to every function in the chain including the channel drivers. For local channels, the second channel can be specified or left to default to a ;2 suffix of first. In ARI, bridge, playback, and snoop objects can also be created with a specified uniqueid. Along the way, the args order to allocating channels was fixed in chan_mgcp and chan_gtalk, and linkedid is no longer lost as masquerade occurs. (closes issue ASTERISK-23120) Review: https://reviewboard.asterisk.org/r/3191/ ........ Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	2a371cd80b	Restore Dial, Queue, and FollowMe 'I' option support. The Dial, Queue, and FollowMe applications need to inhibit the bridging initial connected line exchange in order to support the 'I' option. * Replaced the pass_reference flag on ast_bridge_join() with a flags parameter to pass other flags defined by enum ast_bridge_join_flags. * Replaced the independent flag on ast_bridge_impart() with a flags parameter to pass other flags defined by enum ast_bridge_impart_flags. * Since the Dial, Queue, and FollowMe applications are now the only callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the calling contract to require the initial COLP exchange to already have been done by the caller. * Made all callers of ast_bridge_impart() check the return value. It is important. As a precaution, I also made the compiler complain now if it is not checked. * Did some cleanup in parking_tests.c as a result of checking the ast_bridge_impart() return value. An independent, but associated change is: * Reduce stack usage in ast_indicate_data() and add a dropping redundant connected line verbose message. (closes issue ASTERISK-22072) Reported by: Joshua Colp Review: https://reviewboard.asterisk.org/r/2845/ ........ Merged revisions 399136 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399138 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	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
Jonathan Rose	4f29b97020	app_confbridge: Eliminate a reference leak for confbridge announcer channels git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394583 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	a022379107	Fix incorrect calls to ast_bridge_impart(). There was a misunderstanding about ast_bridge_impart()'s handling of the imparted channel's reference. The channel reference is passed by the caller unless ast_bridge_impart() returns an error. * Fixed a memory leak in conf_announce_channel_push() if the impart failed. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392934 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 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	13 years ago

13 Commits (814d8a99d13f599436afe84808f426adca3aa79c)