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.
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 |