This page is simply an effort at explaining the reason and purpose behind the design of CEL. You can skip this section if you don't care why things are the way they are and only want to get it up and running.
Improving on CDR
CEL, or Channel Event Logging, has been was 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, conferencedinvolved in conferencing, forwarded, etc. In general, those doing who create billing applications in with 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.
Billing requires detail
The design philosophy of CEL is to generate event data that can be 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 There are definite parallels between Asterisk Manager Interface 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 Looking at an example of all the interactions and events involved in a moderately complex call scenario can give the reader a feel for the complexities involved in billing, please . 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 Click the expansion link to see the resulting 42 CEL events : with annotations.
Note that the actual CEL events below are in CSV format and do not include the ;;; and text after that which gives a description of what the event represents.
In terms of Manager events, the above Events correspond to the following 80 Manager events :shown in the expansion link.
And, humorously enough, the above 80 manager events, or 42 CEL events, correspond to the following two CDR records (at the moment!):
""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","" ""fxs.50" 150","150","152","extension","Zap/50-1","Zap/51-1","NoOp","More Hangup message after hopping around"","2007-05-09 17:37:59","2007-05-09 17:38:06","2007-05-09 17:39:11","72","65","ANSWERED","DOCUMENTATION","","1178753871.3",""