Asterisk CDR

From 탱이의 잡동사니
Jump to: navigation, search

Overview

Asterisk CDR(Call Detail Record) 내용 정리.

Basic

Asterisk-12 부터 CDR 내용이 변경되었다.

  • Individual components in Asterisk no longer modify CDRs directly. CDRs are produced based on the state of the channels and bridges within Asterisk. As a result, there is much greater degree of consistency in CDRs throughout Asterisk, regardless of the application channels happen to be executing in.
  • The behaviour of CDRs between multiple parties is now defined.
  • Depending on how channels are dialed and bridged, multiple CDRs will be created for a given call. Post-processing of these records will be required to determine the overall statistics of the call.

가이드에서도 Asterisk-12 부터 많은 변경이 있었지만, 더 특별하고, 더 추가적인 콜 Tracking 을 원한다면 CEL(Channel Event Log)도 함께 사용하도록 안내하고 있다.

Semantics and Syntax

  • Single: a channel is executing dialplan in Asterisk or otherwise has no relationship with any other channel. This is the default state of a CDR.
  • Dial: a channel is involved in a dial operation - either as a caller or as the callee. If they are the caller, they are automatically the Party A in the CDR. If they are the callee, they are automatically the Party B if there is a caller. If there is no caller - as is the case in channel origination - they are the Party A and there is no Party B.
  • Bridge: two channels share a bridge in which they can potentially talk to each other.
  • Finalized: the channel and Asterisk can no longer communicate or the relationship between the two channels has been broken. At this point, the last state of the channels involved is locked in the CDR.
  • Dispatched: the CDR has been written to the backend storages.

When a channel is created, a CDR is created for that channel. The channel is automatically the Party A of the CDR. The CDR is considered to be in the Single state while the channel executes dialplan or is waiting to be associated with another channel.

If a channel dials another channel, the CDR for that channel is transitioned to the Dial state. If the dial operation completes successfully and the channels are bridged together, the CDR transitions to the Bridged state. If the dial operation fails, the CDR transitions to the Finalized state. If the caller continues on in the dialplan, a new CDR is generated for them.

While the channels are bridged together, the CDR remains in the Bridged state. Operations that restrict media flow, such as call hold, are not reflected in CDRs. When the bridge is broken - either because one of the parties hangs up or a party is transferred - the CDR transitions to the Finalized state and any non-hungup channels have a new CDR created for them.

When a channel hangs up, all CDRs associated with it are implicitly fiinalized. When all CDRs for a channel are finalized, the CDRs are Dispatched to the backends for storage.

CDR Lifetime

Creation

A CDR record is created in any one of the following situations.

  • Whenever a channel is created.
  • Whenever a channel leaves a bridge and is not hung up.
  • When a CDR is forked from a prior record.
  • When a channel enters a multi-party bridge.
  • When a channel dials more than one channel.

When it is created, a CDR inherits the uniqueid and linkedid from its Party A channel, and a new sequence number is generated. When created as a result of a dial operation, the channel acting as the caller is always the Party A.

Dialing Parties

When a channel is known to dial other channels, a CDR is created for each dial attempt. The dial status is recorded for each dial attempt as a CDR Disposition. Note that all dial attempts may be dispatched depending on the CDR configuration. The caller is always the Party A in the created CDRs.

Bridging

If a channel is bridged with another channel, the following procedure is performed.

  • The CDR is marked as having entered a bridge. If there is no other channel in the bridge, the CDR waits for another channel to join.
  • For each pairing of channels, the channels are compared to determine which is the Party A channel and which is the Party B channel.
If the channel entering the bridge is the Party A, the CDR has a Party B, and the channel it is bridged with is the Party B, the CDR continues.
If the channel entering the bridge is the Party A, the CDR has a Party B, and the channel is not already the Party B, the current CDR is finalized and a new CDR is created for the relationship between the two parties. Note that the original CDR will be re-activated if the existing Party B enters the bridge.
If the channel entering the bridge is the Party A, the CDR has no Party B, then the channel it is bridged with becomes the Party B.
If the channel entering the bridge is the Party B, the other channel has a CDR with no Party B, this channel becomes the Party B and existing CDR is finalized.
If the channel entering the bridge is the Party B, the other channel has a CDR with a PArty B, and this channel is that CDR's Party B, then the existing CDR is finalized and the other channel's CDR activated.
If the channel entering the bridge is the Party B, the other channel has a CDR with a Party B, and this channel is not that CDR's Party B, then the existing CDR is finalized and a new CDR is created for that other channel with this channel as the Party B.
  • If a third party joins the bridge with Party A and Party B, the process choosing the Party A channel is repeated for each pairing of channels. Thus, in a three-way call there will be three CDR records; in a four-way call there will be six record.
2 important rules going on here.
- Keep using the existing CDR for a channel as long as possible.
- Make CDRs for all pairings of channels in a bridge.

Finalization

A CDR is finalized in one of the following scenarios.

  • If in a dial, the dial operation completes with a status other than ANSWER.
  • If in a bridge, either party A or party B leaves the bridge.
  • Either channel in a CDR hangs up.
  • The CDR is forked and the forking operation instructs that the CDR should be finalized.

When a CDR is finalized, no further modifications can be made to the CDR by the user of Asterisk.

If a Party A channel in a CDR is not hung up but the CDR is finalized - such as when the channel leaves a bridge of its Party B hangs up - a new CDR is made for that channel and the process in CDR Creation is begun again. Note that if the Party B in a CDR continues on in the dialplan and/or is bridged with a new party, it may become Party A for a new CDR.

If at any point the Party A channel for a CDR is hung up, all CDR records for that Party A are dispatched.

Dispatch

When a CDR is dispatched, all CDRs associated with the channel are committed to permanent storage. The CDRs at this point are removed from memory.

Fields

AMA Flags

AMA Flags are set on a channel and are conveyed in the CDR. They inform billing systems how to treat the particular CDR. Asterisk provides no additional semantics regarding these flags - they are present simply to help external systems classify CDRs.

  • OMIT
  • BILLING
  • DOCUMENTATION

Variables

CDR 작성시, 아래의 아래의 CDR Variable 을 사용할 수 있다. 뿐만 아니라, SET(CDR(name)=value) 를 사용하면 직접 CDR variable 을 만들어서 사용할 수도 있다.

In addition, you can set your own extra variables by using Set(CDR(name)=value). These variables can be output into a text-format CDR by using the cdr_custom CDR driver.

  • ${CDR(clid}}: Caller ID
  • ${CDR(src}}: Source
  • ${CDR(dst}}: Destination
  • ${CDR(dcontext)}: Destination context
  • ${CDR(channel)}: Channel name
  • ${CDR(dstchannel)}: Destination channel
  • ${CDR(lastapp)}: Last app executed.
  • ${CDR(lastdata)}: Last app's arguments
  • ${CDR(start)}: Time the call started.
  • ${CDR(answer)}: Time the call was answered.
  • ${CDR(end)}: Time the call ended.
  • ${CDR(duration)}: Duration of the call.
  • ${CDR(billsec)}: Duration of the call once it was answered.
  • ${CDR(disposition)}: ANSWERED, NO ANSWER, BUSY.
  • ${CDR(amaflags)}: DOCUMENTATION, BILL, IGNORE etc.
  • ${CDR(accountcode)}: The channel's account code.
  • ${CDR(uniqueid)}: The channel's unique id.
  • ${CDR(userfield)}: The channels uses specified filed.

See also