kenmirrors/asterisk
1
0
Fork 0
mirror of https://github.com/asterisk/asterisk.git synced 2025-09-04 20:04:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove early bridge BUGBUG comments. Remove some unneeded features.c comments.

Browse Source 
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is contained in:
Richard Mudgett
2013-08-15 19:14:43 +00:00
parent 0c44ee3be3
commit 58af87ef2c
2 changed files with 0 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
main/bridge_channel.c
View File

@@ -1689,8 +1689,6 @@ static void bridge_handle_trip(struct ast_bridge_channel *bridge_channel)
} }
/* Simply write the frame out to the bridge technology. */ /* 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); bridge_channel_write_frame(bridge_channel, frame);
ast_frfree(frame); ast_frfree(frame);
} }

53
main/features.c
View File

@@ -79,59 +79,6 @@ ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
#include "asterisk/stasis_channels.h" #include "asterisk/stasis_channels.h"
#include "asterisk/features_config.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 /*** DOCUMENTATION
<application name="Bridge" language="en_US"> <application name="Bridge" language="en_US">
<synopsis> <synopsis>