Identifying CDR Data Generated for Each Call Type

Each type of call creates a set of CDR data records. This section identifies the records that form the set for each type of call. Many types of calls produce multiple CDRs and CMRs. It helps to identify the expected set of records for a given call before processing the data for that call. This section does not provide an exhaustive set of call types and examples. It does, however, contain a representative sample of different types of calls and the records produced. The assumption is made that CDR generation is enabled, and the CDR Log Calls with Zero Duration Flag service parameter is disabled.

Calls Between Two Endpoints

A standard call is a call between two endpoints that does not involve any features. The endpoints can be either phones or gateways. These calls generate one CDR and two CMRs if they are between IP phones or between IP phones and MGCP-controlled gateways. If an endpoint involved in a call is not an IP phone or an MGCP-controlled gateway, no CMR data is written for that endpoint. This section covers the following two topics:

• CDR data for a call between two IP phones
• CDR data for calls involving a gateway

Note

The originalCalledPartyNumber field always contains the same directory number as the finalCalledPartyNumber field in a normal call.

 

CDR Data for a Call Between Two IP Phones

Each normal call between two IP phones logs one CDR at the end of the call. Each CDR contains all fields identified in Table 7-3. Not all fields in a CDR or CMR are used for a given call. If the field is not used, it contains the default value for that field type. CallManager also writes one CMR per endpoint that is involved in the call. In a standard call between two parties that are each using an IP phone, the system writes two CMRs, one each for the originator and the destination of the call. In this case, the call will have a duration greater than 0 seconds, and the originalCalledPartyNumber field and the finalCalledPartyNumber field both contain the same information.

CDR Values for Calls Involving a Gateway

When a call involves a gateway as one of the endpoints, the IP address for that endpoint is the IP address of the gateway, even though the call might not actually terminate there. The call can pass through the gateway to a real endpoint on the PSTN. Calls that involve a gateway have a nonzero value for a span number in one or both of the span fields (origSpan or destSpan). The fields origDeviceName or destDeviceName contain the device names of the terminating devices. Thus, you have the name of the gateway through which the call passed. When you both originate and terminate a call through a gateway, the software writes a nonzero number into both span fields. The span is normally the port or channel on that gateway used for that call. In the case of an H.323 trunk call, the span fields contain the call leg ID for the call leg going through that gateway.

Abandoned Calls

An abandoned call is defined as any call that terminates before it actually connects to a destination. Abandoned calls will always have a duration of 0 seconds, and the origCause_value field indicates why the call was terminated. If the call has any cause termination value that is not a normal call termination (that is, not 0, 16, or 31), the CDR is logged for that call. Abandoned calls do not generate a CMR.

Some ways you can create abandoned calls include the following:

• Take a phone off-hook and place it back on-hook without dialing any digits. (CDR is not normally logged for this call type.)
• Take the phone off-hook and dial a partial or invalid number and then hang up. (CDR is logged.)
• Call a phone where the user did not answer and it was not forwarded. (CDR is logged.)
• Call a busy phone that did not forward on busy. (CDR is logged.)

CallManager does not distinguish between calls that you abandon on purpose and calls that do not connect because of some network or system error condition. If the cause of termination is anything but a normal call termination, the CDR is logged.

Short Calls

A short call is a call with a duration of less than 1 second. It appears as a zero duration call in the CDRs. These can be differentiated from failed calls by the dateTimeConnect field, which shows the actual connect time of the call. For failed calls (which have never connected), this value is zero. If you want to see these calls, you need to enable CDR Log Calls with Zero Duration Flag.

IP Phone Failures During a Call

When an IP phone is unplugged, there is no immediate physical indication to CallManager. CallManager relies on a TCP-based KeepAlive signaling mechanism to detect when an IP phone is disconnected. The KeepAlive interval is normally set to 30 seconds, and for this discussion, it is assumed that the interval is set at its default value.

Every 30 seconds, each IP phone sends a KeepAlive message to CallManager, and CallManager responds with an acknowledgment. Both parties then know that the other is functioning properly. When an IP phone is unplugged, it fails to send this KeepAlive message. CallManager waits for three KeepAlive intervals (by default, this is about 90 seconds) from the time of the last KeepAlive message before assuming that the IP phone is no longer functioning. The implication to billing is that when an IP phone is unplugged, the duration of the call reflected in the CDR can be up to 3 KeepAlive intervals (about 90 seconds) longer than the actual speech time experienced by the user. This value, 90 seconds, is worst-case, assuming that the default KeepAlive interval of 30 seconds is not changed. When two KeepAlives are missed, the call is terminated at the next KeepAlive interval. Calls that fail in this manner might be identified by a cause value of 41 (Temporary Failure). It is possible for this cause value to occur in other circumstances because external devices such as gateways can also generate this cause value.

