60 Commits (c922846c6da3f1d76e41a574842ad740bfec27a1)

Author	SHA1	Message	Date
Richard Mudgett	58af87ef2c	Remove early bridge BUGBUG comments. Remove some unneeded features.c comments. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396794 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	e35860f954	Changed some BUGBUG tags to associated JIRA issue tags. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396792 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	5f40a6625d	Fix Bridge API DTMF hook matching for begin and end DTMF events. ... The Bridge API DTMF hook matching would not deal with DTMF end events only. It required a DTMF begin event to start matching the DTMF hooks. There are many places in Asterisk where code only generates DTMF end events without the corresponding begin event. One such place is the AMI action Atxfer. * Fixed DTMF hook matching if there is a string of DTMF frames in the read queue. We could potentially miss some of them before. * Fixed AMI Atxfer action documentation. (closes issue ASTERISK-22037) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2752/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396732 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Matthew Jordan	63b5bf26ec	Fix two race conditions and ref counting issue when joining a bridge ... These problems were all caught by a test in the Asterisk Test Suite that originated some Local channels and attempted to move the ;2 half of the Local channel into a bridge using the Bridge AMI action. (1) When originating a channel, the Newchannel event is emitted quickly; however, the ;2 channel will not have a pbx thread assigned to it until after the outbound 'dialing' for the ;1 is complete. Thus, there is a period of time where the outside world "knows" of the channel's existence and can influence it but Asterisk has not yet started the dialplan execution thread. If a Bridge AMI action is taken on the channel, the channel appears to be a Dialed channel with no PBX thread; hence, the channel will be imparted into the Bridge by first 'yanking' the channel. At the same time, a race condition can occur after the yank (but before entering the bridge) when ;1 answers and starts a PBX on the ;2. The end result currently is an assertion failure in the Bridging API, as a channel with a PBX is imparted into the Bridge. There's no way to prevent AMI from attempting to Bridge a channel immediately after creation; likewise, holding the channel lock through the entire Dial operation is unwise (and impossible). Instead of treating the presence of a PBX thread as an error, we simply bail out of the adding the channel to the bridge through ast_bridge_impart. The Bridge action will then fail - but we avoid a situation where the channel is both executing a PBX thread and simultaneously being given a separate thread in the bridging system (which would be a "bad thing"). Since imparting a channel with a PBX *can* occur and is not a programming error, the asserts have been removed. (2) When the first condition occurs, we have to take one of two actions: either hangup the yanked channel as it did not enter the bridge, or deref it because we don't own it. We can determine if we own it or not by testing for the presence of the PBX thread. If we hung it up directly, we'd crash. (3) bridge_find_channel does not increase the reference count of the ast_bridge_channel object. The RAII_VAR usage in ast_bridge_add_channel thus created a ticking time bomb in whatever bridge the channel moved into, as the destructor for the ast_bridge_channel object would be called. Review: https://reviewboard.asterisk.org/r/2741/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396543 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	6fe21ef48e	bridge_channel: Support the lonely flag and make ARI use it. ... The lonely flag is an optional flag for bridge channels that will make them leave a bridge when a channel leaves if only lonely channels are in the bridge at that point. This is useful for things like ending recording and playback channels when they cease to be interacting with other channels in the bridge. (closes issue ASTERISK-22117) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2721/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396497 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
Matthew Jordan	5c4b482471	Support externally initiated parking requests; remove some dead code ... This patch does the following: * It adds support for externally initiated parking requests. In particular, chan_skinny has a protocol level message that initiates a call park. This patch now supports that option, as well as the protocol specific mechanisms in chan_dahdi/sig_analog and chan_mgcp. * A parking bridge features virtual table has been added that provides access to the parking functionality that the Bridging API needs. This includes requests to park an entire 'call' (with little or no additional information, thank you chan_skinny), perform a blind transfer to a parking extension, determine if an extension is a parking extension, as well as the actual "do the parking" request from the Bridging API. * Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new functions * The removal of some - but not all - dead parking code from features.c This also fixed blind transferring a multi-party bridge to a parking lot (which was implemented, but had at least one code path where using the parking features kK might not have worked) Review: https://reviewboard.asterisk.org/r/2710 (closes issue ASTERISK-22134) Reported by: Matt Jordan git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Richard Mudgett	c017d5e6a3	Remove the unsafe bridge parameter from ast_bridge_hook_callback's. ... Most hook callbacks did not need the bridge parameter. The pointer value could become invalid if the channel is moved to another bridge while it is executing. * Fixed some issues in feature_attended_transfer() as a result. * Reduce the bridge inhibit count in attended_transfer_properties_shutdown() after it has restored the bridge channel hooks. * Removed basic bridge requirement on feature_blind_transfer(). It does not require the basic bridge like feature_attended_transfer(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	9a46c1d019	Add name argument to BridgeWait() so multiple holding bridges may be used ... Changes arguments for BridgeWait from BridgeWait(role, options) to BridgeWait(bridge_name, role, options). Now multiple holding bridges may be created and referenced by this application. (closes issue ASTERISK-21922) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2642/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395509 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