[asterisk-commits] mmichelson: branch group/CCSS r222223 - /team/group/CCSS/doc/tex/ccss.tex

Tue Oct 6 10:51:19 CDT 2009

Author: mmichelson
Date: Tue Oct  6 10:51:16 2009
New Revision: 222223

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=222223
Log:
Fix some tex issues, clean up some grammar, and
add a point I forgot yesterday.


Modified:
    team/group/CCSS/doc/tex/ccss.tex

Modified: team/group/CCSS/doc/tex/ccss.tex
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/doc/tex/ccss.tex?view=diff&rev=222223&r1=222222&r2=222223
==============================================================================

--- team/group/CCSS/doc/tex/ccss.tex (original)
+++ team/group/CCSS/doc/tex/ccss.tex Tue Oct  6 10:51:16 2009
@@ -6,7 +6,7 @@
 which administrators may come across during their deployment of the
 feature.
 
-\section{What is CCSS\?}
+\section{What is CCSS?}
 
 	Call Completion Supplementary Services (often abbreviated "CCSS" or
 simply "CC") allow for a caller to let Asterisk automatically alert him
@@ -27,48 +27,50 @@
 clarification. Most of these terms are specific to Asterisk, and are by
 no means standard.
 
-CCBS: Call Completion on Busy Subscriber. When a call fails because the
+begin{itemize}
+\item CCBS: Call Completion on Busy Subscriber. When a call fails because the
 recipient's phone is busy, the caller will have the opportunity to
 request CCBS. When the recipient's phone is no longer busy, the caller
 will be alerted. The means by which the caller is alerted is dependent
 upon the type of agent used  by the caller.
 
-CCNR: Call Completion on No Response. When a call fails because the
+\item CCNR: Call Completion on No Response. When a call fails because the
 recipient does not answer the phone, the caller will have the opportun-
 ity to request CCNR. When the recipient's phone becomes busy and then
 is no longer busy, the caller will be alerted. The means by which the
 caller is alerted is dependent upon the type of the agent used by the
 caller.
 
-Agent: The agent is the entity within Asterisk that communicates with
+\item Agent: The agent is the entity within Asterisk that communicates with
 and acts on behalf of the calling party.
 
-Monitor: The monitor is the entity within Asterisk that communicates
+\item Monitor: The monitor is the entity within Asterisk that communicates
 with and monitors the status of the called party.
 
-Generic Agent: A generic agent is an agent that uses protocol-agnostic
+\item Generic Agent: A generic agent is an agent that uses protocol-agnostic
 methods to communicate with the caller. Generic agents should only be
 used for phones, and never should be used for "trunks."
 
-Generic Monitor: A generic monitor is a monitor that uses protocol-
+\item Generic Monitor: A generic monitor is a monitor that uses protocol-
 agnostic methods to monitor the status of the called party. Like with
 generic agents, generic monitors should only be used for phones.
 
-Native Agent: The opposite of a generic agent. A native agent uses
+\item Native Agent: The opposite of a generic agent. A native agent uses
 protocol-specific messages to communicate with the calling party.
 Native agents may be used for both phones and trunks, but it must be
 known ahead of time that the device with which Asterisk is communica-
 ting supports the necessary signaling.
 
-Native Monitor: The opposite of a generic monitor. A native monitor
+\item Native Monitor: The opposite of a generic monitor. A native monitor
 uses protocol-specific messages to subscribe to and receive notifica-
 tion of the status of the called party. Native monitors may be used
 for both phones and trunks, but it must be known ahead of time that
 the device with which Asterisk is communicating supports the
 necessary signaling.
 
-Offer: An offer of CC refers to the notification received by the caller
+\item Offer: An offer of CC refers to the notification received by the caller
 that he may request CC.
+\end{itemize}
 
 Request: When the caller decides that he would like to subscribe to CC,
 he will make a request for CC. Furthermore, the term may refer to any
@@ -233,7 +235,7 @@
 \item If available timers are running on multiple called parties,
 it is possible that one of the timers may expire before the others
 do. If such a situation occurs, then the interface on which the
-timer expired will ceased to be monitored. If, though, one of the
+timer expired will cease to be monitored. If, though, one of the
 other called parties becomes available before his available timer
 expires, the called party whose available timer had previously
 expired will still be included in the CC\_INTERFACES channel
@@ -247,8 +249,8 @@
 
 \item CC can potentially be a memory hog if used irresponsibly. The
 following are recommendations to help curb the amount of resources
-required by the CC engine. First, limit the number of maximum number
-of CC requests in the system using the cc\_max\_requests option in
+required by the CC engine. First, limit the maximum number of
+CC requests in the system using the cc\_max\_requests option in
 ccss.conf. Second, set the cc\_offer\_timer low for your callers. Since
 it is likely that most calls will not result in a CC request, it is
 a good idea to set this value to something low so that information
@@ -289,6 +291,10 @@
 extension, CC will only be offered to the caller for the parties called
 by the first instantiation of Dial.
 
+\item If a phone forwards a call, then CC may only be requested for
+the phone that executed the call forward. CC may not be requested
+for the phone to which the call was forwarded.
+
 \item CC is currently only supported by the Dial application. Queue,
 Followme, and Page do not support CC because it is not particularly
 useful for those applications.


