[svn-commits] mmichelson: branch mmichelson/atxfer_features r392796 - /team/mmichelson/atxf...
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Mon Jun 24 18:46:52 CDT 2013
Author: mmichelson
Date: Mon Jun 24 18:46:50 2013
New Revision: 392796
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=392796
Log:
Remove giant state machine explanation.
It's getting in the way more than anything now and its descriptions
are a bit dated. A proper explanation will be added to the state definitions
themselves.
Modified:
team/mmichelson/atxfer_features/main/bridging_basic.c
Modified: team/mmichelson/atxfer_features/main/bridging_basic.c
URL: http://svnview.digium.com/svn/asterisk/team/mmichelson/atxfer_features/main/bridging_basic.c?view=diff&rev=392796&r1=392795&r2=392796
==============================================================================
--- team/mmichelson/atxfer_features/main/bridging_basic.c (original)
+++ team/mmichelson/atxfer_features/main/bridging_basic.c Mon Jun 24 18:46:50 2013
@@ -1121,253 +1121,7 @@
ast_channel_set_bridge_role_option(chan, TRANSFERER_ROLE_NAME, "swap", swap);
}
-
/*! \brief Internal built in feature for attended transfers */
-
-/*!
- * XXX The grand idea for attended transfers:
- *
- * Attended transfers currently work in a way that has the feature block until some conclusion can be
- * reached. While this works for basic operaiton, it becomes unworkable when trying to have advanced features
- * such as automatically re-calling the transferer or allowing for the transferer to switch between bridges.
- * Instead, this feature code will be changed to set the transfer in motion and launch a separate thread to
- * oversee the progress and take appropriate action.
- *
- * As a precursor to the actual operations being performed here, there are two new "personalities" being
- * added for basic bridges. The first is the "transferee bridge", which is applied to the original bridge between
- * the transferer and transferee(s). The second is the "transfer target bridge", which is applied to the bridge
- * between the transferer and the transfer target. Both bridges will have pull methods that mainly check the
- * count of channels in the bridge.
- *
- * The following will be done in the feature_attended_transfer DTMF hook:
- * 1) Change the bridge's (bridge A) personality to be a "transferee bridge"
- * 2) Change the transferer channel's (party B) role to be the "transferer" (Doing so will establish transferer DTMF and hangup hooks)
- * 3) Establish a new bridge (bridge C) with the personality of "transfer target bridge"
- * 4) Request an outgoing channel to the transfer target (party C)
- * 5) Place a framehook onto party C (?)
- * 6) Place party C into bridge C
- * 7) If everything has been successful up to this point, then create a monitoring thread for the transfer.
- * 8) Place an outgoing call to party C
- * 9) Return
- *
- * The monitoring thread created in step 7 sleeps until something stimulates it to awaken. The things that can
- * stimulate it are the following:
- * 1) Bridge A becomes empty (or party B is the only party remaining in bridge A) - triggered by Bridge A's pull callback
- * 2) Bridge C becomes empty (or party B is the only party remaining in bridge C) - triggered by Bridge C's pull callback
- * 3) Party B issues a transferer menu command - triggered by DTMF hooks
- * 4) Party B hangs up - triggered by hangup hook
- * 5) Party C answers - triggered either by frame hook or potentially bridge write
- * 6) The atxfernoanswer timeout expires.
- *
- * When any of these stimuli happen, the hook or callback in question will poke the monitoring thread. The monitoring thread
- * will, based on the stimulus, examine the relevant state of the parties (taking into account the current state of the
- * attended transfer) and take appropriate action.
- *
- * So let's examine the monitor thread more closely. The monitor thread will initially start in the CALLING_TARGET state.
- *
- * State: CALLING_TARGET
- * Definition -
- * * Bridge A is still intact
- * * Bridge C is still intact
- * * Party C's channel is either in RING or RINGING state
- * * Party B is UP and is in Bridge A
- *
- * Actions upon entering: Place party B into Bridge C
- *
- * Stimuli during CALLING_TARGET state:
- * 1) Bridge A becomes empty: Transition to FAILED state
- * 2) Party B is only remaining party in Bridge C: Transition to REBRIDGE state
- * 3) Party B issues "atxfer_abort" command: Transition to REBRIDGE state
- * 4) Party B issues "atxfer_complete" command: Transition to BLOND state
- * 5) Party B issues "atxfer_threeway" command: Transition to THREEWAY state
- * 6) Party B issues "atxfer_swap" command: Transition to HESITANT state
- * 7) Party B hangs up: Transition to BLOND state
- * 8) Party C answers: Transition to CONSULTING state
- * 9) Time expires: Transition to REBRIDGE state
- *
- * State: HESITANT
- * Definition -
- * * Bridge A is still intact
- * * Bridge C is still intact
- * * Party C's channel is either in RING or RINGING state
- * * Party B is UP and in Bridge C
- *
- * Actions upon entering: Place party B into Bridge A
- *
- * Stimuli during HESITANT state:
- * 1) Party B is only remaining party in Bridge A: Transition to FAILED state
- * 2) Bridge C becomes empty: Transition to RESUME state
- * 3) Party B issues "atxfer_abort" command: Transition to RESUME state
- * 4) Party B issues "atxfer_complete" command: Transition to BLOND state
- * 5) Party B issues "atxfer_threeway" command: Transition to THREEWAY state
- * 6) Party B issues "atxfer_swap" command: Transition to CALLING_TARGET state
- * 7) Party B hangs up: Transition to BLOND state
- * 8) Party C answers: Transition to DOUBLECHECKING state
- * 9) Time expires: Transition to RESUME state
- *
- * State: REBRIDGE
- * Definition -
- * * Bridge A is still intact
- * * Bridge C is intact but may be empty
- * * Party C's channel is either hung up, RING, RINGING, or UP
- * * Party B is UP and in Bridge C
- *
- * Actions upon entering:
- * * If party C is not already hung up, then hang it up.
- * * Move party B into bridge A.
- * * Destroy bridge C.
- * * Remove transferer role from party B.
- * * Change bridge A's personality back to "basic".
- * * End monitoring thread.
- *
- * This is a final state, so there are no transitions from it.
- *
- * State: RESUME
- * Definition -
- * * Bridge A is still intact
- * * Bridge C is intact but may be empty
- * * Party C's channel is either hung up, RING, RINGING, or UP
- * * Party B is UP and in BRIDGE A
- *
- * Actions upon entering:
- * * If party C is not already hung up, then hang it up.
- * * Destroy bridge C.
- * * Remove transferer role from party B.
- * * Change bridge A's personality back to "basic".
- * * End monitoring thread.
- *
- * This is a final state, so there are no transitions from it.
- *
- * State: THREEWAY
- * Definition -
- * * Bridge A is still intact
- * * Bridge C is intact
- * * Party C's channel is either RING, RINGING, or UP
- * * Party B is UP and in either Bridge A or Bridge C
- *
- * Actions upon entering:
- * * Merge Bridge C into Bridge A
- * * Remove transferer role from party B.
- * * Change bridge A's personality back to "basic".
- * * End monitoring thread.
- *
- * This is a final state, so there are no transitions from it.
- *
- * State: CONSULTING
- * Definition -
- * * Bridge A is still intact
- * * Bridge C is intact
- * * Party C's channel is UP
- * * Party B is UP and in Bridge C
- *
- * Actions upon entering: Set timeout to infinity
- *
- * Stimuli:
- * Bridge A becomes empty: ?????????
- * Party B is the only remaining party in Bridge C: Transition to REBRIDGE state
- * Party B issues "atxfer_abort" command: Transition to REBRIDGE state
- * Party B issues "atxfer_complete" command: Transition to COMPLETE state
- * Party B issues "atxfer_threeway" command: Transition to THREEWAY state
- * Party B issues "atxfer_swap" command: Transition to DOUBLECHECKING state
- * Party B hangs up: Transition to COMPLETE state
- *
- * State: DOUBLECHECKING
- * Definition -
- * * Bridge A is intact
- * * Bridge C is intact
- * * Party C's channel is UP
- * * Party B is UP and in Bridge A
- *
- * Actions upon entering: Set timeout to infinity
- *
- * Stimuli:
- * Party B is the only party remaining in Bridge A: Transition to FAIL state
- * Bridge C becomes empty: Transition to RESUME state
- * Party B issues "atxfer_abort" command: Transition to RESUME state
- * Party B issues "atxfer_complete" command: Transition to COMPLETE state
- * Party B issues "atxfer_threeway" command: Transition to THREEWAY state
- * Party B issues "atxfer_swap" command: Transition to CONSULTING state
- * Party B hangs up: Transition to COMPLETE state
- *
- * State: COMPLETE
- * Definition -
- * * Bridge A is intact
- * * Bridge C is intact
- * * Party B is either UP or has hung up
- * * Party C's channel is UP
- * * Party B is in either Bridge A or Bridge C if still up
- *
- * Actions upon entering:
- * * Merge Bridge C into Bridge A, kicking party B out.
- * * Remove the transferer role from party B.
- * * Change bridge A's personality back to "basic".
- * * End monitoring thread.
- *
- * This is a final state, so there are no transitions from it.
- *
- * State: BLOND
- * Definition -
- * * Bridge A is intact
- * * Bridge C is intact
- * * Party B is either UP or has hung up
- * * Party C's channel is RING or RINGING
- * * Party B is in either Bridge A or Bridge C if still up
- *
- * Actions upon entering:
- * * Merge Bridge C into Bridge A, kicking party B out.
- * * Remove the transferer role from party B.
- *
- * Stimuli:
- * * Party C is the only remaining channel in the bridge: Transition to FAIL state
- * * Party C leaves the bridge: Transition to RECALLING state
- * * Time expires: Transition to RECALLING state
- *
- * State: RECALLING
- * Definition -
- * * Bridge A is intact
- * * Bridge C is dissolved
- * * Parties B and C are hung up
- *
- * Actions upon entering:
- * * Check atxferdropcall setting. If true, transition to FAIL.
- * * Request a channel for party B.
- * * Place party B into Bridge A.
- * * Place an outgoing call to party B.
- *
- * Stimuli:
- * * Party B is the only remaining party in the Bridge: transition to FAIL.
- * * Party B answers: transition to RESUME.
- * * Time expires: transition to RETRANSFER
- *
- * State: RETRANSFER
- * Definition -
- * * Bridge A is intact
- * * Bridge C is dissolved
- * * Parties B and C are hung up
- *
- * Actions upon entering:
- * * Increment counter for number of times RETRANSFER has been entered
- * * If counter >= atxfercallbackretries, transition to FAIL
- * * Request a channel for party C.
- * * Create a new Bridge C with "transfer target" personality.
- * * Place party C into Bridge C.
- * * Place an outgoing call to party C.
- * * Transition to BLOND.
- *
- * State: FAIL
- * Definition -
- * * Bridge A is intact
- * * Bridge C may be dissolved or intact
- * * Party B may be UP or hung up
- * * Party C may be RING, RINGING, UP, or hung up
- * * Party B may be in either Bridge A or Bridge C
- *
- * Actions upon entering:
- * * Remove transferer role from party B
- * * Hang up all involved parties
- * * Destroy all bridges
- * * End monitoring thread
- */
static int feature_attended_transfer(struct ast_bridge *bridge, struct ast_bridge_channel *bridge_channel, void *hook_pvt)
{
char exten[AST_MAX_EXTENSION] = "";
More information about the svn-commits
mailing list