[svn-commits] murf: branch murf/RFCs r159940 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Mon Dec 1 09:02:25 CST 2008
Author: murf
Date: Mon Dec 1 09:02:25 2008
New Revision: 159940
URL: http://svn.digium.com/view/asterisk?view=rev&rev=159940
Log:
Start thinking about user defined Legs and app related CDR's.
Modified:
team/murf/RFCs/CDRfix2.rfc.txt
Modified: team/murf/RFCs/CDRfix2.rfc.txt
URL: http://svn.digium.com/view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=diff&rev=159940&r1=159939&r2=159940
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (original)
+++ team/murf/RFCs/CDRfix2.rfc.txt Mon Dec 1 09:02:25 2008
@@ -31,6 +31,9 @@
CHANGE: add a 'make menuselect" option (in Compiler Options) to set
CDR_HANDLING_INLINE option. All current behavior is preserved
by NOT setting this var, which is by default Off.
+NOTE: If we handle this via a CEL facility, the code will be separate
+ enough that we can simply provide the CEL2CDR option in the
+ make menuselect.
TWO CDR PHILOSOPHIES
--------------------
@@ -100,12 +103,6 @@
represent the linkedID field. The point is not that example linkedID
is fake; it's that all the CDR's in a set have the same linkedID.
-We set up a config file element to allow you to format the linkedID
-field when it is output to a CDR. While playing with the numeric
-representation is probably not wise, you might find it useful to
-append or prepend a system name to the number, so that if multiple
-machines file CDR's to the same database, you can separate them out.
-
------------------------------
INTERNAL vs. EXTERNAL calling:
------------------------------
@@ -172,7 +169,7 @@
e5: C answers
e6: A or C hang up.
- CDRs wanted: (src -> dest)
+ CDRs wanted: (src_channel -> dest_channel)
CDR1: A -> B; start: e1 ans: e2 end: e3 type: CALL Party: A linkedID: abc1
CDR2: A start: e3 end: e5 type: HOLD linkedid: abc1
CDR3: B -> C; start: e3 ans: e5 end: e6 type: BXFER Party: A linkedID: abc1
@@ -191,7 +188,7 @@
e5: C answers, begins conversing with B
e6: B or C hang up.
- CDRs wanted: (src -> dest)
+ CDRs wanted: (src_channel -> dest_channel)
CDR1: A -> B; start: e1 ans: e2 end: e4 type: CALL Party: A linkedid: pqw40
CDR2: B start: e3 end: e5 type: HOLD linkedid: pqw40
CDR3: A -> C; start: e3 ans: e5 end: e6 type: BXFER Party: B linkedid: pqw40
@@ -472,12 +469,97 @@
used multiple times, the linkedID should vary from one meeting to the next,
as long as all participants exit from one meeting to the next.
-A CONF type CDR will be issued.
+A CONF type CDR will be issued after a user exits a conference.
CHANGE: Add a conferenceID field to the CDR list.
<MORE TO COME>
+===========================================================
+Calls to Apps
+===========================================================
+
+All 'incoming' calls (An outside caller coming in via an
+Dahdi FXO interface, an FXS extension (phone) that goes
+off hook, a SIP incoming INVITE, etc) get a pbx dialplan
+attached to them, and the dialplan determines what series
+of application invocations will apply to that call.
+
+For 'normal' calls, the PBX will attach two channels together,
+and a human-to-human conversation results.
+
+But, in those cases when a call terminates in the
+dialplan before another channel is dialed, a CDR should
+reflect this.
+
+The trouble is, recording app invocations is not useful
+to most users. Apps commonly used would be stuff like
+Goto, GotoIf, NoOp, BackGround, etc, and the current
+practice has been simply to record the last application
+run, and its args, along with context and extension.
+
+Normally, for an incoming call, the dialplan will be
+run, and commonly the Answer() application will be run.
+If soon thereafter, a Dial() application is run, the
+start time and answer() times get co-mingled into the
+CDR that represents the call.
+
+It appears that a CDR leg should be generated for
+an incoming call, up to the point of a dial, queue,
+followme, whatever, or a hangup.
+
+Some apps, especially those that take up more
+than a trivial amount of time, should probably
+have their own CDR leg emitted. An example would be
+voicemail; it would be nice to see the arguments
+to the call, so as to record who did what.
+
+But somehow, if there are thousands of incoming calls,
+it seems especially useless to see what sound files
+were played to each. Especially if each call got played
+a dozen sound files...
+
+When an FXS picks up a phone and gets dialtone,
+we would want the pickup time to be a start
+time for the dial will ensue.
+
+But if an FXO calls in, and spends 60 seconds
+with an IVR before a Dial() is executed to an
+extension, the time Asterisk created the channel
+may or may not be an acceptable start time for
+the Dial.
+
+ForkCDR was a heavily used application to provide
+user specified timing. Similar capbilities must
+exist so that dialplan writers can determine
+what call legs they wish to add to the default
+set (which includes Dialing, transfers, and etc).
+
+CEL provides USER events, and an app to allow these
+events to be inserted into the event stream.
+What we need is extend this concept to the CDR level,
+and make it so such user defined events get CDR's
+generated for them.
+
+How about an application SplitCDR(type), that, when
+called, will generate a leg CDR with a type string
+specified by the 'type' argument, which constitutes
+a user-defined CDR type. The current account code,
+userfield, etc, will be associated with this CDR
+as normal. The moment that the SplitCDR() app is
+called the end time of the CDR generated.
+
+CHANGE: Institute the SplitCDR() application.
+
+INVESTIGATE: which Apps should cut a CDR leg
+as a minimum?
+Dial, Meetme, FollowMe, Queue, Voicemail, Park,
+VoicemailMain for starters... The dial related
+apps generate switching events that will be tracked,
+but Voicemail is not currently treated specially;
+such apps may just as easily have SplitCDR()
+called before and after to track them... and not
+cut legs by default...
==============================================
MIXED SCENARIOS
@@ -485,8 +567,7 @@
This stuff isn't going to do us any good unless
it can smoothly represent complicated, mixed
-scenarios properly. So, let's invent a few, andA internal | |
-
+scenarios properly. So, let's invent a few, and
see if it holds up nicely.
(1) Dahdi Burlington Pile-On:
@@ -601,17 +682,10 @@
Type
----
-CALL a user-initiated call, usually via Dial or Queue or Meetme applications.
-
-PARK a user has been Parked. The Party field records who is parked. The
- ParkingStall field records which parking stall the parked channel was
- sent to.
-
-BXFER A blind transfer has occurred. The src field records the caller; the dest
- field records the successfully reached target; the Party field records
- who the call was transferred to. For this segment, the two parties
- conversing were the target and the Party that was transferred. The
- transferer was hung up at the start time.
+3WAY src_channel, dest_channel, and Party are all conferenced together via Asterisk. This
+ most commonly occurrs in dahdi channels. SIP phones
+ usually do this at the phone, so all you might see is two calls going
+ on to the same device at the same time.
AXFER An attempt to do an assisted xfer. The disposition will not be ANSWERED.
@@ -627,32 +701,43 @@
records which party of the two or three hung up. The start time
records the time of hangup.
+BARGE Records the time period while someone is 'barging' a channel (eavesdropping).
+ Src describes the channel doing the barge. Dest is the channel being listened
+ to. (Party might list who is connected to dest channel).
+
+BXFER A blind transfer has occurred. The src_channel field records the caller; the dest_channel
+ field records the successfully reached target; the Party field records
+ who the call was transferred to. For this segment, the two parties
+ conversing were the target and the Party that was transferred. The
+ transferer was hung up at the start time.
+
+CALL a user-initiated call, usually via Dial or Queue or Meetme applications.
+
+CONF a Meetme Conference participation.
+
HOLD A state where the src is being played nothing but music on hold;
this occurs during assisted xfers, and possibly in other scenarios.
Party contains who put this channel on hold.
-3WAY src, dest, and Party are all conferenced together via Asterisk. This
- most commonly occurred in dahdi channels, that can handle it. SIP phones
- usually do this at the phone, so all you might see is two calls going
- on to the same device at the same time.
+PARK a user has been Parked. The Party field records who is parked. The
+ ParkingStall field records which parking stall the parked channel was
+ sent to.
RECALL a system-initiated call, usually to a single specific target, otherwise
similar to CALL. Occurs when PARKed calls expire;
-CONF a Meetme Conference participation.
-
RECONN This happens when an attended transfer is attempted, but the target
party does not answer the phone. When the ringing times out, the
- transferer and the original party are reconnected. The src and dest
+ transferer and the original party are reconnected. The src and dest channel
fields should describe the two parties.
-BARGE Records the time period while someone is 'barging' a channel (eavesdropping).
- Src describes the channel doing the barge. Dest is the channel being listened
- to. (Party might list who is connected to dest).
-
-WHISPER Records the time period while one channel 'whispers' into another. src is the
- channel doing the whispering. Dest is the channel being whispered to.
-
+USER User inserted CDR Leg, initiated via SplitCDR() call. The Party field
+ is set to the type value the user passed. The current channel's CDR will
+ be ended at the time the SplitCDR was run. The start time of the next
+ leg will also equal this time.
+
+WHISPER Records the time period while one channel 'whispers' into another. srcChannel is the
+ channel doing the whispering. DestChannel is the channel being whispered to.
QUESTION: What other kinds of inter-channel interactions are possible? INVESTIGATE: go
thru apps & funcs and find possible interactions.
More information about the svn-commits
mailing list