[asterisk-commits] murf: branch murf/RFCs r168437 - /team/murf/RFCs/CDRfix2.rfc.txt
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Sun Jan 11 00:41:50 CST 2009
Author: murf
Date: Sun Jan 11 00:41:50 2009
New Revision: 168437
URL: http://svn.digium.com/svn-view/asterisk?view=rev&rev=168437
Log:
outline all the CDR fields for both Leg-Based, and Simple CDRs. Do some cleanup and clarification. Next: get more specific about the Leg-based CDR fields. In which type CDR's are they set/left empty...
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=168437&r1=168436&r2=168437
==============================================================================
--- team/murf/RFCs/CDRfix2.rfc.txt (original)
+++ team/murf/RFCs/CDRfix2.rfc.txt Sun Jan 11 00:41:50 2009
@@ -205,6 +205,9 @@
# channel_unique_id = timestamp | uuid | none
# the default is timestamp.
+# dstchannel_unique_id = timestamp | uuid | none
+# the default is timestamp.
+
# cdr_unique_id = timestamp | uuid | none
# the default is timestamp.
@@ -215,13 +218,15 @@
# channel_unique_id_append = hostname | hostip | uuid | string:<string>
+# dstchannel_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.
+# dstchannel_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.
@@ -238,28 +243,6 @@
# 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:
@@ -900,7 +883,7 @@
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.
+set to "no".
@@ -908,30 +891,191 @@
CDR Fields (current and proposed)
---------------------------------
-accountcode (user modifiable)
-amaflags (user modifiable)
+accountcode (user modifiable)
+amaflags (user modifiable)
+callerid_name (user modifiable)
+callerid_num (user modifiable)
+callerid_ani (user modifiable)
+callerid_rdnis (user modifiable)
+callerid_dnid (user modifiable)
+userfield (user modifiable)
+ --- These 8 fields are set on the channel,
+ and CEL events will record snapshots of these with
+ each channel event. All these values are copied
+ from channel structure storage with each event
+
+ The user can modify these channel values with the
+ CHANNEL() func from the dialplan, as in (eg):
+ Set(CHANNEL(accountcode)=someval)
+
+ To set the callerid_* fields, you would use the
+ CALLERID() func. For example:
+ Set(CALLERID(ani)=some-val);
+
+ Most of the channel drivers allow you to specify
+ a value for accountcode and amaflags, as well as
+ at least the name & num in the callerid. When
+ the channel is created, these values are set from
+ the channel config files.
+
+ Of course, as each leg CDR is generated, the
+ value of these fields will be reported as they
+ appeared in the last event associated with the
+ leg. So, these values may change from leg to
+ leg, according to the leg type and the dialplan.
+ It is up to your billing system to choose the
+ proper values. For instance, the callerid informaton
+ might be edited after the call is received, but
+ before an extension is dialed, so that it is more
+ readable for the target extension's display. The
+ callerid would then be different from one leg to
+ the next...
+
answer (timeval)
-
-billsec
+disposition (numeric/string)
+
+ --- if this lef involves a dialing operation,
+ then the answer field will be set with the
+ time of the answer; if the line was answered.
+ Whether the line is answered or not, the
+ disposition variable will be set with the
+ result of the dial. Disposition can be one of
+ FAILED, NO ANSWER, ANSWERED, BUSY, and CANCELLED.
+ CANCELLED occurs, for instance, when several
+ phones are dialed at once... the first to answer
+ will get the ANSWERED disposition. The rest of the
+ targets will be silenced, and they will get the
+ CANCELLED disposition.
+
+billsec (integer)
+duration (integer)
+ --- billsec: the usual (end-time minus answer-time)
+ (if answer time not set, then this would be 0.)
+ --- duration: the usual (end-time minus start-time)
+ (either start or end time not set, this would be 0).
+
channel
-clid
-confid
+ --- If a dialing operation were involved with this
+ leg, then this is the originating channel name.
+
+channel_uniqueid
+ --- if a uniqueID is associated with the dialing
+ channel, this would contain that ID.
+
dcontext
-disposition
dst
+ --- the context and extension of the destination
+ of a call. If A calls B, then these fields
+ would contain the target context and extension
+ that was dialed.
+
+
dstchannel
-duration
+ --- This is the name of the channel that
+ was called (the target channel).
+
+
+dstchannel_uniqueid
+ --- the dstchannel's uniqueID, if it has one.
+
+
end (timeval)
+ --- time of the hangup of the channel.
+
hangupcause (new)
-lastapp
+ --- the cause of the hangup. It is stored as an integer.
+ If you use the odbc_adaptive CDR backend, and your
+ database backend is an integer, the integer will
+ be recorded in the DB. If the field is a string, then
+ a string will be stored:
+
+Integer value String value
+ 1 "Unallocated (unassigned) number"
+ 2 "No route to specified transmit network"
+ 3 "No route to destination"
+ 6 "Channel unacceptable"
+ 7 "Call awarded and being delivered in an established channel"
+ 16 "Normal Clearing"
+ 17 "User busy"
+ 18 "No user responding"
+ 19 "User alerting, no answer"
+ 21 "Call Rejected"
+ 22 "Number changed"
+ 27 "Destination out of order"
+ 28 "Invalid number format"
+ 29 "Facility rejected"
+ 30 "Response to STATus ENQuiry"
+ 31 "Normal, unspecified"
+ 34 "Circuit/channel congestion"
+ 38 "Network out of order"
+ 41 "Temporary failure"
+ 42 "Switching equipment congestion"
+ 43 "Access information discarded"
+ 44 "Requested channel not available"
+ 45 "Pre-empted"
+ 50 "Facility not subscribed"
+ 52 "Outgoing call barred"
+ 54 "Incoming call barred"
+ 57 "Bearer capability not authorized"
+ 58 "Bearer capability not available"
+ 65 "Bearer capability not implemented"
+ 66 "Channel not implemented"
+ 69 "Facility not implemented"
+ 81 "Invalid call reference value"
+ 88 "Incompatible destination"
+ 95 "Invalid message unspecified"
+ 96 "Mandatory information element is missing"
+ 97 "Message type nonexist."
+ 98 "Wrong message"
+ 99 "Info. element nonexist or not implemented"
+ 100 "Invalid information element contents"
+ 101 "Message not compatible with call state"
+ 102 "Recover on timer expiry"
+ 103 "Mandatory IE length error"
+ 111 "Protocol error, unspecified"
+ 127 "Interworking, unspecifies"
+ The above list is, of course, subject to occasional changes.
+
+hanguporig (new) name of the channel that hung up first, if available
+hanguporig_uniqueid (new) the uniqueID of the channel that hung up first, if
+ configured, and if available.
+
+lastapp
lastdata
+ --- these fields record a relevant application call
+ and its arguments. The data contained and whether
+ it is filled, depends on the CDR type field.
+
linkedid (new, sort of)
-party (new)
+ --- the linkedID field. Transfers (and other operations) may end up generating
+ several CDRs with the same linkedid field.
+
+party (new)
+ --- If A calls B, and B transfers A to C,
+ the party field will contain the name of
+ channel A. The channel/dstchannel will
+ reflect B calling C.
+
src
+ --- the name of extension that was executing when
+ this channel was created.
+
start (timeval)
-uniqueid
-userfield (user modifiable)
+ --- the time that this channel came into being.
+
vars (a list of attached vars)
+ --- When this is implemented, any channel variables
+ that begin with "CDR_" will be sent with the event,
+ and attached as a variable list to the CDR being posted.
+ The database backend can then either ignore these,
+ or set these fields in the row, as described
+ by the backends documentation.
+
+
+
+
+confid
+ --- a conference ID. Not yet spec'd.
---------
@@ -1057,7 +1201,16 @@
this channel.
All dial attempts will be recorded if the unanswered option in cel2cdr.conf
-is not set.
+is not set no "no".
+
+The "party" field will record the name of the channel for which the
+CDR was generated. The src/dest, channel, dstchannel fields will
+contain the channel that dialed, and the target of the dial, which
+stragely enough, may not be the channel being documented by the CDR!
+(if more than one channel was being dialed, one is randomly picked
+for the dstchannel).
+
+
CHANGE: A new disposition value, CANCELLED, which is set when
a channel is dialed, but the dial was discontinued
@@ -1105,7 +1258,7 @@
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'.)
+(cdrs marked with * will not be output if config file option unanswered is set to 'no'.)
Chan (A) does the xfer:
@@ -1335,32 +1488,197 @@
CDR Fields (current and proposed)
---------------------------------
-accountcode (user modifiable)
-amaflags (user modifiable)
+accountcode (user modifiable)
+amaflags (user modifiable)
+callerid_name (user modifiable)
+callerid_num (user modifiable)
+callerid_ani (user modifiable)
+callerid_rdnis (user modifiable)
+callerid_dnid (user modifiable)
+userfield (user modifiable)
+ --- These 8 fields are set on the channel,
+ and CEL events will record snapshots of these with
+ each channel event. All these values are copied
+ from channel structure storage with each event
+
+ The user can modify these channel values with the
+ CHANNEL() func from the dialplan, as in (eg):
+ Set(CHANNEL(accountcode)=someval)
+ I propose that the last non-null value be used,
+ from the time-sorted list of channel events. It
+ *is* possible (or could be possible), that these
+ fields could be lost... or be reset to the default...
+
+ To set the callerid_* fields, you would use the
+ CALLERID() func. For example:
+ Set(CALLERID(ani)=some-val);
+
+ Most of the channel drivers allow you to specify
+ a value for accountcode and amaflags, as well as
+ at least the name & num in the callerid. When
+ the channel is created, these values are set from
+ the channel config files.
+
+
answer (timeval)
-
-axfer2hungup (new)
-billsec
+disposition (numeric/string)
+
+ the time of the answer event that may be associated with
+ bringing this channel into existence. For instance, in the
+ case of an incoming call, this field might not be
+ set, if the dialplan doesn't explicitly call the Answer()
+ app, and no applications run involve answering the channel.
+ If A calls B, and this is B's CDR, it will reflect the answer
+ time of B.
+
+ Disposition in the same manner reflects how this channel
+ responded to a ringing signal. It could be FAIL, BUSY,
+ NO ANSWER, ANSWERED, or CANCEL. CANCEL happens when a set
+ of channels are opened to dial, and one of them answers.
+ The other channels get CANCELLED disposition and are closed.
+
+billsec (integer)
+duration (integer)
+ --- billsec: the usual (end-time minus answer-time)
+ (if answer time not set, then this would be 0.)
+ --- duration: the usual (end-time minus start-time)
+ (either start or end time not set, this would be 0).
+
channel
-clid
-confid
+ --- If this channel was dialed, this is the channel
+ that initiated the call. Remember that is
+ possible (in a transfer situation), for the
+ dialing party to transfer the call to another
+ channel. So, if A calls B, and B transfers
+ A to C, then C's CDR will have the name of
+ the C channel in the "party field" (see below),
+ and the name of the B channel will be in the
+ "channel" field.
+
+channel_uniqueid
+ --- a uniqueid that is stored on the channel.
+ masquerading should copy this to the new
+ channel, overwriting its otherwise freshly
+ new value. If you specify
+ channel_unique_id = none
+ in the config file, then this field
+ will not be set in the database backends.
+
+RESEARCH: what should we do about local channels?
+ For the moment, the two halves of a local
+ channel should have the same channel_uniqueid.
+
dcontext
-disposition
dst
+ --- the context and extension of the destination
+ of a call. If A calls B, then these fields
+ would be filled in the CDR for the B channel.
+
+
dstchannel
-duration
+ --- If this channel was dialed, this is the name
+ of this channel (the target channel).
+ Remember that is possible (in a transfer situation),
+ for the callee to be different than
+ what was targeted.
+
+RESEARCH: Really? can this happen? If not, we can eliminate
+ this field!
+
+
+dstchannel_uniqueid
+ --- the dstchannel's uniqueID, if it has one.
+
+
end (timeval)
-hangupcause (new) only set on CDR's involving a hangup.
-hanguporig (new) name of the channel that hung up first, if available
+ --- time of the hangup of the channel.
+
+hangupcause (new)
+ --- the cause of the hangup. It is stored as an integer.
+ If you use the odbc_adaptive CDR backend, and your
+ database backend is an integer, the integer will
+ be recorded in the DB. If the field is a string, then
+ a string will be stored:
+
+Integer value String value
+ 1 "Unallocated (unassigned) number"
+ 2 "No route to specified transmit network"
+ 3 "No route to destination"
+ 6 "Channel unacceptable"
+ 7 "Call awarded and being delivered in an established channel"
+ 16 "Normal Clearing"
+ 17 "User busy"
+ 18 "No user responding"
+ 19 "User alerting, no answer"
+ 21 "Call Rejected"
+ 22 "Number changed"
+ 27 "Destination out of order"
+ 28 "Invalid number format"
+ 29 "Facility rejected"
+ 30 "Response to STATus ENQuiry"
+ 31 "Normal, unspecified"
+ 34 "Circuit/channel congestion"
+ 38 "Network out of order"
+ 41 "Temporary failure"
+ 42 "Switching equipment congestion"
+ 43 "Access information discarded"
+ 44 "Requested channel not available"
+ 45 "Pre-empted"
+ 50 "Facility not subscribed"
+ 52 "Outgoing call barred"
+ 54 "Incoming call barred"
+ 57 "Bearer capability not authorized"
+ 58 "Bearer capability not available"
+ 65 "Bearer capability not implemented"
+ 66 "Channel not implemented"
+ 69 "Facility not implemented"
+ 81 "Invalid call reference value"
+ 88 "Incompatible destination"
+ 95 "Invalid message unspecified"
+ 96 "Mandatory information element is missing"
+ 97 "Message type nonexist."
+ 98 "Wrong message"
+ 99 "Info. element nonexist or not implemented"
+ 100 "Invalid information element contents"
+ 101 "Message not compatible with call state"
+ 102 "Recover on timer expiry"
+ 103 "Mandatory IE length error"
+ 111 "Protocol error, unspecified"
+ 127 "Interworking, unspecifies"
+ The above list is, of course, subject to occasional changes.
+
+hanguporig (new) name of the channel that hung up first, if available
+hanguporig_uniqueid (new) the uniqueID of the channel that hung up first, if
+ configured, and if available.
+
lastapp
lastdata
+ --- If this channel was created via some application
+ these fields should record the app and its args.
+ It might be used to help define the mechanism that
+ spawned this channel. For instance Park_redial for
+ expired parks, etc.
+
linkedid (new, sort of)
-parkingstall (new)
-party (new) The name of the channel whose lifespan is described in the CDR.
+ --- the linkedID field. Transfers may end up generating
+ several CDRs with the same linkedid field.
+
+party (new)
+ --- The name of the channel whose lifespan is described in the CDR.
+ Pretty basic. Will most likely look like: Dahdi/1-1
+ Don't be shocked if you see Dahdi/1-2 --it
+ happens with local channels.
+ Don't be shocked if you see Dahdi/1-1<ZOMBIE>
+ -- it happens with masquerading.
+
src
+ --- the name of extension that was executing when
+ this channel was created.
+
start (timeval)
-type (new)
-uniqueid
-userfield (user modifiable)
+ --- the time that this channel came into being.
+
vars (a list of attached vars)
-
+ --- When this is implemented, any channel variables
+ that begin with CDR_ will be sent with the event,
+ and attached as a variable list to the CDR being posted.
More information about the asterisk-commits
mailing list