diff options
author | Richard Mudgett <rmudgett@digium.com> | 2013-08-15 19:14:43 +0000 |
---|---|---|
committer | Richard Mudgett <rmudgett@digium.com> | 2013-08-15 19:14:43 +0000 |
commit | 58af87ef2ce5c8854c95914296e15a9fc6d939af (patch) | |
tree | d92b52eb745a606d37f377dd6787b57c76acb965 | |
parent | 0c44ee3be33093f2398d0486899fe22daab16e34 (diff) |
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
-rw-r--r-- | main/bridge_channel.c | 2 | ||||
-rw-r--r-- | main/features.c | 53 |
2 files changed, 0 insertions, 55 deletions
diff --git a/main/bridge_channel.c b/main/bridge_channel.c index bb49c0d1c..32d48309b 100644 --- a/main/bridge_channel.c +++ b/main/bridge_channel.c @@ -1689,8 +1689,6 @@ static void bridge_handle_trip(struct ast_bridge_channel *bridge_channel) } /* Simply write the frame out to the bridge technology. */ -/* BUGBUG The tech is where AST_CONTROL_ANSWER hook should go. (early bridge) */ -/* BUGBUG The tech is where incoming BUSY/CONGESTION hangup should happen? (early bridge) */ bridge_channel_write_frame(bridge_channel, frame); ast_frfree(frame); } diff --git a/main/features.c b/main/features.c index 7c53451fa..d4ecf657e 100644 --- a/main/features.c +++ b/main/features.c @@ -79,59 +79,6 @@ ASTERISK_FILE_VERSION(__FILE__, "$Revision$") #include "asterisk/stasis_channels.h" #include "asterisk/features_config.h" -/* BUGBUG TEST_FRAMEWORK is disabled because parking tests no longer work. */ -#undef TEST_FRAMEWORK - -/* - * Party A - transferee - * Party B - transferer - * Party C - target of transfer - * - * DTMF attended transfer works within the channel bridge. - * Unfortunately, when either party A or B in the channel bridge - * hangs up, that channel is not completely hung up until the - * transfer completes. This is a real problem depending upon - * the channel technology involved. - * - * For chan_dahdi, the channel is crippled until the hangup is - * complete. Either the channel is not useable (analog) or the - * protocol disconnect messages are held up (PRI/BRI/SS7) and - * the media is not released. - * - * For chan_sip, a call limit of one is going to block that - * endpoint from any further calls until the hangup is complete. - * - * For party A this is a minor problem. The party A channel - * will only be in this condition while party B is dialing and - * when party B and C are conferring. The conversation between - * party B and C is expected to be a short one. Party B is - * either asking a question of party C or announcing party A. - * Also party A does not have much incentive to hangup at this - * point. - * - * For party B this can be a major problem during a blonde - * transfer. (A blonde transfer is our term for an attended - * transfer that is converted into a blind transfer. :)) Party - * B could be the operator. When party B hangs up, he assumes - * that he is out of the original call entirely. The party B - * channel will be in this condition while party C is ringing, - * while attempting to recall party B, and while waiting between - * call attempts. - * - * WARNING: - * The ATXFER_NULL_TECH conditional is a hack to fix the - * problem. It will replace the party B channel technology with - * a NULL channel driver. The consequences of this code is that - * the 'h' extension will not be able to access any channel - * technology specific information like SIP statistics for the - * call. - * - * Uncomment the ATXFER_NULL_TECH define below to replace the - * party B channel technology in the channel bridge to complete - * hanging up the channel technology. - */ -//#define ATXFER_NULL_TECH 1 - /*** DOCUMENTATION <application name="Bridge" language="en_US"> <synopsis> |