[asterisk-commits] seanbright: branch group/newcdr r202647 - /team/group/newcdr/doc/tex/
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Tue Jun 23 11:03:15 CDT 2009
Author: seanbright
Date: Tue Jun 23 11:03:11 2009
New Revision: 202647
URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=202647
Log:
Some reformatting, wrap lines consistently, and change ASCII art to figure.
Modified:
team/group/newcdr/doc/tex/cel-doc.tex
team/group/newcdr/doc/tex/celdriver.tex
Modified: team/group/newcdr/doc/tex/cel-doc.tex
URL: http://svn.asterisk.org/svn-view/asterisk/team/group/newcdr/doc/tex/cel-doc.tex?view=diff&rev=202647&r1=202646&r2=202647
==============================================================================
--- team/group/newcdr/doc/tex/cel-doc.tex (original)
+++ team/group/newcdr/doc/tex/cel-doc.tex Tue Jun 23 11:03:11 2009
@@ -1,47 +1,52 @@
\section{Design Goals}
-CEL is being written with the hopes that it will help solve some of the problems
-that were difficult to address in CDR records. Some difficulties in CDR generation
-are the fact that the CDR record stores three events: the "Start" time, the "Answer"
-time, and the "End" time. Billing time is usually the difference between "Answer" and
-"End", and total call duration was the difference in time from "Start" to "End".
-The trouble with this direct and simple approach is the fact that calls can be
-transferred, put on hold, conferenced, forwarded, etc. In general, those doing billing
-applications in Asterisk find they have to do all sorts of very creative things to
-overcome the shortcomings of CDR records, often supplementing the CDR records with
-AGI scripts and manager event filters.
-
-CEL is an acronym, taken from "Channel Event Logging".
-
-The fundamental assumption is that the Channel is the fundamental communication object in asterisk,
-which basically provides a communication channel between two communication ports. It makes
-sense to have an event system aimed at recording important events on channels. Each
-Event is attached to a channel, like ANSWER or HANGUP. Some events are meant to connect
-two or more channels, like the BRIDGE\_START event. Some events, like BLINDTRANSFER, are initiated
-by one channel, but affect two others. These events use the Peer field, like BRIDGE would,
-to point to the target channel.
-
-The design philosophy of CEL is to generate event data that can grouped together to form
-a billing record. This may not be a simple task, but we hope to provide a few different
-examples that could be used as a basis for those involved in this effort.
-
-There are definite parallels between Manager events and CEL events; but there are some differences.
-Some events that are generated by CEL are not generated by the Manager interface (yet). CEL is
-optimized for databases, and Manager events are not. The focus of CEL is billing. The Manager interface
-is targeted to real-time monitoring and control of asterisk.
-
-To give the reader a feel for the complexities involved in billing, please take note of the
-following sequence of events:
-
-Remember that 150, 151, and 152 are all Zap extension numbers, and their respective devices are
-Zap/50, Zap/51, and Zap/52.
-
-152 dials 151; 151 answers. 152 parks 151; 152 hangs up. 150 picks up the park (dials 701). 150 and 151 converse.
-151 flashes hook; dials 152, talks to 152, then 151 flashes hook again for 3-way conference. 151 converses with the
-other two for a while, then hangs up. 150 and 152 keep conversing, then hang up. 150 hangs up first.(not that it matters).
-
-This sequence of actions will generate the following annotated list of 42 CEL events:
+CEL, or Channel Event Logging, is being written with the hopes that it will help
+solve some of the problems that were difficult to address in CDR records. Some
+difficulties in CDR generation are the fact that the CDR record stores three
+events: the "Start" time, the "Answer" time, and the "End" time. Billing time is
+usually the difference between "Answer" and "End", and total call duration was
+the difference in time from "Start" to "End". The trouble with this direct and
+simple approach is the fact that calls can be transferred, put on hold,
+conferenced, forwarded, etc. In general, those doing billing applications in
+Asterisk find they have to do all sorts of very creative things to overcome the
+shortcomings of CDR records, often supplementing the CDR records with AGI
+scripts and manager event filters.
+
+The fundamental assumption is that the Channel is the fundamental communication
+object in asterisk, which basically provides a communication channel between two
+communication ports. It makes sense to have an event system aimed at recording
+important events on channels. Each Event is attached to a channel, like ANSWER
+or HANGUP. Some events are meant to connect two or more channels, like the
+BRIDGE\_START event. Some events, like BLINDTRANSFER, are initiated by one
+channel, but affect two others. These events use the Peer field, like BRIDGE
+would, to point to the target channel.
+
+The design philosophy of CEL is to generate event data that can grouped together
+to form a billing record. This may not be a simple task, but we hope to provide
+a few different examples that could be used as a basis for those involved in
+this effort.
+
+There are definite parallels between Manager events and CEL events; but there
+are some differences. Some events that are generated by CEL are not generated
+by the Manager interface (yet). CEL is optimized for databases, and Manager
+events are not. The focus of CEL is billing. The Manager interface is targeted
+to real-time monitoring and control of asterisk.
+
+To give the reader a feel for the complexities involved in billing, please take
+note of the following sequence of events:
+
+Remember that 150, 151, and 152 are all Zap extension numbers, and their
+respective devices are Zap/50, Zap/51, and Zap/52.
+
+152 dials 151; 151 answers. 152 parks 151; 152 hangs up. 150 picks up the park
+(dials 701). 150 and 151 converse. 151 flashes hook; dials 152, talks to 152,
+then 151 flashes hook again for 3-way conference. 151 converses with the other
+two for a while, then hangs up. 150 and 152 keep conversing, then hang up. 150
+hangs up first.(not that it matters).
+
+This sequence of actions will generate the following annotated list of 42 CEL
+events:
\begin{verbatim}
"EV_CHAN_START","2007-05-09 12:46:16","fxs.52","152","","","","s","extension","Zap/52-1","","","DOCUMENTATION","","1178736376.3","","" ;;; 152 takes the phone off-hook
@@ -97,7 +102,8 @@
"EV_CHAN_END","2007-05-09 12:50:13","fxs.50","150","150","","","h","extension","Zap/50-1","","","DOCUMENTATION","","1178736471.6","","" ;;; 150 ends
\end{verbatim}
-In terms of Manager events, the above Events correspond to the following 80 Manager events:
+In terms of Manager events, the above Events correspond to the following 80
+Manager events:
\begin{verbatim}
Event: Newchannel
@@ -754,8 +760,8 @@
Cause-txt: Normal Clearing
\end{verbatim}
-And, humorously enough, the above 80 manager events, or 42 CEL events, correspond to the following
-two CDR records (at the moment!):
+And, humorously enough, the above 80 manager events, or 42 CEL events,
+correspond to the following two CDR records (at the moment!):
\begin{verbatim}
""fxs.52" <152>","152","h","extension","Zap/52-1","Zap/51-1","NoOp","More Hangup message after hopping around"","2007-05-09 17:35:56","2007-05-09 17:36:20","2007-05-09 17:36:36","40","16","ANSWERED","DOCUMENTATION","","1178753756.0",""
@@ -763,10 +769,10 @@
\end{verbatim}
-\section{CEL Events and Fields}
-
-While CDR's and the Manager are basically both event tracking mechanisms, CEL tries
-to track only those events that might pertain to billing issues.
+\section{Events and Fields}
+
+While CDR's and the Manager are basically both event tracking mechanisms, CEL
+tries to track only those events that might pertain to billing issues.
Here is a list of events tracked by CEL:
\begin{verbatim}
@@ -816,20 +822,23 @@
\end{verbatim}
-\section{CEL Applications, Functions}
-
-\subsection{The CEL Function}
-
-The CEL function parallels the CDR function, for fetching values from the channel or event.
-It has some notable notable differences, though! For instance, CEL data is not stored on the
-channel. Well, not much of it, anyway! You can use the CEL function to set the amaflags, accountcode,
-and userfield, which are stored on the channel.
-
-Channel variables are not available for reading from the CEL function, nor can any variable name other
-than what's in the list, be set. CDR's have a structure attached to the channel, where the CDR function
-could access the values stored there, or set the values there. CDR's could store their own variable
-lists, but CEL has no such storage. There is no reason to store any event information, as they are
-immediately output to the various backends at the time they are generated.
+\section{Applications \& Functions}
+
+\subsection{CEL Function}
+
+The CEL function parallels the CDR function, for fetching values from the
+channel or event. It has some notable notable differences, though! For
+instance, CEL data is not stored on the channel. Well, not much of it, anyway!
+You can use the CEL function to set the amaflags, accountcode, and userfield,
+which are stored on the channel.
+
+Channel variables are not available for reading from the CEL function, nor can
+any variable name other than what's in the list, be set. CDR's have a structure
+attached to the channel, where the CDR function could access the values stored
+there, or set the values there. CDR's could store their own variable lists, but
+CEL has no such storage. There is no reason to store any event information, as
+they are immediately output to the various backends at the time they are
+generated.
See the description for the CEL function from the CLI: core show function CEL
@@ -846,11 +855,12 @@
eventtype
\end{verbatim}
-\subsection{The CELGenUserEvent Application}
-
-This application allows the dialplan to insert custom events into the event stream.
-
-For more information, in the CLI, type: core show application CELGenUserEvent
+\subsection{CELGenUserEvent Application}
+
+This application allows the dialplan to insert custom events into the event
+stream.
+
+For more information, in the CLI, type: core show application CELGenUserEvent
It's arguments take this format:
@@ -858,17 +868,17 @@
CELGenUserEvent(eventname)
\end{verbatim}
-Please note that there is no restrictions on the name supplied. If it happens to match
-a standard CEL event name, it will look like that event was generated. This could be
-a blessing or a curse!
-
-
-\section{CEL config files}
-
-\section{CEL Back Ends}
-
-Right now, the CEL package will support CSV, Customized CSV, ODBC, PGSQL, TDS, Sqlite, Sqlite3, and Radius database backends.
-See the doc/celdriver.tex file for how to use these back ends.
+Please note that there is no restrictions on the name supplied. If it happens to
+match a standard CEL event name, it will look like that event was
+generated. This could be a blessing or a curse!
+
+\section{Configuration Files}
+
+\section{Storage Backends}
+
+Right now, the CEL package will support CSV, Customized CSV, ODBC, PGSQL, TDS,
+Sqlite, Sqlite3, and Radius database backends. See the doc/celdriver.tex file
+for how to use these back ends.
\section{Generating Billing Information}
Modified: team/group/newcdr/doc/tex/celdriver.tex
URL: http://svn.asterisk.org/svn-view/asterisk/team/group/newcdr/doc/tex/celdriver.tex?view=diff&rev=202647&r1=202646&r2=202647
==============================================================================
--- team/group/newcdr/doc/tex/celdriver.tex (original)
+++ team/group/newcdr/doc/tex/celdriver.tex Tue Jun 23 11:03:11 2009
@@ -1,6 +1,6 @@
Channel Event records can be stored in many different databases or even CSV text.
-\section{MSSQL}
+\section{Microsoft SQL Server}
Asterisk can currently store Channel Events into an MSSQL database in
two different ways: cel\_odbc or cel\_tds
@@ -109,7 +109,7 @@
logs a connection to the database and will now record every
desired channel event at the moment it occurs.
-\subsection{TDS, using cel\_tds}
+\subsection{FreeTDS, using cel\_tds}
Compile, configure, and install the latest FreeTDS package:
\begin{verbatim}
tar -zxvf freetds-0.62.4.tar.gz &&
@@ -172,11 +172,11 @@
call to the database when it's complete.
-\section{MYSQL}
+\section{MySQL}
Using MySQL for Channel Event records is supported by using ODBC and the cel\_odbc module.
-\section{PGSQL}
+\section{PostreSQL}
If you want to go directly to postgresql database, and have the cel\_pgsql.so
compiled you can use the following sample setup.
On Debian, before compiling asterisk, just install libpqxx-dev.
@@ -221,9 +221,9 @@
);
\end{verbatim}
-\section{SQLLITE}
-
-SQLite version 2 is supported in cel\_sqlite.
+\section{SQLite 3}
+
+SQLite version 3 is supported in cel\_sqlite3\_custom.
\section{RADIUS}
@@ -235,18 +235,34 @@
\item Asterisk PBX
\end{itemize}
-\begin{verbatim}
- +--------------------+
- | Asterisk PBX |
- | |
- |********************|
- | | +---------------+
- | RADIUS client |------->| RADIUS server |
- | |<-------| (FreeRADIUS) |
- +--------------------+ +---------------+
-\end{verbatim}
-
-
+\begin{figure}[h]
+\begin{center}
+\setlength{\unitlength}{4cm}
+\begin{picture}(3,.75)
+\put(0,0){\line(0,1){.75}}
+\put(0,.75){\line(1,0){1.5}}
+\put(1.5,0){\line(0,1){.75}}
+\put(0,0){\line(1,0){1.5}}
+\put(.1,.4){\makebox(1.3,.3){Asterisk PBX}}
+\put(.1,.4){\line(1,0){1.3}}
+\put(.1,.1){\line(1,0){1.3}}
+\put(.1,.1){\line(0,1){.3}}
+\put(1.4,.1){\line(0,1){.3}}
+\put(.1,.1){\makebox(1.3,.3){RADIUS Client}}
+\put(1.8,0){\line(0,1){.5}}
+\put(1.8,.5){\line(1,0){1.1}}
+\put(1.8,0){\line(1,0){1.1}}
+\put(2.9,0){\line(0,1){.5}}
+\put(1.8,.275){\makebox(1.1,.1){RADIUS Server}}
+\put(1.8,.125){\makebox(1.1,.1){$(FreeRADIUS)$}}
+\thicklines
+\put(1.4,.3){\vector(1,0){.4}}
+\put(1.8,.2){\vector(-1,0){.4}}
+\thinlines
+\end{picture}
+\end{center}
+\caption{Asterisk/RADIUS Integration}
+\end{figure}
\subsection{Steps to follow in order to have RADIUS support}
More information about the asterisk-commits
mailing list