Forwarded or Redirected Calls

The fields in the CDRs for both forwarded calls and redirected calls are the same as those for normal calls, except for the originalCalledPartyNumber field and the originalCalledPartyNumber Partition field. These two fields contain the directory number and partition of the original destination for this call. When you forward a call, the finalCalledPartyNumber and the finalCalledPartyNumberPartition fields are updated to contain the directory number of the final destination of the call. The lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that forwarded or redirected this call, and the lastRedirectRedirectOnBehalfOf field identifies which feature or entity caused the call to be redirected. In the case of forwarding, the lastRedirectRedirectReason field identifies why the call was forwarded. Features such as conference and call pickup redirect calls to implement the feature operation.

Tip

If the call is forwarded more than one hop, the intermediate forwarding parties are not recorded in the CDR.

 

Precedence Calls (MLPP)

The fields in the CDRs for precedence calls are basically the same as for all other calls of the same type (normal calls, forwarded calls, transferred calls, and so forth). The difference is that the destPrecedenceLevel field or the origPrecedenceLevel field is set. If a call is preempted by a precedence call, the cause codes indicate the reason for the preemption. If a precedence call is preempted by a higher-level precedence call, the cause codes also indicate the reason for the preemption.

Malicious Calls

A malicious call is one where the called party feels threatened in some way. Users identify a call as a malicious call by pressing the MCID softkey. When a call is identified as malicious, CallManager flags the call by including the following string in the Comment field:

 callFlag=MALICIOUS

 

Video Calls

Video calls appear the same as other voice calls of the same type except that the additional video fields contain the video data.

Immediate Divert (to Voice Mail)

CDRs for calls that have been diverted to voice mail using the immediate divert feature (via the iDivert softkey) appear the same as forwarded calls. The origCalledPartyRedirectOnBehalfOf field and the lastRedirectRedirectOnBehalfOf field indicate that a call was redirected on behalf of the immediate divert feature.

Transferred Calls and Examples

Calls that are transferred have additional records logged for them. The three calls that are logged are as follows:

• Original call from party A to party B
• Call from the transferring party (party A or B) to the transfer destination (party C)
• Call from the transferred party (party A or B) to the destination (party C)

If the transfer is a blind transferin which the user did not wait for the transfer destination to answer before completing the transferthe record logged has a duration of 0 seconds and the origCause_Value and destCause_Value fields set to 126 (Call Split).

The following examples are not an exhaustive set and are intended to illustrate the records that are generated under the stated circumstances. The examples help clarify what records are generated on transferred calls, parked calls, and conference calls. These examples assume that you did not enable the CDR Log Calls with Zero Duration Flag service parameter.

Transferred Call Example 1: A Calls B, A Transfers B to C

The call scenario is as follows:

1. A calls B.
2. B answers the call.
3. A presses Transf....
4. A calls C.
5. C answers the call.
6. A presses Transf... again.
7. When B and C are done talking, one or both hang up.

Three CDRs and four CMRs are generated for this call:

• CMR for ALogged when A initiates the transfer.
• Three records are logged when A completes the transfer (second softkey press):

  CDR for call from A to BOriginal call

  CDR for call from A to CConsultative call, where A announces the transfer of B to C

  CMR for A

• Three records are logged when either B or C hangs up:

  CDR for call from B to CActive call after transfer is complete

  CMR for B

  CMR for C

This call is a consultation transfer because the call from A to C was actually connected. The originalCalledPartyNumber and finalCalledPartyNumber field values are the same in the CDRs for this call.

Transferred Call Example 2: A Calls B, B Transfers A to C

The call scenario is as follows:

1. A calls B.
2. B answers the call.
3. B presses Transf... softkey.
4. B calls C.
5. C answers the call.
6. B presses Transf... softkey again.
7. When A and C are done talking, one or both hang up.

Three CDRs and four CMRs are generated for this call. The records logged are

• CMR for BLogged when B presses the Transf... softkey.
• Three records are logged when B presses the Transf... softkey the second time:

  CDR for call from A to BOriginal call

  CDR for call from B to CConsultative call where B announces the transfer of A to C

  CMR for B

