[asterisk-commits] mmichelson: branch mmichelson/atxfer_features r392052 - /team/mmichelson/atxf...
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Mon Jun 17 13:11:05 CDT 2013
Author: mmichelson
Date: Mon Jun 17 13:11:04 2013
New Revision: 392052
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=392052
Log:
Adds, in comments, a rough outline of a state machine for attended transfers.
There are some details omitted from the states, but as a reference, it does a good
enough job to guide me. Now to actually implement the thing...
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=392052&r1=392051&r2=392052
==============================================================================
--- team/mmichelson/atxfer_features/main/bridging_basic.c (original)
+++ team/mmichelson/atxfer_features/main/bridging_basic.c Mon Jun 17 13:11:04 2013
@@ -410,6 +410,252 @@
}
/*! \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 asterisk-commits
mailing list