[asterisk-commits] mmichelson: branch group/CCSS r217318 - /team/group/CCSS/main/ccss.c

[SVN commits to the Asterisk project]

Author: mmichelson
Date: Tue Sep  8 17:29:50 2009
New Revision: 217318

URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=217318
Log:
Map a plan of attack for the agent callback function.

I've got some exciting work ahead :)


Modified:
    team/group/CCSS/main/ccss.c

Modified: team/group/CCSS/main/ccss.c
URL: http://svn.asterisk.org/svn-view/asterisk/team/group/CCSS/main/ccss.c?view=diff&rev=217318&r1=217317&r2=217318
==============================================================================
--- team/group/CCSS/main/ccss.c (original)
+++ team/group/CCSS/main/ccss.c Tue Sep  8 17:29:50 2009
@@ -795,7 +795,58 @@
 
 static int cc_generic_agent_recall(struct ast_cc_agent *agent)
 {
-	/* STUB */
+	/* Let's map this out
+	 *
+	 * What should this function actually DO? This function needs
+	 * to place a call to agent->interface. Upon answering the call,
+	 * a pbx needs to be started and the topmost extension monitor
+	 * in the monitor graph should be where the pbx starts.
+	 *
+	 * That's simple enough, but there are two things which complicate
+	 * matters.
+	 *
+	 * 1) When the PBX is started, there needs to be a magic CC_INTERFACES
+	 * channel variable which contains the proper interfaces to dial at
+	 * each step. This includes Dials which call local channels which then
+	 * dial more devices. My thinking on this matter is that we can re-use
+	 * the pending offer used for the caller. This will require some changes
+	 * to how pending offers currently work. I think one way that might work
+	 * would be to unlink the pending offer from the container of pending
+	 * offers like we currently do when CC is requested by the caller, BUT also
+	 * let the core_instance (or perhaps the agent) gain a reference to the
+	 * pending offer so it is not freed. In fact, I think that giving the
+	 * agent a reference to the pending offer is the best idea since we could
+	 * have centralized code in the core for setting the CC_INTERFACES variable.
+	 * The other tricky part of this is that the interface dialed initially is
+	 * not going to be the same as was originally dialed. The answer to this
+	 * is to create a monitor callback to retrieve a specific dial string to
+	 * use given a device name and a core_id.
+	 *
+	 * Another idea regarding the pending offers is just to not have a container
+	 * of them. Since the pending offer, agent, and core instance are all created
+	 * around the same time, it would probably be sufficient to just give the
+	 * agent a reference to the pending offer when everything gets created. Wow, what
+	 * a great idea.
+	 *
+	 * 2) This function is called from the core state machine processing thread, meaning
+	 * that it will block all state change requests. Some amount of asyncronicity needs
+	 * to be used here. Sure, I could make use of ast_pbx_outgoing_exten, but it has problems.
+	 * 		a) It still *mostly* runs synchronously. The portion where the caller is called
+	 * 		back will run in this thread. We can't afford for that sort of delay.
+	 * 		b) We need to be able to set the CC_INTERFACES variable on the channel we create.
+	 * 		Or we need to attach the pending offer as a datastore. Either way, the channel
+	 * 		structure is completely hidden from us if we use outgoing_exten.
+	 * Yeah, so I can't make use of the typical "origination" function. I also considered using
+	 * the dialing API, but that is no good either since it completely hides the ast_channel
+	 * from view.
+	 *
+	 * So, my plan is to create a new thread immediately. Inside that thread, I'll call
+	 * ast_request_and_dial to request a channel and dial the channel. IF the channel answers, I
+	 * will first run the callback_macro, then set the CC_INTERFACES as necessary, and then start
+	 * a PBX.
+	 *
+	 * Phew!
+	 */
 	return 0;
 }