[asterisk-commits] murf: branch murf/RFCs r168394 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Sat Jan 10 17:42:26 CST 2009
Author: murf
Date: Sat Jan 10 17:42:26 2009
New Revision: 168394
URL: http://svn.digium.com/svn-view/asterisk?view=rev&rev=168394
Log:
Simple CDRs vs. Leg-Based CDRs; define channel and CDR unique IDs. Define how Asterisk will handle them. Propose changes to the app_queue and channel_masquerade() funcs.
Modified:
team/murf/RFCs/CDRfix2.rfc.txt
Modified: team/murf/RFCs/CDRfix2.rfc.txt
URL: http://svn.digium.com/svn-view/asterisk/team/murf/RFCs/CDRfix2.rfc.txt?view=diff&rev=168394&r1=168393&r2=168394
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (original)
+++ team/murf/RFCs/CDRfix2.rfc.txt Sat Jan 10 17:42:26 2009
@@ -19,9 +19,11 @@
serve as a specification for what the CEL->CDR generator is expected
to do.)
-And, CEL doesn't solve a problem that exists in the code, that needs
-to be addressed, and affects not only CDR's, but when/where/how the h
-(hangup) extension gets run. Parking and transfers affect this code.
+I believe that CEL can solve the CDR problem, by making
+the CDR generation independent of channels and the PBX loops.
+A similar approach may help with running the hangup extension
+at the proper times and on the proper channels when parking/
+xfers happen.
So, I'm going to spec out my changes completely before I change one
line of code. I want/need to see the end of the journey before I take
@@ -35,7 +37,7 @@
enough that we can simply provide the CEL2CDR option in the
make menuselect.
-TWO CDR PHILOSOPHIES
+CDR PHILOSOPHIES
--------------------
There seem to be, in the CDR universe, two different philosophies:
@@ -66,21 +68,33 @@
another for the hold-time, another for the continued A-C conversation,
and another for the transfer.
-In this specification, we will use the Leg-based system. Asterisk
-was originally set up for a channel-based CDR system, but a few
-complications come with transfers and parks; a major problem
-occurs with masquerading, in that the channel/peer relationships
-get swapped. We will probably not escape having to do a full
-analysis of masquerading and how it affects the channel/peer
-relationships, but that will come later in this spec (timewise).
-
-
-===========
-<I removed the section about Channel/Peer Roles;
- and a description of masqerading....
- it looks very much like this approach makes this
- study uninteresting>
-===========
+This document will specify both these methods. The channel
+based will be called "SIMPLE CDRs", and will will issue a single
+CDR expresing its lifetime; its disposition will reflect how
+it was created. You should be able to infer the interactions
+between channels by using the linkedID field, but to those
+using this method are just usually interested in how much
+time a channel was connected, and not usually so interested
+in what it did while connected.
+
+The other method will be called "LEG-BASED CDRs" and will allow
+varying levels of description; For instance, HOLD and PARK
+records can be suppressed via config file options.
+
+Asterisk was originally set up for a hybrid channel-based CDR
+system, but a few complications come with transfers and parks;
+a major problem occurs with masquerading, in that the channel/peer
+relationships (enshrined in some function arguments)
+get swapped. Using CEL, we separate the CDR data from channels
+and overcome the problems in the original Asterisk implementation.
+
+==================================================================
+= =
+= COMMON ISSUES BETWEEN =
+= LEG BASED CDRs and =
+= SIMPLE CDRs =
+= =
+==================================================================
@@ -103,6 +117,150 @@
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.
+==================
+The UniqueID Field
+==================
+
+Previously, in Asterisk, there existed the "uniqueID"
+field; I think it was meant to be unique between CDR's,
+but via the magic of masquerading, it was not always so
+unique.
+
+A lot of discussion went into this; I was favoring dropping
+it entirely, but one user asked not to:
+
+ "I use the uniqueid extensively to
+ relate things like entries in the queue
+ log to it's associated CDR."
+
+Hmmm... There is one main difficulty about this;
+the queue app will no longer have any notion about
+what uniqueID the CDR might have. These unique
+ID's will no longer be stored on the channel!
+
+And, with masquerading going on, the uniqueID,
+even if it were stored on a channel (which it is/was),
+could not be guaranteed to remain the same across
+masquerades; the new channel gets a new uniqueID.
+The old <ZOMBIE> would keep the old uniqueID.
+
+
+CHANGE:
+We change the channel_masquerade func
+to copy the old channel uniqueID to the newly
+created channel (from the 'clone' to the 'original',
+using the terminology there). That way, the
+channel's uniqueID won't change with masquerading.
+But it will then not totally be unique...
+For instance, channel "Dahdi/1-1" and
+"Dahdi/1-1<ZOMBIE>" will both have the same
+uniqueID. But that doesn't strike me as a big
+problem. the <ZOMBIE> version is stripped of
+(almost) everything important to that channel,
+and will soon die... so who cares?
+
+We change the code in app_queue to *ONLY* use
+the channel uniqueID.
+
+And we pass the channel uniqueID code up thru
+the CEL layer to the CDR, wherever we pass
+up the channel name. (channel and destchannel
+fields).
+
+And at the CDR level, we provide two ID's rather
+than one. A uniqueID for the channel; and a uniquID
+for the CDR itself. In the SimpleCDR world, we could
+use the channel uniqueID, because there will never
+be more than one CDR issued for a channel.
+
+The channel uniqueID would be labelled "channel_uniqueid"
+and the CDR uniqueID would be labelled "cdr_uniqueid".
+
+We'd have to decide in the Leg-based world, where we actually
+mention channel uniqueID's... because I guess they are a reference
+more than a declaration, and because there would be no no place
+where they would be declared, per se. Right now, in CDRs we
+refer to channels by name, not by uniqueID. It's almost as
+if we should store all the channel uniqueID's in a separate
+table, with a column for the channel uniqueID and a column for
+the channel name; that would allow the queue log entries to
+map to CDR logs...
+
+OR, we provide a field for the channel name, and another field
+(column) for the corresponding channel uniqueID, when we generate
+the CDR legs. We mention channel names for "channel" and "destchannel"
+fields... so we'd have corresponding "channel" and "channeluniqueid"
+fields, and "destchannel" and "destchanneluniqueid" fields.
+
+Also, both of these uniqueID fields would be configurable,
+as per Greyman's suggestions: you could configure them to
+be the current timestamp format, or a uuid field, and you could
+append any fixed string to either, or append an IP/gethostname()
+type string to either. I think this should cover all bases, don't you?
+
+================
+ This will be supported in the cel2cdr config file:
+================
+
+# channel_unique_id = timestamp | uuid | none
+# the default is timestamp.
+
+# cdr_unique_id = timestamp | uuid | none
+# the default is timestamp.
+
+# (If you don't want/need CDR unique id's, then
+# why generate and transfer them? But channel_unique_id's
+# would be less optional-- if you need to them to
+# correspond to the queue logs.)
+
+# channel_unique_id_append = hostname | hostip | uuid | string:<string>
+
+# cdr_unique_id_append = hostname | hostip | uuid | string:<string>
+
+# linkedid_append = hostname | hostip | uuid | string:<string>
+
+# All of the above fields (channel_unique_id_append and
+# cdr_unique_id_append and linkedid_append) would default
+# to empty strings.
+
+# The <string> would be appended to the unique id/linked id when it
+# the value is stored in its internal field in Asterisk.
+
+# If you had several systems logging to the same db,
+# you could guarantee that the id's were unique across
+# systems that way. UUid's should be unique across systems
+# as-is; make sure they are set up that way!
+
+# I purposely did not allow the linkedID's to be configured:
+# I need them to have certain properties that uuid's do not
+# support. So, I'm not allowing users to play with linkedid's
+# except to append things to them. Users, you'll have to deal
+# with that!
+================
+
+unique_append_ident=<string>
+
+The <string> would be appended to the unique id/linked id when it
+goes "out the door"; This would allow you to tack on a system name
+or ip or whatever to every uniqueid/linkedid as it goes into the db/log
+file/whatever; if you had several systems logging to the same db,
+you could guarantee that the id's were unique across systems that way.
+
+unique_append_uuid = yes
+ would append the uuid (all 36 bytes of it)
+ to the uniqueID/linkedid. This uuid is calculated once per Asterisk
+ invocation;
+
+unique_append_uuid = per_channel
+ would append the uuid (all 36 bytes of it)
+ to the uniqueID/linkedid. This uuid is calculated once per
+ channel created.
+
+In this Specification, we will preserve and expand the
+notion of a unique ID for each CDR generated.
+
+A lot of discussion went into this
+
------------------------------
INTERNAL vs. EXTERNAL calling:
------------------------------
@@ -134,6 +292,44 @@
When xfers involve 3 channels, you probably will have to decide
what happens in 8 cases; each case involving either C internal
or external... best of luck!
+
+------------------------------
+Checkpoints for long calls
+------------------------------
+
+I've had it suggested more than a few times that
+it would be nice to issue "checkpoint" CDRs for
+conversations that are longer than a certain amount
+of time. I picture the dialing apps (like Dial and
+Queue), issueing CEL checkpoint events, much along
+the same line as the Dial L() options give warnings
+about time limits to the call.
+
+The CEL2CDR interface would respond to these events
+by posting a CHECKPOINT CDR with the EndTime set to
+the time of the checkpoint event. A billing application
+would ignore these, especially if a CDR that closes
+the conversation that is not of type CHECKPOINT was
+issued. If Asterisk crashes and no CDR issued for a long
+conversation, the last CHECKPOINT could be used instead.
+
+NOTE: Is this really useful? You could also replay the
+event stream, and be able to estimate the crash time
+as the time of the last event in the stream, or better
+yet, the time the core file was written, and cap
+off any open conversations with that time.
+
+So, no checkpoints are necessary!
+
+
+
+==================================================================
+= =
+= =
+= LEG BASED CDRs =
+= =
+= =
+==================================================================
----------------------------------
CDR BEHAVIOR in various situations
@@ -690,6 +886,450 @@
CDR5: A -> C; start: e5 ans: end: e6 type: 3WAY Disp: ANSW Party: B linkedid: utf87
CDR6: A -> C; start: e6 ans: end: e7 type: AXFER2 Disp: ANSW Party: B linkedid: utf87 Hung: A
+===========================================================
+Parking
+===========================================================
+
+Parking (and holding) channels should have no
+affect on the Simple CDR's, beyond the fact
+that parking usually begins with one of the
+parties in a parking stall, the other getting
+hung up. On hangup, the channel will generate
+a CDR.
+
+Any dial attempt (from parking lot expiration time being
+reached) should be recorded in a CDR, unless the dialed
+party did not answer, and the unanswered option was not
+set to yes.
+
+
+
+---------------------------------
+CDR Fields (current and proposed)
+---------------------------------
+
+accountcode (user modifiable)
+amaflags (user modifiable)
+answer (timeval)
+
+billsec
+channel
+clid
+confid
+dcontext
+disposition
+dst
+dstchannel
+duration
+end (timeval)
+hangupcause (new)
+lastapp
+lastdata
+linkedid (new, sort of)
+party (new)
+src
+start (timeval)
+uniqueid
+userfield (user modifiable)
+vars (a list of attached vars)
+
+
+---------
+TYPE LIST
+---------
+
+Here is a list of the CDR types, and what special meanings
+apply to CDR fields for that type:
+
+Type
+----
+
+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.
+
+
+AXFER1 The state in the assisted transfer, where, if A axfers B to C, A is
+ talking to C, and B is on hold.
+
+AXFER2 A state in the assisted Transfer sequence, where:
+ (a) the referer and the referee (A) and (C) have had a conversation,
+ and A has hung up to allow B and C to converse
+ (b) One of the parties of a 3-way conversation has hung up
+ to allow the other two parties to converse. the AXFER2HUNGUP field
+ 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.
+
+FAX an incoming or outgoing fax call leg;
+
+FINAL If configured for such, after all channels involved in a logical call have been closed,
+ we can issue a CDR with this type. The start/stop times should coincide with the end
+ time of the final channel to be closed.
+
+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.
+
+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.
+
+PREDIAL When Dial, Queue, etc, initiate, a new call leg is formed, and the
+ previous leg is ended at the moment the app is started. This type
+ will be applied to the new leg formed. It will usually contain the
+ times from the time an extension picked up to the time a dial command
+ was issued (the amount of time to dial something); or it will record the
+ time from an incoming call's arrival, to the time of a dial (the amount
+ of time traversing IVR, for instance).
+
+RECALL a system-initiated call, usually to a single specific target, otherwise
+ similar to CALL. Occurs when PARKed calls expire;
+
+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 channel
+ fields should describe the two parties.
+
+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.
+
+
+
+
+==================================================================
+= =
+= =
+= Simple CDRs =
+= =
+= =
+==================================================================
+
+A sufficiently large number of developers are interested in
+a paired-down CDR system that simply describes the amount of time
+that a channel was alive.
+
+So, a much simplifed system where a single CDR is issued
+when a channel is closed, with a START time when the channel
+was initially created, an ANSWER time when it was first answered,
+and a final END time when the channel was hung up.
+
+As in the Asterisk original CDR system, there would be arithmetically
+determined billsec and duration fields.
+
+Now, during its lifetime, a channel may have been put on hold,
+transferred a hundred times, put on hold an unmerciful number of
+times, parked a dozen times and picked up who-knows-how-many times,
+but it's entire span of existence would be described with a
+single, simple CDR.
+
+But, still the main points of its activity could be inferred from
+the other channels activated in its behalf, whose CDRs would document
+the same linkedID.
+
+The main rule about the fields in the CDR are: the disposition
+from handling the creation of the channel are set in the
+channel itself; not in the CDR that might have dialed (or tried to dial)
+this channel.
+
+All dial attempts will be recorded if the unanswered option in cel2cdr.conf
+is not set.
+
+CHANGE: A new disposition value, CANCELLED, which is set when
+ a channel is dialed, but the dial was discontinued
+ because another channel, which was dialed at the the
+ same time, was answered first.
+
+CHANGE: Add a new config file, cel2cdr; In the [general] field,
+ add an option called "noanswer". The value "yes" will
+ make the cdr generator skip issueing CDR's for dial attempts
+ that do not yield "ANSWERED". (criteria: billsec == 0)
+
+----------------------------------
+CDR BEHAVIOR in various situations
+----------------------------------
+
+As in the Leg-Based CDR's, we'll present a few of the same
+scenarios, and you can get a feel for the way the CDR's would
+be generated.
+
+===========================================================
+BLIND XFERS: (Only when C answers in the following sequences):
+===========================================================
+
+Assuming the 'normal' case, A calls B.
+
+Peer (B) does the xfer:
+
+ Assume these event times:
+ e1: A's start time. (Set previously, perhaps)
+ e1a: A calls Dial() for B, D, E, and F (E is busy, F is offline)
+ e2: B answer time (Set previously, perhaps)
+ e3: B hits #, flashes hook, whatever to initiate
+ xfer and A starts getting MOH
+ e4: B finishes dialing, hits a button, whatever,
+ and ends his call. (B gets congestion, dialtone, whatever)
+ e5: C answers
+ e6: A or C hang up.
+
+
+ CDRs wanted: (src_channel -> dest_channel)
+ CDR1: A -> B start: e1a ans: e2 end: e4 Party: B disp: ANSW linkedID: abc9
+ *CDR2: A -> D start: e1a ans: - end: e2 Party: D disp: CANCELLED linkedID: abc9
+ *CDR3: A -> E start: e1a ans: - end: e2 Party: E disp: BUSY linkedID: abc9
+ *CDR4: A -> F start: e1a ans: - end: e2 Party: F disp: FAIL linkedID: abc9
+ CDR5: A start: e1 ans: e1 end: e6 Party: A disp: ANSW linkedID: abc9
+ CDR6: B -> C start: e4 ans: e5 end: e6 Party: C disp: ANSW linkedid: abc9
+
+(cdrs marked with * will not be output if config file option unanswered is not set to 'yes'.)
+
+Chan (A) does the xfer:
+
+ Assume these event times:
+ e1: A'a start time. (Set previously)
+ e1a: A calls Dial() for B, D, E, and F (E is busy, F is offline)
+ e2: B answer time (Set previously)
+ e3: A hits #, flashes hook, whatever, to initiate
+ xfer and B starts getting MOH
+ e4: A finishes dialing the xfer, hits a button, whatever,
+ and ends his call.
+ e5: C answers, begins conversing with B
+ e6: B or C hang up.
+
+ CDRs wanted: (src_channel -> dest_channel)
+ *CDR1: A -> E start: e1a ans: - end: e1a Party: E disp: BUSY linkedID: abc9
+ *CDR2: A -> F start: e1a ans: - end: e1a Party: F disp: FAIL linkedID: abc9
+ *CDR3: A -> D start: e1a ans: - end: e2 Party: D disp: CANCELLED linkedID: abc9
+ CDR4: A start: e1 ans: e1 end: e4 Party: A disp: ANSW linkedID: abc9
+ CDR5: A -> B start: e1a ans: e2 end: e6 Party: B disp: ANSW linkedID: abc9
+ CDR6: B -> C start: e4 ans: e5 end: e6 Party: C disp: ANSW linkedid: abc9
+
+
+===========================================================
+Attended Xfer:
+===========================================================
+
+Attended Xfers Involve 3 parties, and can involve 3-ways.
+3 ways are either handled by the phone, or the channel
+driver. For instance on phones with Dahdi interfaces,
+you can do 3-ways using hookflashes. SIP phones provide
+a conference button, usually, that does the 3-way mixing
+in the phone itself. Asterisk can't see these 3-ways.
+
+They follow this flow (non-3way):
+
+A and B are conversing. A (or B) performs some sequence
+to initiate the attended xfer. (one touch via feature
+# or * dtmf, hookflash, buttons on sip phone, etc)
+
+B (or A) gets put on hold, while the person doing the
+xfer gets a dialtone. The transferer dials the target
+extension (C), and the target extension (C) answers.
+
+A (or B) and C converse privately.
+
+At this point A (or B) can hang up for the simple
+one-touch call forwarding scenario. B (or A) is
+connected (bridged) to C.
+
+But (when the 'one-touch' feature is not used) A
+(or B) can also form a 3-way conversation in some
+cases, and all 3 can converse. A can hang up,
+and leave B and C talking, or for that matter,
+B can hang up, and leave A and C talking. I'd
+imagine that C could hang up and leave A and B
+conversing, as at the beginning.
+
+Each variant might generate a different CDR
+sequence.
+
+Event times of interest:
+
+e1: A picks up (or calls in); begins to dial a destination
+ela: Dial() is called for B, D, E, and F (E is busy, F is offline)
+e2: B answers
+e3: A or B hits initiates a transfer (#, hookflash, *2 or whatever)
+ The initiating party gets dialtone, the other party MOH.
+e3b: A or B might hang up now before C answers
+e4: C answers; the initiating party and C converse.
+e4b: C never answers... A and B are reconnected.
+e4d: A or B hangs up.
+e5: (optional) the initiating party (via hookflash or other method)
+ signals a 3-way to start
+e6: the initiating party hangs up; C and the other party are
+ now connected.
+e7: C or the other party hangs up.
+
+
+(a) C never answers. The attempt would get
+ recorded.
+
+ A initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ *CDR4: A -> C start: e2 ans: - end: e4b Disp: NOANS Party: C linkedID: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e4d Disp: ANSW Party: B linkedid: zzz33
+ CDR6: A start: e1 ans: e1 end: e4d Disp: ANSW Party: A linkedid: zzz33
+
+ B initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ *CDR4: B -> C start: e2 ans: - end: e4b Disp: NOANS Party: C linkedID: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e4d Disp: ANSW Party: B linkedid: zzz33
+ CDR6: A start: e1 ans: e1 end: e4d Disp: ANSW Party: A linkedid: zzz33
+
+
+(b) the transferer hangs up before C answers.
+ this should probably proceed like a blind
+ xfer.
+
+ A initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR6: A start: e1 ans: e1 end: e3b Disp: ANSW Party: A linkedid: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e4d Disp: ANSW Party: B linkedid: zzz33
+ CDR4: A -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+
+ B initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e3b Disp: ANSW Party: B linkedid: zzz33
+ CDR6: A start: e1 ans: e1 end: e4d Disp: ANSW Party: A linkedid: zzz33
+ CDR4: B -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+
+(c) the transferer talks to C, and hangs up,
+ allowing the other two parties to be
+ bridged.
+
+CHANGE: One more CDR field! the AXFER2HUNGUP field, which records
+ who hung up to put the call in AXFER2 state. Only contains
+ data when type is AXFER2.
+
+ A initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A start: e1 ans: e1 end: e4d Disp: ANSW Party: A linkedid: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e7 Disp: ANSW Party: B linkedid: zzz33
+ CDR6: A -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+
+ B initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A -> B; start: e1a ans: e2 end: e4d Disp: ANSW Party: B linkedid: zzz33
+ CDR5: A start: e1 ans: e1 end: e7 Disp: ANSW Party: A linkedid: zzz33
+ CDR6: B -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+
+
+
+(d) the transferer engages a 3-way, to
+ which the transferer hangs up first.
+ the other two parties are still bridged.
+
+ A initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A start: e1 ans: e1 end: e6 Disp: ANSW Party: A linkedid: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e7 Disp: ANSW Party: B linkedid: zzz33
+ CDR6: A -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+
+ B initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A -> B; start: e1a ans: e2 end: e6 Disp: ANSW Party: B linkedid: zzz33
+ CDR5: A start: e1 ans: e1 end: e7 Disp: ANSW Party: A linkedid: zzz33
+ CDR6: B -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+
+
+(e) the transferer engages a 3-way, to
+ which the transferee (C) hangs up first (time e6).
+ the other two parties are still bridged.
+
+ A initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A -> C start: e2 ans: e4 end: e6 Disp: ANSW Party: C linkedID: zzz33
+ CDR5: A start: e1 ans: e1 end: e7 Disp: ANSW Party: A linkedid: zzz33
+ CDR6: A -> B; start: e1a ans: e2 end: e7 Disp: ANSW Party: B linkedid: zzz33
+
+ B initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: B -> C start: e2 ans: e4 end: e6 Disp: ANSW Party: C linkedID: zzz33
+ CDR5: A -> B; start: e1a ans: e2 end: e7 Disp: ANSW Party: B linkedid: zzz33
+ CDR6: A start: e1 ans: e1 end: e7 Disp: ANSW Party: A linkedid: zzz33
+
+
+(f) the transferer engages a 3-way, to
+ which the transferred party hangs up first.
+ the other two parties are still bridged.
+
+ A initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A -> B; start: e1a ans: e2 end: e6 Disp: ANSW Party: B linkedid: zzz33
+ CDR5: A -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+ CDR6: A start: e1 ans: e1 end: e7 Disp: ANSW Party: A linkedid: zzz33
+
+ B initiates xfer:
+
+ *CDR1: A -> E start: e1a ans: - end: e1a Disp: BUSY Party: E linkedID: zzz33
+ *CDR2: A -> F start: e1a ans: - end: e1a Disp: FAIL Party: F linkedID: zzz33
+ *CDR3: A -> D start: e1a ans: - end: e2 Disp: CANCELLED Party: D linkedID: zzz33
+ CDR4: A start: e1 ans: e1 end: e6 Disp: ANSW Party: A linkedid: zzz33
+ CDR5: B -> C start: e2 ans: e4 end: e7 Disp: ANSW Party: C linkedID: zzz33
+ CDR6: A -> B; start: e1a ans: e2 end: e7 Disp: ANSW Party: B linkedid: zzz33
+
+
+
+
+
+
---------------------------------
CDR Fields (current and proposed)
@@ -710,11 +1350,13 @@
dstchannel
duration
end (timeval)
+hangupcause (new) only set on CDR's involving a hangup.
+hanguporig (new) name of the channel that hung up first, if available
lastapp
lastdata
linkedid (new, sort of)
parkingstall (new)
-party (new)
+party (new) The name of the channel whose lifespan is described in the CDR.
src
start (timeval)
type (new)
@@ -722,91 +1364,3 @@
userfield (user modifiable)
vars (a list of attached vars)
-
----------
-TYPE LIST
----------
-
-Here is a list of the CDR types, and what special meanings
-apply to CDR fields for that type:
-
-Type
-----
-
-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.
-
-
-AXFER1 The state in the assisted transfer, where, if A axfers B to C, A is
- talking to C, and B is on hold.
-
-AXFER2 A state in the assisted Transfer sequence, where:
- (a) the referer and the referee (A) and (C) have had a conversation,
- and A has hung up to allow B and C to converse
- (b) One of the parties of a 3-way conversation has hung up
- to allow the other two parties to converse. the AXFER2HUNGUP field
- 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.
-
-FAX an incoming or outgoing fax call leg;
-
-FINAL If configured for such, after all channels involved in a logical call have been closed,
- we can issue a CDR with this type. The start/stop times should coincide with the end
- time of the final channel to be closed.
-
-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.
-
-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.
-
-PREDIAL When Dial, Queue, etc, initiate, a new call leg is formed, and the
- previous leg is ended at the moment the app is started. This type
- will be applied to the new leg formed. It will usually contain the
- times from the time an extension picked up to the time a dial command
- was issued (the amount of time to dial something); or it will record the
- time from an incoming call's arrival, to the time of a dial (the amount
- of time traversing IVR, for instance).
-
-RECALL a system-initiated call, usually to a single specific target, otherwise
- similar to CALL. Occurs when PARKed calls expire;
-
-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 channel
- fields should describe the two parties.
-
-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