[asterisk-commits] rmudgett: trunk r396794 - in /trunk/main: bridge_channel.c features.c

[SVN commits to the Asterisk project]

Author: rmudgett
Date: Thu Aug 15 14:14:43 2013
New Revision: 396794

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=396794
Log:
Remove early bridge BUGBUG comments.  Remove some unneeded features.c comments.

Modified:
    trunk/main/bridge_channel.c
    trunk/main/features.c

Modified: trunk/main/bridge_channel.c
URL: http://svnview.digium.com/svn/asterisk/trunk/main/bridge_channel.c?view=diff&rev=396794&r1=396793&r2=396794
==============================================================================
--- trunk/main/bridge_channel.c (original)
+++ trunk/main/bridge_channel.c Thu Aug 15 14:14:43 2013
@@ -1689,8 +1689,6 @@
 	}
 
 	/* 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);
 }

Modified: trunk/main/features.c
URL: http://svnview.digium.com/svn/asterisk/trunk/main/features.c?view=diff&rev=396794&r1=396793&r2=396794
==============================================================================
--- trunk/main/features.c (original)
+++ trunk/main/features.c Thu Aug 15 14:14:43 2013
@@ -78,59 +78,6 @@
 #include "asterisk/stasis.h"
 #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">