Reference:Call Detail Record CDR

What is a CDR?

A CDR's purpose is to facilitate billing of customers for calls performed through a gateway running on a particular IP 21/400/3000. A CDR is defined as a sequence of entries which in total describes a single call as far as billing is considered.

What is the mechanism CDRs are provided by the IP gateways?

The CDR's log entries are provided using a dedicated channel which is technically equal to the version 3 log mechanism of the IP 400/3000. This is to de-couple CDR entries from other possible log entries. The transport mechanisms are as follows: • syslog: deliver entries to (unix-ish) syslogd. Entries are sent to a configured syslog demon using the syslog class specified. • raw tcp: deliver entries to specified host and port in raw text-based tcp stream. The IP 400/3000 will open a TCP socket to the specified IP address and port and write each entry to this stream. If the stream is closed for any reason, it will be re-opened again. Entries are separated by CR/NL. • raw tcp incoming: retrieve entries in raw text-based tcp stream by connecting to a specified TCP port of the ip 400/3000. As before except that the IP 400 waits for an incoming connect. • http: deliver entries by HTTP 1.0 GET request to specified web server with query part in URL (e.g. http://path?log=msg)

Can CDRs get lost?

Yes. Currently, CDRs are NOT permanently buffered. That is, when a CDR is generated and there is no active and functional CDR delivery mechanism at this point in time, the CDR gets lost. Thus, you must make sure that the mechanism is always in place. More specifically, CDRs delivered by either raw tcp or syslog are always lost if the mechanism is not in place once the CDR is written. However, CDRs delivered via HTTP are buffered to an extent (precisely, as far as memory suffices in the gateway). Thus, for reliable billing, HTTP is the method of choice. The amount of memory dedicated for buffering CDRs depends on the gateway model. Models with big memory (such as IP800 and IP3000) buffer up to 300kB, others (such as IP400 and IP202) only 50kB. A CDR is of variable size, but as a rule of thumb, 200 bytes per CDR should be a valid average.

How many CDRs are generated per call and when?

Unless you have ticked “Send only billing CDR’s” in the gateways CDR configuration, you will see a single CDR for each event on the call.

Here are the events for a typical straight call:

event=A:Call src_cgpn=32 src_cdpn=7300961321
event=B:Call src_cgpn=32 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Call src_cgpn=32 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Proceed src_cgpn=32 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Alert src_cgpn=32 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Connect src_cgpn=32 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Disc src_cgpn=32 cause=02_80_90 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=A:Rel src_cgpn=32 cause=02_80_90 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Rel src_cgpn=32 cause=02_80_90 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32

With reduced CDRs for billing purposes, you will see only the final events:

event=A:Rel src_cgpn=32 cause=02_80_90 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32
event=B:Rel src_cgpn=32 cause=02_80_90 src_cdpn=7300961321 dst_cdpn=7300961321 dst_cgpn=32

See chapter 9 for more detailed exampled of CDRs. So if you are interested in billing purposes only, you should configure billing CDRs only to reduce traffic and to increase the number of calls being buffered in case of a CDR link failure (see above). The CDR generation is done by the gateway process. This has the advantage that billing is available even if there is no PBX installed, however it has the disadvantage that for PBX-internal calls (including calls in-between different locations of the same PBX net) no CDRs are generated (since these calls are not seen by the gateway process).

Each event is prefixed by a leg identifier (either A or B). To understand this, consider the following example:

• A PBX user (extension 32) calls an external user in the PSTN (07300932)
• The PBX is registered with the gateway process with the GW1 voice interface
• The call is sent to the PSTN through an ISDN interface PRI1

When the call arrives from the PBX at GW1, the GW1 interface mappings (if any) are evaluated. Then the call is sent to the routing engine. This end of the call is known as “leg A”. All events originating at this leg are prefixed with “A:”. Depending on the routing table configuration cdpn/cgpn mappings are performed, then the call is routed to an outgoing interface. This end of the call is known as “leg B”. All events originating at this end are prefixed with “B:”.

In the CDR, you will find the numbers after the mapping at the source interface but before the mapping defined by the routing table as src_cgpn and src_cdpn respectively. The numbers after the mappings defined by the routing table but before performing the mappings defined for the destination interface are shown as dst_cgpn and dst_cdpn respectively. These numbers are always in sync on the A and B leg. However, please note that the numbers (especially the dst_* numbers) may change due to settings in the routing table (e.g. if least cost routing is configured and multiple call by call providers are tried to place the call). Also, the interfaces may change (e.g. if a trunk line bundle is used and one line is busy clearing the call with a “no b channel available” cause code, then another interface may be tried and thus seen as dst_if). Please note also that, after a call transfer, the src_if (which actually is the interface used by the A leg) may be used for an outgoing call (and the dst_if may be used for an incoming call), depending on the value of the dir attribute.