• Three records are logged when either A or C hangs up:

  CDR for call from A to CActive call after transfer is complete

  CMR for A

  CMR for C

Transferred Call Example 3: A Calls B, A Transfers B to C on a Blind Transfer

The call scenario is as follows:

1. A calls B.
2. B answers the call.
3. A presses Transf....
4. A calls C.
5. C does not answer yet.
6. A presses Transf... again.
7. C answers the call.
8. When B and C are done talking, one or both hang up.

Three CDRs and four CMRs are generated for this call:

• CMR for ALogged when A pressed the Transf... softkey.
• Three records are logged when A presses the Transf... softkey the second time:

  CDR for call from A to B

  CMR for A

  CDR for call from A to C (zero duration and termination cause of 126 [Call Split])

• Three records are logged when either B or C hangs up:

  CDR for call from B to C

  CMR for B

  CMR for C

Because the call was a blind transfer, the call from A to C has a duration of 0 seconds and the origCause_Value and destCause_Value set to 126 (Call Split). The call is logged because of the Call Split cause code.

Transferred Call Example 4: A Calls B, B Transfers A to C on a Blind Transfer

The call scenario is as follows:

1. A calls B.
2. B answers the call.
3. B presses Transf....
4. B calls C.
5. C does not answer yet.
6. B presses Transf... again.
7. C answers the call.
8. When A and C are done talking, one or both hang up.

Three CDRs and four CMRs are generated for this call:

• CMR for BLogged when B pressed the Transf... softkey.
• Three records are logged when B presses the Transf... softkey the second time:

  CDR for call from A to B

  CMR for B

  CDR for call from B to C (zero duration and termination cause of 126 [Call Split])

• Three records are logged when either A or C hangs up:

  CDR for call from A to C

  CMR for A

  CMR for C

Because the call was a blind transfer, the call from B to C has a duration of 0 seconds and the origCause_Value and destCause_Value set to 126 (Call Split).

Transferred Call Example 5: A Calls B, B Transfers A to C on a Blind Transfer, and C Is Forwarded to D

The call scenario is as follows:

1. Set Call Forward All on phone C to phone D.
2. A calls B.
3. B answers the call.
4. B presses Transf....
5. B calls C (C is forwarded to D).
6. D does not answer yet.
7. B presses Transf... again.
8. D answers the call.
9. When A and D are done talking, one or both hang up.

Three CDRs and four CMRs are generated for this call:

• CMR for BLogged when B pressed the Transf... softkey.
• Three records are logged when B presses the Transf... softkey the second time:

  CDR for call from A to B

  CMR for B

  CDR for call from B to C (which was forwarded to D)

• Three records are logged when either A or D hangs up:

  CDR for call from A to D

  CMR for A

  CMR for D

This call was a blind transfer, and the call from B to C has a duration of 0 seconds and the origCause_Value and destCause_Value set to 126 (Call Split). Because the destination C was forwarded to D, the call logged from A to D will have the originalCalledPartyNumber field set to C, and the finalCalledPartyNumber field set to D.

Parked Call Example: A Calls B, A Parks B, and C Picks Up B

The call scenario is as follows:

1. A calls B.
2. B answers the call.
3. A presses Park (call was parked on a park number).
4. C calls B's park number.
5. When B and C are done talking, one or both hang up.

Two CDRs and three CMRs are generated for a parked call:

• CMR for ALogged when A pressed the Park softkey
• CDR for call from A to B (original call)Logged when A pressed the Park softkey
• Three records are logged when either B or C hangs up:

  CDR for call from C to B (the final call when C picked it up)

  CMR for B

  CMR for C

Conference Calls and Examples

CallManager allows two types of conferencesAd Hoc and Meet-Me. CallManager creates a different set of records for each of these conference types.

Ad Hoc Conference Calls

You can identify the Ad Hoc conference controller by examining the Comment field in the CDR. When a call is involved in more than one conference, it contains multiple sets of conference controller information. This happens, for example, when a conference is reduced to two parties, and one of them starts another conference. When multiple sets exist, the last conference controller information in the CDR identifies the conference controller for the call.

When an Ad Hoc conference call is reduced to two parties, the two parties are connected directly and the conference bridge is released. This results in an additional CDR and up to two additional CMRs for the directly connected call.

Ad Hoc Conference Example: A Calls B, A Calls C, A Sets Up Conference Among A, B, and C

The call scenario is as follows:

