[asterisk-commits] murf: branch murf/RFCs r159940 - /team/murf/RFCs/CDRfix2.rfc.txt

SVN commits to the Asterisk project asterisk-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 asterisk-commits mailing list