Author: derek Date: Wed Jun 13 22:36:35 2007 New Revision: 325 Modified: sofaswitch/trunk/callflow/docs/chap1.sgml sofaswitch/trunk/callflow/docs/chap2.sgml Log: More updates. Get ulink to work. Add more cross references. Modified: sofaswitch/trunk/callflow/docs/chap1.sgml ============================================================================== --- sofaswitch/trunk/callflow/docs/chap1.sgml (original) +++ sofaswitch/trunk/callflow/docs/chap1.sgml Wed Jun 13 22:36:35 2007 @@ -87,11 +87,15 @@ handled call into a separate Python thread. </para> <para> We therefore base this code around -<ulink URL="http://twistedmatrix.com/trac"></ulink> an event driven network -framework written in Python. Using Twisted solved the handling of the any -number of asynchronous events.. Further, we could have one psuedo thread per -call, but in reality there is one thread in operation. One psuedo thread per -call makes things much simpler to analyse. </para> +<ulink url="http://twistedmatrix.com/trac">Twisted</ulink>, an event driven +network framework written in Python. Using <ulink +url="http://twistedmatrix.com/trac">Twisted</ulink> solved the handling of the +any number of asynchronous events.. From a users point of view, we have one +thread per call and graph management is simplified. The reality is that there +are two Python threads in operation, one to do <ulink +url="http://twistedmatrix.com/trac">Twisted</ulink>, and one to execute the +graphs. +</para> <para>The Python code will process the items on the graph, until it reaches the end of the current graph. Execution then waits for a event to happen, Modified: sofaswitch/trunk/callflow/docs/chap2.sgml ============================================================================== --- sofaswitch/trunk/callflow/docs/chap2.sgml (original) +++ sofaswitch/trunk/callflow/docs/chap2.sgml Wed Jun 13 22:36:35 2007 @@ -11,8 +11,10 @@ One should remember that each graph is designed to handle one call. Events are posted to each graph, that are relevant to each call. Multiple calls can be handled simultaneously by spawning off graphs with the aid of the -<literal>Load New Graph</literal> widget. Thus, on receiving notification of an -incoming call, one would spawn of a <literal>Load New Graph</literal>, which is +<literal>Load New Graph</literal> widget +(section <xref endterm="LoadNewGraph" linkend="LoadNewGraphSec"/>). +For example then, on receiving notification of an +incoming call, one would spawn of a new graph which is designed to handle that particular incoming call. </para> @@ -138,8 +140,9 @@ </para> <para> While processing each of the nodes in the supplied graph, it is -ignoring all timer events. Execution continues until it is suspended -(section <xref endterm="SuspendProcessing" linkend="SuspendProcessingSec"/>). +ignoring all timer events. When the for loop has been completed, execution is +terminated. The termination control object is explained elsewhere (section +<xref endterm="TerminateProcessing" linkend="TerminateProcessingSec"/>). Once execution has been suspended, the system will process pending events. </para> @@ -170,14 +173,15 @@ register to receive any event that contains the word "NEW" (we are searching for all events advising of a new node). At which point, execution continues to the right, and goes into the lower "execute Python code" box, which prints a -message. Finally, execution moves into the bottom most box, and is suspended. +message. Finally, execution moves into the bottom most box, and is suspended +(<xref endterm="SuspendProcessing" linkend="SuspendProcessingSec"/>) </para> <para> -At this point, we rely upon the twisted module in Python to call methods +At this point, we rely upon the <ulink url="http://twistedmatrix.com/trac">Twisted</ulink> module in Python to call methods indicating that things have happened (e.g. a timer, data received from network -etc). On receipt of a message about a new node, execution is moved to the box -on the star output of the eventer box. Thus, the left Python code box is +etc). On receipt of a message about a new node, execution is moved to the +star output of the eventer box. Thus, the left Python code box is executed, which (in this case) reports the id of the voip node created. Execution then moves to the skull and cross bones and terminates. </para> @@ -234,11 +238,19 @@ Key to the operation of &sofaswitch; is the ability to move audio from one entity to another. This audio passes directly betweeen entities, and does not go via the server. The &sofaswitch; entities themselves worry about the -transport of the data. The trivial example in figure <xref xrefstyle="select: +transport of the data. Since the audio data does not go via the control +circuits, the control system is not burdened by attempting to handle the +packets in real time. Further, should the control system abnormally terminate, +the current calls will continue. +</para> + +<para> +The trivial example in figure <xref xrefstyle="select: labelnumber" linkend="trivialtransferexample"/> shows the transfer of audio from the sound entity back to the sound entity. Consequently, audio that is captured at the mic will be directed to the speaker. The sound entity has -therefore been told to talk to itself. +therefore been told to talk to itself. Further details on audio transfer are +found in section <xref endterm="TransferAudio" linkend="TransferAudioSec"/>. <figure id="trivialtransferexample"> <title>Trivial example of the transfer of audio</title> <mediaobject>