Initially, the A-leg is incoming (as seen from the routing engine), the B-leg is outgoing. However, after a call transfer, both legs may be incoming or both legs may be outgoing or the A-leg may be outgoing and the B-leg incoming. This may be significant for billing purposes. Each event has a “dir” attribute which is either “in” or “out”. So if there is an event for the A-leg and the “dir” attribute has the value “out”, then the call direction of the A-leg is outgoing (as seen from the routing engine).

When a call transfer happens, it is reflected in an A:X or B:X event. If 2 calls are merged by a transfer, then one of the call legs receives an X event with an xref/xleg attribute which points to the call being merged.

All CDRs created by a single call, regardless of the leg the respective event originates from, share the same ref field.

Depending on the billing strategy, the src/dst_dgpn (diverting party number) may be of interest.

How do I tell internal from external calls?

From the gateway process’ point of view (and thus from the CDR’s point of view), there is no distinction between internal and external calls. Any call travelling through the gateway process is a call for which CDRs are generated. As said before, internal calls from the PBX’s point of view currently do not create CDRs at all. For all others, the interpretation of being “internal” or “external” must be done by the receiving application. Usually, such applications have a configuration dialog to define the interface names (which are seen as dst_if or src_if) which are considered “external”. As a rule of thumb, most ISDN interfaces can be regarded “external” normally3. These names include TEL1, TEL2, TEL3, TEL4, PPP, PRI14.

In some cases, ISDN interfaces are used for connectivity to internal entities. This is e.g. if a second PBX is connected via a tie line or the gateway is looped-in to the trunk line of the legacy PBX. The PRI2 interface is usually used in that way.

Note though that all interfaces may be configured individually and thus in a specific installation may be used for different purposes.

How does a single CDR log entry look like?

A particular log entry has several fields. A field has a name tag and a value. Fields can appear in an arbitrary order within the entry. Not all fields appear in every log entry. Name tags include:

Tag: cause

Example: cause=02_82_81

Cause for call termination. These are coded <size>_<coding-standard/location>_<causecode>[_< diagnostics>]. The individual octets (separated by ‘_’ are hex-numbers). Size is usually 0x2. Coding-standard/location is made up of: bit 8, 7, 6 and 5 usually 1000. Bit 4, 3, 2, 1 gives the location (that is, the entity generating the cause code). There may be extraneous octets giving further diagnostic information.

If bit 8 to 5 are unequal to 1000, the cause code is non-standard.

The location is usually 0010, so that the second octet is usually 0x82 (10000010).

The lower 7 bit of the third octet is the cause code. It is coded as follows (for standard codes):

Cause value	Cause
0x1	Unallocated number
0x2	No route to specified transit network
0x3	No route to destination
0x6	Channel unnacceptable
0x7	Call awarded and being delivered in an established channel
0x10	Normal call clearing
0x11	User busy
0x12	No user responding
0x13	No answer from user (user alerted)
0x15	Call rejected
0x16	Number changed
0x1A	Non-selected user clearing
0x1B	Destination out of order
0x1C	Invalid number format
0x1D	Facility rejected
0x1E	Response to STATUS ENQUIRY
0x1F	Normal, unspecified
0x22	No circuit/channel available
0x26	Network out of order
0x29	Temporary failure
0x2A	Switching equipment congestion
0x2B	Access information discarded
0x2C	Requested circuit/channel not available
0x2D	Resources unavailable, unspecified
0x31	Quality of service unavailable
0x32	Requested facility not subscribed
0x39	Bearer capability not authorised
0x3A	Bearer capability not presently available
0x3F	Service or option ot available, unspecified
0x41	Bearer capability not implemented
0x42	Channel type not implemented
0x45	Requested facility not implemented
0x46	Only restricted digital information bearer capability is available
0x4F	Service or option not implemented, unspecified
0x51	Invalid call reference value
0x52	Identified channel does not exist
0x53	A suspended call exists, but this call identity does not
0x54	Call identity in use
0x55	No call suspended
0x56	Call having the requested call identity has been cleared
0x58	Incompatible destination
0x5B	Invalid transit network selection
0x5F	Invalid message, unspecified
0x60	Mandatory information element missing
0x61	Message type non-existent or not implemented
0x62	Message not compatible with call state
0x63	Information element non-existent or nor implemented
0x64	Invalid information element contents
0x65	Message not compatible with call state
0x66	Recovery on timer expiry
0x6F	Protocol error, unspecified
0x7F	Interworking, unspecified