1. A calls B.
2. B answers the call.
3. A presses Confrn softkey.
4. A calls C.
5. C answers the call.
6. A presses Confrn again.
7. When A, B, and C are done talking, two or more hang up.

Six CDRs and five CMRs are generated for a three-party Ad Hoc conference:

• CMR for ALogged when A pressed the Confrn softkey.
• CDR for call from A to BLogged when A pressed the Confrn softkey.
• CDR for call from A to CLogged when A pressed the Confrn softkey the second time.
• CMR for ALogged when A pressed the Confrn softkey the second time.
• Six records are logged when the conference is terminated. The CDRs are logged in the order that the participants hang up:

  CDR for call from A to conference bridge

  CDR for call from B to conference bridge

  CDR for call from C to conference bridge

  CDR for call between last two parties when one of the three hangs up

  CMR for A

  CMR for B

  CMR for C

Tip

The last CDR shown in the preceding list is normally generated. The only time it is not generated is when two or more of the last three parties in a conference hang up at the same time. When that occurs, the system terminates the conference without generating the last CDR because the call between the last two parties would not exist in that case.

You can identify the conference controller (A) for this conference call because the Comment field in the CDR contains a string with the following format:

 ConfControllerDn=A;ConfControllerDeviceName=A's device name

If A's DN were 1000 and A's Device Name were SEP0003E333FEBD, the Comment field would contain the following:

 ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD

Calls that are connected to the conference bridge will have the finalCalledPartyNumber field set to a value similar to b0019901001.

In an Ad Hoc conference, each additional participant added causes four additional records to be generated. In this case, the call scenario to add another participant is as follows:

1. A presses Confrn softkey.
2. A calls D.
3. D answers the call.
4. A presses Confrn softkey again (D joins the conference).

Two CDRs and three CMRs would be logged:

• CMR for A when A pressed the Confrn softkey to begin the conference addition
• CDR for call from A to D logged when A pressed the Confrn softkey the second time
• CMR for A when A pressed the Confrn softkey the second time to rejoin the conference
• CDR for call from D to conference bridge logged when the conference is terminated
• CMR for D logged when conference was terminated

Meet-Me Conference Example: A Sets Up Meet-Me Conference, B and C Call into Conference

The call scenario is as follows:

1. A goes off-hook.
2. A presses MeetMe softkey.
3. A dials Meet-Me number (A is connected to the conference).
4. B calls Meet-Me number (B is connected to the conference).
5. C calls Meet-Me number (C is connected to the conference).
6. When A, B, and C are done talking, they hang up.

Three CDRs and three CMRs are generated for a three-party Meet-Me conference. The CDR and CMR for each call into the conference are logged when that participant hangs up. The records are as follows:

• CDR for call from A to Meet-Me conference
• CMR A
• CDR for call from B to Meet-Me conference
• CMR B
• CDR for call from C to Meet-Me conference
• CMR C

For each additional participant in a Meet-Me conference, one CDR is logged and one CMR is logged.

Held Calls Example

This section illustrates what happens when calls are placed on hold and resumed again.

The call scenario is as follows:

1. A calls B.
2. A presses Hold.
3. A presses Resume.
4. A presses Hold.
5. A presses Resume.
6. B presses Hold.
7. B presses Resume.
8. A presses Hold.
9. A presses Resume.
10. B presses Hold.
11. B presses Resume.
12. A or B hangs up.

Held calls create one CMR for each time you put a call on hold. They also create only one CDR for the entire call, which includes the talk time and hold time from the time the call originally connected to the time of the final disconnect. CMRs are generated in order each time a user presses the Hold softkey, and two CMRs are generated at the end of the actual call:

• CMR for AB placed on hold
• CMR for AB placed on hold again
• CMR for BA placed on hold
• CMR for AB placed on hold
• CMR for BA placed on hold
• CDR for call from A to B when A or B hangs up
• CMR for A
• CMR for B

Calls with Busy or Bad Destinations

A call with a busy or bad destination is logged with all relevant fields containing data. Which fields contain data depends on what caused the call to terminate. The destCause_value field contains a cause code indicating why the call was not completed. One CDR is logged and possibly one CMR is logged for each of these calls.

If you abandoned the call without dialing any digits, the cause will be NO_ERROR (0), and the duration will always be 0 seconds. These calls are not logged unless the CDR Log Calls with Zero Duration Flag service parameter is enabled. If the call is logged, one CDR is logged and possibly one CMR is logged.