Cisco Unified Communications Manager Call Detail Records Administration Guide, Release 9.1(1)
CDR Examples
Downloads: This chapterpdf (PDF - 3.08MB) The complete bookPDF (PDF - 4.83MB) | Feedback

CDR Examples

Contents

CDR Examples

This chapter provides examples of the call detail records (CDRs) that the Cisco Unified Communications Manager Release system generates for all call types. You can use this information for post-processing activities such as generating billing records and network analysis.

When you install your system, the system enables CDRs by default. You can enable or disable CDRs at any time that the system is in operation. You do not need to restart Cisco Unified Communications Manager for the change to take effect. The system responds to all changes within a few seconds.

AAC calls

Advanced Audio Coding-Low Delay (AAC-LD) is a super-wideband codec that provides excellent speech and music quality at various bit rates. The audio quality scales up with the bit rate. Two mutually incompatible RTP payload formats are supported: mpeg4-generic and MP4A-LATM.

For AAC-LD (mpeg4-generic) calls, the codec type (payload capability) value 42 is used.

For AAC-LD (MP4A-LATM) calls, a separate codec type value is used for each supported bit rate. The codec type values are 43 (128K), 44 (64K), 45 (56K), 46 (48K), 47 (32K), and 48 (24K).

The system adds an audio bandwidth field to the CDR for AAC-LD calls.

Field Names

Definitions

origMediaCap_bandwidth

This integer field contains the audio bandwidth.

destMediaCap_bandwidth

This integer field contains the audio bandwidth.

The system populates the bandwidth fields based on the following table:

Codec

Bandwidth

G711Alaw64k

64

G711Alaw56k

56

G711mu-law64k

64

G711mu-law56k

56

G722 64k

64

G722 56k

56

G722 48k

48

G7231

7

G728

16

G729

8

G729AnnexA

8

Is11172AudioCap

0

Is13818AudioCap

0

G729AnnexB

8

G729AnnexAwAnnexB

8

GSM Full Rate

13

GSM Half Rate

7

GSM Enhanced Full Rate

13

Wideband 256K

256

Data 64k

64

Data 56k

56

G7221 32K

32

G7221 24K

24

AAC-LD (mpeg4-generic)

256

AAC-LD (MP4A-LATM) 128K

128

AAC-LD (MP4A-LATM) 64K

64

AAC-LD (MP4A-LATM) 56K

56

AAC-LD (MP4A-LATM) 48K

48

AAC-LD (MP4A-LATM) 32K

32

AAC-LD (MP4A-LATM) 24K

24

GSM

13

iLBC

15 or 13

iSAC

32

XV150 MR 729A

8

NSE VBD 729A

8

AAC-LD (mpeg4-generic) calls CDR example

This example applies to a call with AAC-LD (mpeg4-generic) codec:

Field Names

AAC CDR

globalCallID_callId

121

origLegCallIdentifier

101

destLegCallIdentifier

102

callingPartyNumber

51234

originalCalledPartyNumber

57890

finalCalledPartyNumber

57890

lastRedirectDn

57890

origCause_Value

0

dest_CauseValue

16

origMediaCap_payloadCapability

42

origMediaCap_Bandwidth

256

destMediaCap_payloadCapability

42

destMediaCap_Bandwidth

256

Abandoned calls

The logging of calls with zero duration represents an optional action. If logging calls with zero duration is enabled, the following actions occur:

  • All calls generate a CDR.
  • If the call is abandoned, such as when a phone is taken off hook and placed back on hook, various fields do not contain data. In this case, the originalCalledPartyNumber, finalCalledPartyNumber, the partitions that are associated with them, the destIpAddr, and the dateTimeConnect fields all remain blank. All calls that are not connected have a duration of 0 second. When a call is abandoned, the cause code contains 0.
  • If the user dials a directory number and abandons the call before it connects, the FirstDest and FinalDest fields and their associated partitions contain the directory number and the partition to which the call would have been extended. The DestIp field remains blank, and the duration specifies 0 second.

Note


You must enable the CDR Log Calls With Zero Duration Flag service parameter to log calls with zero duration. This parameter enables or disables the logging of CDRs for calls which lasted less than 1 second. See the "Configuring CDR Service Parameters" section in the CDR Analysis and Reporting Administration Guide for more information.


Examples of abandoned calls

  1. Extension 2001 goes off hook, then on hook.

    Field Names

    CDR

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    0

    callingPartyNumber

    2001

    originalCalledPartyNumber

     

    finalCalledPartyNumber

     

    lastRedirectDn

     

    origCause_Value

    16

    dest_CauseValue

    0

    duration

    0

  2. Extension 2001 calls 2309, but 2001 hangs up (abandons) the call before it is answered.

    Field Names

    CDR

    globalCallID_callId

    2

    origLegCallIdentifier

    200

    destLegCallIdentifier

    201

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origCause_Value

    16

    dest_CauseValue

    0

    duration

    0

Ad hoc conference linking

The advanced ad hoc conference linking feature allows you to link multiple ad hoc conferences together by adding an ad hoc conference to another ad hoc conference as if it were an individual participant. You can also use the methods that are available for adding individual participants to an ad hoc conference to add another conference to an ad hoc conference.

CDRs that the advanced ad hoc conference linking feature generates include a field called OrigConversationId. This field associates the conference bridges that are involved in a linked conference. The Comment field of the CDR adds the ConfRequestorDN and ConfRequestorDeviceName tags to indicate add/drop of participants of the conference by a non-controller of the conference.

The following scenarios show some of the various CDRs:

Conference linking using join

The direction of the call between the bridges depends upon which of the two calls that involve Carol is primary. The primary call survives, and the secondary call gets redirected to the conference.

Alice calls Bob, and Bob conferences in Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2). Two separate conferences get created. Carol exists in both conferences. At this point, CDR1, CDR2, CDR3, and CDR4 get generated.

Carol joins the two conferences. At this point, CDR5 gets generated.

When the remaining parties hang up, the remaining CDRs get generated in the order that the parties leave the conference.

Conference linking using join example

Field Names

CDR1: Alice -> Bob (original call)

CDR2: Bob -> Carol (consultation call)

CDR3: Dave -> Carol (original call)

CDR4: Dave -> Ed (consultation call)

CDR5: Carol -> Conference Bridge (conference call)

CDR6: Dave -> Conference Bridge (conference call)

globalCallID_callId

1

2

3

4

3

3

origLegCallIdentifier

11

13

21

23

22

22

destLegCallIdentifier

12

14

22

24

25

26

callingPartyNumber

1000

1001

1003

1003

1002

1003

originalCalledPartyNumber

1001

1002

1002

1004

b0029901222

b0029901222

finalCalledPartyNumber

1001

1002

1002

1004

b0029901222

b0029901222

lastRedirectDn

1001

1002

1002

1004

1003

1003

origTerminationOnBehalfOf

4

4

4

4

4

4

destTerminationOnBehalfOf

4

4

4

4

4

4

lastRedirectRedirectReason

0

0

0

0

98

98

lastRedirectRedirectOnBehalfOf

0

0

0

0

4

4

origConversationID

0

0

0

0

0

0

destConversationID

0

0

0

0

2222

2222

Comment

       
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Field Names

CDR7: Dave -> Conference Bridge (conference call)

CDR8: Ed -> Conference Bridge (conference call)

CDR9: Conference Bridge (conference call)

CDR10: Alice -> Conference Bridge (conference call)

CDR11: Bob -> Conference Bridge (conference call)

globalCallID_callId

3

3

1

1

1

origLegCallIdentifier

21

24

17

11

12

destLegCallIdentifier

26

27

28

15

16

callingPartyNumber

1003

1004

b0029901001

1000

1001

originalCalledPartyNumber

b0029901222

b0029901222

b0029901222

b0029901001

b0029901001

finalCalledPartyNumber

b0029901222

b0029901222

b0029901222

b0029901001

b0029901001

lastRedirectDn

1003

1003

1002

1001

1001

origTerminationOnBehalfOf

0

0

0

0

0

destTerminationOnBehalfOf

0

0

0

0

0

lastRedirectRedirectReason

98

98

4

98

98

lastRedirectRedirectOnBehalfOf

4

4

10

4

4

origConversationID

0

0

0

0

0

destConversationID

2222

2222

2222

2222

2222

Comment

ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD

Conference linking using transfer or Direct Transfer

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol and conferences in Ed (Conference 2). Two separate conferences get created; Carol exists in both conferences. At this point, CDR1, CDR2, CDR3, and CDR4 get generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob exist in Conference 1 while Dave and Ed are in Conference 2. When the remaining parties hang up, the remaining CDRs get generated in the order in which the parties leave the conference.


Note


The direction of the call between the bridges depends on which of the two calls that involve Carol is the primary call. The primary call side represents the calling party of the transferred call.


Conference linking using transfer or Direct Transfer example

Field Names

CDR1: Alice -> Bob (original call)

CDR2: Bob -> Carol (consultation call)

CDR3: Dave -> Carol (original call)

CDR4: Dave -> Carol (consultation call)

CDR5: Carol -> Conference Bridge (conference call)

CDR6: Carol -> Conference Bridge (conference call)

globalCallID_callId

1

2

3

4

1

3

origLegCallIdentifier

11

13

21

23

14

22

destLegCallIdentifier

12

14

22

24

17

25

callingPartyNumber

1000

1001

1003

1003

1002

1003

originalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

finalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

lastRedirectDn

1001

1002

1002

1004

1001

1003

origTerminationOnBehalfOf

4

4

4

4

10

10

destTerminationOnBehalfOf

4

4

4

4

10

10

lastRedirectRedirectReason

0

0

0

0

98

98

lastRedirectRedirectOnBehalfOf

0

0

0

0

4

4

origConversationID

0

0

0

0

0

0

destConversationID

0

0

0

0

1111

2222

Comment

       
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Field Names

CDR7: Dave -> Conference Bridge (conference call)

CDR8: Ed -> Conference Bridge (conference call)

CDR9: Conference Bridge (conference call)

CDR10: Alice -> Conference Bridge (conference call)

CDR11: Bob -> Conference Bridge (conference call)

globalCallID_callId

3

3

1

1

1

origLegCallIdentifier

21

24

17

11

12

destLegCallIdentifier

26

27

28

15

16

callingPartyNumber

1003

1004

b0029901001

1000

1001

originalCalledPartyNumber

b0029901222

b0029901222

b0029901222

b0029901001

b0029901001

finalCalledPartyNumber

b0029901222

b0029901222

b0029901222

b0029901001

b0029901001

lastRedirectDn

1003

1003

1002

1001

1001

origTerminationOnBehalfOf

0

0

0

0

0

destTerminationOnBehalfOf

0

0

0

0

0

lastRedirectRedirectReason

98

98

4

98

98

lastRedirectRedirectOnBehalfOf

4

4

10

4

4

origConversationID

0

0

111

0

0

destConversationID

2222

2222

2222

1111

1111

Comment

ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD

Linked conference party removal

CDRs get generated in the order in which the parties leave a conference. When the remaining conference only has two parties, the two parties get joined directly together.

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2). Two separate conferences get created; Carol participates in both conferences. At this point, CDR1, CDR2, CDR3, and CDR4 get generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob exist in Conference 1 while Dave and Ed are in Conference 2. Conference 1 and Conference 2 get transferred together. Carol hangs up and leaves only two parties in Conference 1.

Because only two parties exist in the conference, Bob and the conference link get joined together. At this point, CDR7, CDR8, and CDR9 get generated. Because Bob is the controller in Conference 1, Bob represents the calling party in the call between Bob and Conference 2. When the remaining parties hang up, the remaining CDRs get generated in the order in which the parties leave the conference.


Note


If Bob is not a controller and the chaining occurs before Bob joins Conference 1, the call between Bob and Conference 2 gets generated in the opposite direction from what is shown in the CDRs.


The direction of the call between the final two parties of a conference depends on who has been in the conference the longest. The party that has been in the conference the longest becomes the calling party.

Removing a Party from a Linked Conference Example

Field Names

CDR1: Alice -> Bob (original call)

CDR2: Bob -> Carol (consultation call)

CDR3: Dave -> Carol (original call)

CDR4: Dave -> Carol (consultation call)

CDR5: Carol -> Conference Bridge (conference call)

CDR6: Carol -> Conference Bridge (conference call)

globalCallID_callId

1

2

3

4

1

3

origLegCallIdentifier

11

13

21

23

14

22

destLegCallIdentifier

12

14

22

24

17

25

callingPartyNumber

1000

1001

1003

1003

1002

1002

originalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

finalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

lastRedirectDn

1001

1002

1002

1004

1001

1003

origTerminationOnBehalfOf

4

4

4

4

10

10

destTerminationOnBehalfOf

4

4

4

4

10

10

lastRedirectRedirectReason

0

0

0

0

98

98

lastRedirectRedirectOnBehalfOf

0

0

0

0

4

4

origConversationID

0

0

0

0

0

0

destConversationID

0

0

0

0

1111

2222

Comment

       
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Field Names

CDR7: Alice -> Conference Bridge (conference call)

CDR8: Bob -> Conference Bridge (conference call)

CDR9: Conference Bridge -> Conference Bridge

CDR10: Bob -> Conference Bridge (conference call)

CDR11: Dave -> Conference Bridge (conference call)

CDR12: Ed -> Conference Bridge (conference call)

globalCallID_callId

1

1

3

3

3

3

origLegCallIdentifier

11

12

25

11

12

24

destLegCallIdentifier

15

16

28

15

16

27

callingPartyNumber

1001

1001

b0029901222

1000

1001

1003

originalCalledPartyNumber

b0029901001

b0029901001

b0029901001

b0029901222

b0029901222

b0029901222

finalCalledPartyNumber

b0029901001

b0029901001

b0029901001

b0029901222

b0029901222

b0029901222

lastRedirectDn

1001

1001

1002

b0029901001

1003

1003

origTerminationOnBehalfOf

16

4

4

4

0

0

destTerminationOnBehalfOf

0

4

4

4

0

0

lastRedirectRedirectReason

98

98

4

98

98

98

lastRedirectRedirectOnBehalfOf

4

4

10

4

4

4

origConversationID

0

0

2222

0

0

0

destConversationID

1111

1111

1111

2222

2222

2222

Comment

ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Linked conference party (controller) removal

CDRs get generated in the order in which the parties leave a conference. When the remaining conference only has two parties, these two parties get joined directly together.

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol and conferences in Ed (Conference 2). Two separate conferences get created; Carol participates in both conferences. At this point, CDR1, CDR2, CDR3, and CDR4 get generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob exist in Conference 1, while Dave and Ed are in Conference 2. Conference 1 and Conference 2 get transferred together. Bob hangs up which leaves only two parties that are connected to Conference 1.

Because only two parties exist in Conference1, Alice and the conference link get joined directly together. At this point, CDR7, CDR8, and CDR9 get generated. Because Alice has been in the conference longer, she becomes the calling party in the call between Alice and Conference 2. When the remaining parties hang up, the remaining CDRs get generated in the order in which the parties leave the conference.


Note


The direction of a call between the final two parties of a conference depends on who has been in the conference the longest. The party that has been in the conference the longest becomes the calling party.


Removing a controller from a linked conference example

Field Names

CDR1: Alice -> Bob (original call)

CDR2: Bob -> Carol (consultation call)

CDR3: Dave -> Carol (original call)

CDR4: Dave -> Carol (consultation call)

CDR5: Carol -> Conference Bridge (conference call)

CDR6: Carol -> Conference Bridge (conference call)

globalCallID_callId

1

2

3

4

1

3

origLegCallIdentifier

11

13

21

23

14

22

destLegCallIdentifier

12

14

22

24

17

25

callingPartyNumber

1000

1001

1003

1003

1002

1002

originalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

finalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

lastRedirectDn

1001

1002

1002

1004

1001

1003

origTerminationOnBehalfOf

4

4

4

4

10

10

destTerminationOnBehalfOf

4

4

4

4

10

10

lastRedirectRedirectReason

0

0

0

0

98

98

lastRedirectRedirectOnBehalfOf

0

0

0

0

4

4

origConversationID

0

0

0

0

0

0

destConversationID

0

0

0

0

1111

2222

Comment

       
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Field Names

CDR7: Conference Bridge -> Conference Bridge

CDR8: Alice -> Conference Bridge (conference call)

CDR9: Conference Bridge -> Conference Bridge

CDR10: Alice -> Conference Bridge (conference call)

CDR11: Dave -> Conference Bridge (conference call)

CDR12: Ed -> Conference Bridge (conference call)

globalCallID_callId

1

1

3

3

3

3

origLegCallIdentifier

12

11

25

11

21

24

destLegCallIdentifier

16

15

28

25

26

27

callingPartyNumber

1001

1000

b0029901001

1001

1003

1004

originalCalledPartyNumber

b0029901001

b0029901001

b0029901001

b0029901222

b0029901222

b0029901222

finalCalledPartyNumber

b0029901001

b0029901001

b0029901001

b0029901222

b0029901222

b0029901222

lastRedirectDn

1001

1001

1002

b0029901001

1003

1003

origTerminationOnBehalfOf

4

16

4

4

0

0

destTerminationOnBehalfOf

4

0

4

4

0

0

lastRedirectRedirectReason

98

98

4

98

98

98

lastRedirectRedirectOnBehalfOf

4

4

10

4

4

4

origConversationID

0

0

2222

0

0

0

destConversationID

1111

1111

1111

2222

2222

2222

Comment

ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Linked conference removal

Alice calls Bob, and Bob conferences Carol (Conference 1). Dave calls Carol, and conferences in Ed (Conference 2). Two separate conferences get created; Carol participates in both conferences. At this point, CDR1, CDR2, CDR3, and CDR4 get generated.

Carol presses the Direct Transfer (DirTrfr) softkey on the call to the first conference. Alice and Bob exist in Conference 1, while Dave and Ed are in Conference 2. Conference 1 and Conference 2 get transferred together.

Bob presses the ConfList softkey and has Alice, Bob, and the conference link "Conference" shown in the list. Bob selects "Conference" and presses the Remove softkey. At this point, CDR7, CDR8, and CDR9 get generated. The conference link gets removed, which leaves two parties in the conference.

The remaining two parties get joined together. In Conference 1, Alice and Bob get joined together, and in Conference 2, Dave and Ed get joined together. When the remaining parties hang up, the remaining CDRs get generated in the order in which the parties leave the conference.

Removing the linked conference example

Field Names

CDR1: Alice -> Bob (original call)

CDR2: Bob -> Carol (consultation call)

CDR3: Dave -> Carol (original call)

CDR4: Dave -> Carol (consultation call)

CDR5: Carol -> Conference Bridge (conference call)

CDR6: Carol -> Conference Bridge (conference call)

globalCallID_callId

1

2

3

4

1

3

origLegCallIdentifier

11

13

21

23

14

22

destLegCallIdentifier

12

14

22

24

17

25

callingPartyNumber

1000

1001

1003

1003

1002

1002

originalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

finalCalledPartyNumber

1001

1002

1002

1004

b0029901001

b0029901222

lastRedirectDn

1001

1002

1002

1004

1001

1003

origTerminationOnBehalfOf

4

4

4

4

10

10

destTerminationOnBehalfOf

4

4

4

4

10

10

lastRedirectRedirectReason

0

0

0

0

98

98

lastRedirectRedirectOnBehalfOf

0

0

0

0

4

4

origConversationID

0

0

0

0

0

0

destConversationID

0

0

0

0

1111

2222

Comment

       
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Field Names

CDR7: Conference Bridge -> Conference Bridge

CDR8: Alice -> Conference Bridge (conference call)

CDR9: Bob -> Conference Bridge

CDR10: Dave -> Conference Bridge (conference call)

CDR11: Ed -> Conference Bridge (conference call)

CDR12: Bob-> Alice

globalCallID_callId

3

1

1

3

3

3

origLegCallIdentifier

25

11

12

21

24

21

destLegCallIdentifier

28

15

16

26

27

24

callingPartyNumber

b0029901222

1000

1001

1003

1004

1003

originalCalledPartyNumber

b0029901001

b0029901001

b0029901001

b0029901222

b0029901222

b0029901222

finalCalledPartyNumber

b0029901001

b0029901001

b0029901001

b0029901222

b0029901222

1004

lastRedirectDn

1002

1001

1001

1003

1003

b0029901222

origTerminationOnBehalfOf

4

4

4

16

0

0

destTerminationOnBehalfOf

4

4

4

0

0

0

lastRedirectRedirectReason

4

98

98

98

98

98

lastRedirectRedirectOnBehalfOf

10

4

4

4

4

4

origConversationID

0

0

0

0

0

0

destConversationID

1111

1111

1111

2222

2222

0

Comment

ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1001;Co
nfController
DeviceName=S
EP0003E333FE
BD;ConfReque
storDn-1001;
ConfRequesto
rDeviceName=
SEP0003E333F
EBD
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1
ConfControll
erDn=1003;Co
nfController
DeviceName=S
EP0003E333FA
D1;ConfReque
storDn-1003;
ConfRequesto
rDeviceName=
SEP0003E333F
AD1

Field Names

CDR13: Dave -> Ed

globalCallID_callId

3

origLegCallIdentifier

21

destLegCallIdentifier

24

callingPartyNumber

1003

originalCalledPartyNumber

b0029901222

finalCalledPartyNumber

1004

lastRedirectDn

b0029901222

origTerminationOnBehalfOf

0

destTerminationOnBehalfOf

0

lastRedirectRedirectReason

98

lastRedirectRedirectOnBehalfOf

4

origConversationID

0

destConversationID

0

Comment

ConfControllerDn=10
03;ConfControllerDe
viceName=SEP0003E33
3FAD1;ConfRequestor
Dn-1003;ConfRequest
orDeviceName=SEP000
3E333FAD1

Agent greeting calls

The Agent Greeting call feature instructs Cisco Unified Communications Manager to play a prerecorded announcement to the customer automatically after successful media connection to the agent device occurs. Both the agent and the customer hear the Agent Greeting.

Example of an agent greeting call

  1. The customer (1001) calls the agent (1006).
  2. The agent (1006) answers the call. The customer and the agent connect.
  3. The Agent Greeting call feature instructs Cisco Unified Communications Manager to play a prerecorded announcement to the customer automatically after successful media connection to the agent device occurs. This causes an IVR (1000) to connect to the Built-In Bridge (BIB) of agent phone. Both the agent and the customer hear the Agent Greeting.
  4. The customer-agent call ends. A CDR gets generated for the customer-to-agent call. A CDR gets generated for the IVR (1000) to BIB of agent phone.

The CDR for the IVR to agent BIB specifies the comment AgentGreeting=<agentCI>. The OnBehalfOf field is set to 33 and redirectReason code is set to 752 for Agent Greeting call.

Field Names

Call From Customer to Agent

Call From IVR to Agent BIB

globalCallID_callId

270001

270002

origLegCallIdentifier

22980857

22980861

destLegCallIdentifier

22980858

22980862

callingPartyNumber

1001

1000

originalCalledPartyNumber

1006

b00121104001

finalCalledPartyNumber

1006

b00121104001

origCallTerminationOnBehalfOf

12

0

destCallTerminationOnBehalfOf

0

33

origCalledPartyRedirectOnBehalfOf

0

33

lastRedirectRedirectOnBehalfOf

0

33

origCalledPartyRedirectReason

0

752

lastRedirectRedirectReason

0

752

destConversationId

0

22980858

joinOnBehalfOf

33

comment

AgentGreeting=22980858

duration

23

9

Barge

When a shared line uses the barge feature, the origCalledPartyNumber, finalCalledPartyNumber, and lastRedirectDn represent the conference bridge number 'b00. . .'. The redirect and join OnBehalfOf fields reflect a value of Barge = 15, and the redirect reason fields specify Barge = 114.

Barge examples

  1. 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40003 hangs up.

    Note


    Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.


    Field Names

    Original Call CDR

    Barge Call CDR

    globalCallID_callId

    7

    7

    origLegCallIdentifier

    16777230

    16777232

    destLegCallIdentifier

    16777231

    16777235

    callingPartyNumber

    40003

    40003

    origCalledPartyNumber

    40001

    b001501001

    finalCalledPartyNumber

    40001

    b001501001

    lastRedirectDn

    40001

    b001501001

    origCause_Value

    16

    0

    dest_CauseValue

    0

    0

    origCalledPartyRedirectReason

    0

    114

    lastRedirectRedirectReason

    0

    114

    origCalledPartyRedirectOnBehalfOf

     

    15

    lastRedirectRedirectOnBehalfOf

     

    15

    joinOnBehalfOf

     

    15

    destConversationID

    0

    16777231

  2. 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40001 hangs up.

    Note


    Both CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.


    Field Names

    Original Call CDR

    Barge Call 1 CDR

    Final Call 2 CDR

    globalCallID_callId

    9 9 9

    origLegCallIdentifier

    16777236

    16777238

    16777236

    destLegCallIdentifier

    16777237

    16777241

    16777238

    callingPartyNumber

    40003

    40001

    40003

    origCalledPartyNumber

    40001

    b001501001

    40001

    finalCalledPartyNumber

    40001

    b001501001

    40001

    lastRedirectDn

    40001

    b001501001

    40001

    origCause_Value

    0

    393216

    16

    dest_CauseValue

    16

    393216

    0

    origCalledPartyRedirectReason

    0

    114

    0

    lastRedirectRedirectReason

    0

    114

    0

    origTerminationOnBehalfOf

     

    15

    12

    destTerminationOnBehalfOf

    12

    15

    12

    lastRedirectRedirectOnBehalfOf

     

    15

     

    joinOnBehalfOf

     

    15

     

    destConversationID

    0

    16777237

    0

  3. 40003 calls 40001, and 40001 answers. Shared line 40001' on another phone presses the Barge softkey. All the parties get conferenced together; then, 40001' (another shared line and phone) presses the Barge softkey. 40003 hangs up first.

    Note


    All CDRs have the same globalCallID_callId, and the conversationID field links back to the CI (call Identifier) of the barged call.


    Field Names

    Original Call CDR

    Barge Call 1 CDR

    Final Call 2 CDR

    globalCallID_callId

    14 14 14

    origLegCallIdentifier

    16777249

    16777251

    16777255

    destLegCallIdentifier

    16777250

    16777254

    16777258

    callingPartyNumber

    40003

    40001

    40001

    origCalledPartyNumber

    40001

    b001501001

    b001501001

    finalCalledPartyNumber

    40001

    b001501001

    b001501001

    lastRedirectDn

    40001

    b001501001

    b001501001

    origCause_Value

    16

    0

    0

    dest_CauseValue

    0

    0

    0

    origCalledPartyRedirectReason

    0

    114

    114

    lastRedirectRedirectReason

    0

    114

    114

    origTerminationOnBehalfOf

    12

    15

    15

    destTerminationOnBehalfOf

         

    origRedirectRedirectOnBehalfOf

     

    15

    15

    lastRedirectRedirectOnBehalfOf

     

    15

    15

    joinOnBehalfOf

     

    15

    15

    destConversationID

    0

    16777250

    16777251

Call monitoring

The system generates CDRs for the Call Monitoring feature by using existing CDR fields.

The monitoring calls have one-way media. The media fields stay empty for one side of the call for one-way media CDRs.

The destConversationID field of the Call Monitoring CDR matches the agent call leg identifier in the CDR of the call that is monitored and links together the Call Monitoring CDR and the CDR of the monitored call.

Call monitoring examples

  1. The customer (9728134987) calls the agent (30000), and the agent answers. The supervisor (40003) monitors the call. The destConversationID from the monitoring call matches the destLegCallIdentifier of the monitored call.

    Field Names

    Monitored Call CDR

    Monitoring Call CDR

    globalCallID_callId

    7

    10

    origLegCallIdentifier

    16777230

    16777232

    destLegCallIdentifier

    16777231

    16777235

    callingPartyNumber

    9728134987

    40003

    originalCalledPartyNumber

    30000

    b001501001

    finalCalledPartyNumber

    30000

    b001501001

    lastRedirectDn

    30000

    b001501001

    origCause_Value

    16

    0

    dest_CauseValue

    0

    0

    origCalledPartyRedirectReason

    0

    370

    lastRedirectRedirectOnBehalfOf

    0

    370

    origCalledPartyRedirectOnBehalfOf

     

    28

    lastRedirectRedirectOnBehalfOf

     

    28

    destConversationID

    0

    16777231

  2. The agent (30000) calls the customer (9728134987), and the customer answers. The supervisor (40003) monitors the call. The destConversationID from the monitoring call matches the origLegCallIdentifier of the monitored call.

    Field Names

    Monitored Call CDR

    Monitoring Call CDR

    globalCallID_callId

    71

    101

    origLegCallIdentifier

    16777299

    16777932

    destLegCallIdentifier

    16777300

    16777235

    callingPartyNumber

    30000

    40003

    originalCalledPartyNumber

    9728134987

    b001501002

    finalCalledPartyNumber

    9728134987

    b001501002

    lastRedirectDn

    9728134987

    b001501002

    origCause_Value

    16

    0

    dest_CauseValue

    0

    0

    origCalledPartyRedirectReason

    0

    370

    lastRedirectRedirectOnBehalfOf

    0

    370

    origCalledPartyRedirectOnBehalfOf

     

    28

    lastRedirectRedirectOnBehalfOf

     

    28

    destConversationID

    0

    16777299

Call park

Call Park generates two CDRs, one for the original call that gets parked and another for the call that gets picked up or reverted. These CDRs will have the same globalCallID_callId.

Call park pickup

When the call is parked, the call gets split. The original call generates a CDR. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR.

When the parked call gets retrieved, the user goes off hook and enters the park code. This call joins with the parked call. Because the user who is picking up the call gets joined with the parked call, the system treats the user as the originator of the call, and the parked user gets treated as the destination. This means that the callingPartyNumber field of the call contains the directory number of the user who is picking up the call, and the originalCalledNumber and finalCalledNumber fields contain the directory number of the parked user. The lastRedirectDn field contains the park code that is used to pick up the call. The lastRedirectRedirectReason field specifies Call Park Pickup = 8. The lastRedirectRedirectOnBehalfOf field should specify Call Park = 3.

Call park pickup CDR example

50003 calls 50002; 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code (44444).

Field Names

Original Call That Is Parked CDR

Parked Call That Is Picked Up CDR

globalCallID_callId

1

1

origLegCallIdentifier

20863957

20863961

destLegCallIdentifier

20863958

20863957

callingPartyNumber

50003

50001

originalCalledPartyNumber

50002

50003

finalCalledPartyNumber

50002

50003

lastRedirectDn

50002

44444

origCause_Value

393216

0

dest_CauseValue

393216

16

origCalledPartyRedirectReason

0

0

lastRedirectRedirectReason

0

8

origCalledPartyRedirectOnBehalfOf

0

0

lastRedirectRedirectOnBehalfOf

0

3

origTerminationOnBehalfOf

3

0

destTerminationOnBehalfOf

3

12

joinOnBehalfOf

0

3

duration

4

60

Call park reversion

When a call is parked and not picked up, the call park reversion timer expires and redirects the call to the called party. In this case, the system generates two CDRs. The first CDR appears the same as the preceding Call Park Pickup scenario, but the second CDR differs slightly. When the Call Pickup Reversion timer expires, the call gets redirected to the called party.

When the call is parked, the call gets split. This action generates a CDR for the original call. The origTerminationOnBehalfOf and destTerminationOnBehalfOf fields get set to Call Park = 3 for this CDR, the same as the Call Park Pickup scenario.

When the Call Park Reversion timer expires, the call gets redirected to the called party. The origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields specify Call Park = 3. The origCalledPartyRedirectReason field specifies Call Park = 7, and the lastRedirectRedirectReason field specifies Call Park Reversion = 11.

Call park reversion CDR example
  • Call Park Reversion Example – 50003 calls 50002; 50002 presses the Park softkey. Nobody picks up the parked call; the parked call reverts to 50002, and 50002 answers.

Field Names

Original Call That Is Parked CDR

Reverted Call CDR

globalCallID_callId

2

2

origLegCallIdentifier

20863963

20863963

destLegCallIdentifier

20863964

20863967

callingPartyNumber

50003

50003

originalCalledPartyNumber

50002

50002

finalCalledPartyNumber

50002

50002

lastRedirectDn

50002

50002

origCause_Value

393216

0

dest_CauseValue

393216

16

origCalledPartyRedirectReason

0

7

lastRedirectRedirectReason

0

11

origCalledPartyRedirectOnBehalfOf

0

3

lastRedirectRedirectOnBehalfOf

0

3

origTerminationOnBehalfOf

3

3

destTerminationOnBehalfOf

3

12

joinOnBehalfOf

0

3

duration

7

60

Call pickup

There are two types of call pickup in Cisco Unified Communications Manager: Pickup and Auto Pickup. The CDR records appear slightly different for these two types of call pickup.

Pickup

Pickup CDR example

A call comes in from the PSTN to extensions 2000, 2001, and 2002. These extensions reside in the same pickup group. Extension 2002 picks up the call that is ringing on 2001. Extension 2002 answers the call, and the call connects between the PSTN caller and extension 2002.

Field Names

Pickup Call CDR

globalCallID_callId

22

callingPartyNumber

9728131234

originalCalledPartyNumber

2001

finalCalledPartyNumber

2002

lastRedirectDn

2001

origCause_Value

0

dest_CauseValue

16

origTerminationOnBehalfOf

16

destTerminationOnBehalfOf

16

lastRedirectOnBehalfOf

16

lastRedirectReason

5

joinOnBehalfOf

16

Auto pickup

Auto Pickup acts like call pickup with auto answer. The user does not need to press the last answer softkey. The call automatically connects. Two CDRs get generated for Auto Pickup. These CDRs have the same Call ID.

  • The first CDR gets generated for the original call. This CDR will have the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields equal to 16 (Pickup). This value indicates that the call got terminated on behalf of the Pickup feature.
  • The second CDR represents the final call after it was picked up. This CDR will have the lastRedirectOnBehalfOf and the joinOnBehalfOf fields set to 16 (Pickup). This value indicates that the call was joined on behalf of the Pickup feature. The lastRedirectReason contains the redirect reason of 5 (Pickup).

Auto Pickup CDRs look the same for all types of auto pickup: Auto Pickup, Auto Group Pickup and Auto Other Pickup.


Note


When the Service Parameter Auto Call Pickup Enabled is set to True for an IP Phone and a Cisco Unified Communications Manager receives an incoming call that the IP phone picks up, the prefix digit defined in the Translation Pattern is added to the callingPartyNumber in CDR. However, the prefix digit is not added when the Service Parameter Auto Call Pickup Enabled is set to False.


Auto pickup CDR example
  • Auto Pickup Example - Call goes from the PSTN to extension 2001; 2001 and 2002 exist in the same pickup group. 2002 picks up the call that rings on 2001; the call automatically connects between the PSTN caller and 2002. They talk for 2 minutes.

    Note


    The prefix digits defined in the Translation Pattern only applies to basic call.


Field Names

Original Call CDR

Pickup CDR

globalCallID_callId

11

11

origLegCallIdentifier

12345

12345

destLegCallIdentifier

12346

12347

callingPartyNumber

9728134987

9728134987

originalCalledPartyNumber

2001

2001

finalCalledPartyNumber

2001

2002

lastRedirectDn

2001

2001

origCause_Value

393216

16

dest_CauseValue

393216

0

origTerminationOnBehalfOf

16

12

destTerminationOnBehalfOf

16

16

lastRedirectRedirectReason

0

5

lastRedirectRedirectOnBehalfOf

0

16

joinOnBehalfOf

0

16

duration

0

120

Call recording

The system generates CDRs for the Call Recording feature by using existing CDR fields.

The recording calls have one-way media. The media fields stay empty for one side of the call for one-way media CDRs.

The origConversationID field of the two Call Recording CDRs matches the agent call leg identifier in the Recording Call CDR and links together the Call Recording CDR and the CDR of the recorded call.

Call recording CDR examples

  1. The customer (9728134987) calls the agent (30000), and the agent answers. The Recorder's DN is 90000. The recording feature creates two recording calls to the recording device, which results in two additional CDRs: one for the agent voice, and another for the customer voice. The origConversationID from the recording CDRs matches the destLegCallIdentifier of the recorded CDR. In this scenario, the customer hangs up.

    Field Names

    Monitored Call CDR

    Monitoring Call CDR

    globalCallID_callId

    7

    10

    origLegCallIdentifier

    16777110

    16777120

    destLegCallIdentifier

    16777111

    16777121

    callingPartyNumber

    9728134987

    30000

    originalCalledPartyNumber

    30000

    90000

    finalCalledPartyNumber

    30000

    90000

    lastRedirectDn

    30000

    90000

    origCause_Value

    16

    0

    dest_CauseValue

    0

    0

    origCalledPartyRedirectReason

    0

    354

    lastRedirectRedirectOnBehalfOf

    0

    354

    origCalledPartyRedirectOnBehalfOf

     

    27

    lastRedirectRedirectOnBehalfOf

     

    27

    origConversationID

    0

    16777111

  2. The agent (30000) calls the customer (9728134987), and the customer answers. The Recorder's DN is 90000. The recording feature creates two recording calls to the recording device, which results in two additional CDRs: one for the agent voice, and another for the customer voice. The origConversationID field from the recording CDRs will match the origLegCallIdentifier field of the recorded CDR. In this scenario, the agent hangs up.

    Field Names

    Monitored Call CDR

    Monitoring Call CDR

    globalCallID_callId

    71

    100

    origLegCallIdentifier

    16777113

    16777220

    destLegCallIdentifier

    16777114

    16777221

    callingPartyNumber

    30000

    30000

    originalCalledPartyNumber

    9728134987

    90000

    finalCalledPartyNumber

    9728134987

    90000

    lastRedirectDn

    9728134987

    90000

    origCause_Value

    16

    16

    dest_CauseValue

    0

    0

    origCalledPartyRedirectReason

    0

    354

    lastRedirectRedirectOnBehalfOf

    0

    354

    origCalledPartyRedirectOnBehalfOf

     

    27

    lastRedirectRedirectOnBehalfOf

     

    27

    origConversationID

    0

    16777113

Call secured status

This field identifies security status of the call. It contains the highest level of security that is reached during a call. For example, if the call is originally unsecured, and later the call changes to secured, the CDR contains 1 for "Secured" even though different portions of the call have different status values. The callSecuredStatus field identifies the security status of the call.

Call secured status CDR examples

  1. Encrypted Call - The system encrypts the call between 20000 and 20001. The parties talk for 5 minutes.

    Field Names

    CDR

    globalCallID_callId

    102

    origLegCallIdentifier

    16777140

    destLegCallIdentifier

    16777141

    callingPartyNumber

    20000

    origCalledPartyNumber

    20001

    finalCalledPartyNumber

    20001

    lastRedirectDn

    20001

    origCause_Value

    0

    dest_CauseValue

    16

    callSecuredStatus

    2

    duration

    300

  2. Authenticated Call - The call between 20000 and 20001 gets authenticated (not encrypted). The parties talk for 10 minutes.

    Field Names

    CDR

    globalCallID_callId

    103

    origLegCallIdentifier

    16777142

    destLegCallIdentifier

    16777143

    callingPartyNumber

    20000

    origCalledPartyNumber

    20001

    finalCalledPartyNumber

    20001

    lastRedirectDn

    20001

    origCause_Value

    0

    dest_CauseValue

    16

    callSecuredStatus

    1

    duration

    600

Calling party normalization

This feature provides the support of the international escape code "+" to Cisco Unified Communications Manager. This addition enhances the dialing capabilities of dual-mode phones and improves callbacks for companies in different geographical locations.

The callingPartyNumber, originalCalledPartyNumber, finalCalledPartyNumber, lastRedirectDN fields, and the new fields, outpulsedCallingPartyNumber and outpulsedCalledPartyNumber, may now contain a "+" in the CDR. The device reports the Calling Party Number that it outpulsed back to Call Control only if calling party normalization/localization takes place. If calling party normalization/localization occurs, the action gets recorded in the CDR in the new field outpulsedCallingPartyNumber.

Calling party normalization CDR examples

  1. A call gets placed from a Dallas PSTN to an enterprise phone. The 7-digit calling number comprises 500 1212; the Dallas area code displays 972. The calling party transformation contains +1972. The callingPartyNumber field in the CDR contains +1 972 500 1212 (global format). The new field outpulsedCallingPartyNumber contains the localized number 500 1212.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    +19725001212

    outpulsedCallingPartyNumber

    5001212

    duration

    60

  1. A call gets placed from an enterprise phone to a Dallas PSTN. The extension of the enterprise phone comprises 12345; the fully qualified number comprises 9725002345. Calling party transformation checks the external phone number mask feature. The callingPartyNumber field in the CDR contains +1 972 500 2345 (global format). The new field outpulsedCallingPartyNumber contains the localized number 9725002345.

    Field Names

    Values

    globalCallID_callId

    2

    origLegCallIdentifier

    102

    destLegCallIdentifier

    103

    callingPartyNumber

    +19725002345

    outpulsedCallingPartyNumber

    9725002345

    duration

    60

Calls with busy or bad destinations

The system logs all these calls as normal calls, and all relevant fields contain data. The Calling or Called Party Cause fields contain a cause code that indicates why the call does not connect, and the Called Party IP and Date/Time Connect fields remain blank. The system logs all unsuccessful calls, even if zero duration calls are not being logged (CdrLogCallsWithZeroDurationFlag set at True or False, a duration of zero, and a DateTimeConnect value of zero).

Examples of unsuccessful calls CDRs

  1. Call goes to PSTN number, but party already is engaged (cause 17 = user busy)

    Field Names

    CDR

    globalCallID_callId

    3

    origLegCallIdentifier

    300

    destLegCallIdentifier

    301

    callingPartyNumber

    2001

    originalCalledPartyNumber

    9728134987

    origCause_Value

    0

    dest_CauseValue

    17

    duration

    0

  2. Call goes to PSTN number, but number does not exist (cause 1 = number unavailable)

    Field Names

    CDR

    globalCallID_callId

    4

    origLegCallIdentifier

    302

    destLegCallIdentifier

    303

    callingPartyNumber

    2001

    originalCalledPartyNumber

    9728134987

    origCause_Value

    1

    dest_CauseValue

    0

    duration

    0

  3. Call to PSTN fails because PSTN trunks are out of order (cause 38 = Network Out Of Order).

    Field Names

    CDR

    globalCallID_callId

    5

    origLegCallIdentifier

    304

    destLegCallIdentifier

    305

    callingPartyNumber

    2001

    originalCalledPartyNumber

    9728134987

    origCause_Value

    0

    dest_CauseValue

    38

    duration

    0

cBarge

The cBarge feature acts very similar to the conference feature. When a shared line uses the cBarge feature, the origCalledPartyNumber, finalCalledPartyNumber and lastRedirectDn represent the conference bridge number 'b00. . . '. The redirect and join OnBehalfOf fields have a value of Conference = 4, and the redirect reason fields specify Conference = 98.

cBarge CDR example

40003 calls 40001, and 40001 answers; 40001' (shared line) on another phone presses the cBarge button.

Field Names

Orig Call CDR

cBarge Call CDR 1

cBarge Call CDR 2

cBarge Call CDR 3

Final Call CDR

globalCallID_callId

49

49

49

49

49

origLegCallIdentifier

1677346

1677348

1677347

1677346

1677347

destLegCallIdentifier

1677347

1677353

1677351

1677352

1677346

callingPartyNumber

40003

40001

40001

40003

40001

originalCalledPartyNumber

40001

b0029901001

b0029901001

b0029901001

40003

finalCalledPartyNumber

40001

b0029901001

b0029901001

b0029901001

40003

lastRedirectDn

40001

b0029901001

40001

40001

b0029901001

origCause_Value

393216

16

393216

393216

16

dest_CauseValue

393216

0

393216

393216

0

origCalledPartyRedirectReason

0

98

98

98

0

lastRedirectRedirectReason

0

98

98

98

98

destTerminationOnBehalfOf

4

 

4

4

4

origCalledRedirectOnBehalfOf

 

4

4

4

 

lastRedirectRedirectOnBehalfOf

 

4

4

4

4

joinOnBehalfOf

 

4

4

4

4

Conversation ID

0

16777220

16777220

16777220

1

duration

60

360

 

360

360

Comment

Orig Call CDR

 

cBarge Call CDR 1

ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD

cBarge Call CDR 2

ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD

cBarge Call CDR 3

ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD

Final Call CDR

ConfControllerDn=40003;ConfControlerDeviceName=SEP0003E333FEBD

Client matter code (CMC)

When the CMC feature gets invoked, the system writes the client matter code into the CDR. The clientMatterCode field contains the client matter code that the caller enters.

CMC CDR example

10000 calls 2142364624; the user gets prompted for a client matter code and enters 11111. The caller answers the call and talks for 10 minutes.

Field Names

Values

globalCallID_callId

101

origLegCallIdentifier

16777130

destLegCallIdentifier

16777131

callingPartyNumber

10000

origCalledPartyNumber

2142364624

finalCalledPartyNumber

2142364624

lastRedirectDn

2142364624

origCause_Value

0

dest_CauseValue

16

clientMatterCode

11111

duration

600

Conference calls

Multiple records get logged for calls that are part of a conference. The number of CDR records that get generated depends on the number of parties in the conference. One CDR exists for each party in the conference; one CDR for the original placed call, one CDR for each setup call that get used to join other parties to the conference, and one CDR for the last two parties that get connected in the conference. For a three-party, ad hoc conference, six CDRs exist: one CDR for the original call, three CDRs for the parties that get connected to the conference, one CDR for each setup call, and one CDR for the final two parties in the conference. You can associate the setup calls with the correct call leg in the conference by examining the calling leg ID and called leg ID.

The conference bridge device represents special significance to the Cisco Unified Communications Manager, and calls to the conference bridge appear as calls to the conference bridge device. A special number in the form "b0019901001" shows the conference bridge port. Records show all calls into the conference bridge, regardless of the actual direction; however, by examining the setup call CDRs, you can determine the original direction of each call.

You can find the conference controller information in the comment field of the CDR. The format of this information follows:

Comment field = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003"

  • The conference controller DN + conference controller device name uniquely identify the conference controller. The system needs the device name in the case of shared lines.
  • If the call is involved in multiple conference calls, the comment field contains multiple conference controller information. This situation can occur when the conference goes down to two parties, and one of these parties starts another conference. If this is the case, the last conference controller information in the comment field identifies the conference controller.

The call legs that are connected to the conference include the following information fields:

  • The finalCalledPartyNumber field contains the conference bridge number "b0019901001."
  • The origCalledPtyRedirectOnBehalfOf field gets set to Conference = 4.
    • The lastRedirectRedirectOnBehalfOf field gets set to Conference = 4.
    • The joinOnBehalfOf field gets set to (Conference = 4).
    • The comment field identifies the conference controller.
    • The destConversationID field remains the same for all members in the conference. You can use this field to identify members of a conference call.

The original placed call and all setup calls that were used to join parties to the conference have the following characteristics:

  • The origCallTerminationOnBehalfOf field gets set to Conference = 4.
  • The destCallTerminationOnBehalfOf field gets set to Conference = 4.

Conference call CDR example

  • Call goes from 2001 to 2309.
  • 2309 answers and talks for 60 seconds.
  • 2001 presses the conference softkey and dials 3071111.
  • 307111 answers and talks for 20 seconds; then, 2001 presses the conference softkey to complete the conference.
  • The three members of the conference talk for 360 seconds.

3071111 hangs up and leaves 2001 and 2309 in the conference. Because only two participants are left in the conference, the conference features joins these two directly together, and they talk for another 55 seconds.


Note


Each conference call leg gets shown as placing a call into the conference bridge. The system shows the call as a call into the bridge, regardless of the actual direction of the call.


Field Names

Orig Call CDR

Setup Call CDR

Conference CDR 1

Conference CDR 2

Conference CDR 3

Final CDR

globalCallID_callId

1

2

1

1

1

1

origLegCallIdentifier

101

105

101

102

106

101

destLegCallIdentifier

102

106

115

116

117

102

callingPartyNumber

2001

2001

2001

2309

3071111

2001

originalCalledPartyNumber

2309

3071111

b0029901001

b0029901001

b0029901001

2309

finalCalledPartyNumber

2301

3071111

b0029901001

b0029901001

b0029901001

2309

lastRedirectDn

2001

3071111

b0029901001

b0029901001

b0029901001

b0029901001

origCause_Value

393216

0

16

393216

393216

16

dest_CauseValue

393216

0

393216

393216

393216

0

origCalledPartyRedirectReason

0

0

0

0

0

0

lastRedirectRedirectReason

0

0

0

0

0

98

origTerminationOnBehalfOf

4

4

12

12

4

12

destTerminationOnBehalfOf

4

4

0

0

4

4

origCalledRedirectOnBehalfOf

0

0

4

4

4

0

lastRedirectRedirectOnBehalfOf

0

0

4

4

4

4

joinOnBehalfOf

0

0

4

4

4

4

Conversation ID

0

0

1

1

1

0

duration

60

20

360

360

360

55

Comment

Orig Call CDR

 

Setup Call CDR

ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD

Conference CDR 1

ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD

Conference CDR 2

ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD

Conference CDR 3

ConfControllerDn=2001;ConfControlerDeviceName=SEP0003E333FEBD

Final CDR

 

Operational factors

Three major operational factors exist for conference call CDRs:

  1. When a conference decreases to two parties, the two parties connect directly and release the conference resource. This change generates an additional CDR for the call between the last two parties in the conference call. For example, if four people connect in a conference call (Amy, Dustin, Spencer, Ethan), when Ethan hangs up, three people remain in the conference call that is connected to the conference bridge (Amy, Dustin, Spencer). When Spencer hangs up, only two people remain in the conference call (Amy and Dustin). The system joins Amy and Dustin directly, and, the conference resource gets released. Directly joining Amy and Dustin creates an additional CDR between the last two parties in the conference.
  2. The system adds the conference controller information to the comment field in the CDR. This information identifies the conference controller. No need now exists to examine the consultation call to determine who is the conference controller. The following example shows this information: Comment field = "ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD"
    • The conference controller DN + conference controller device name uniquely identify the conference controller. A need for the device name exists in the case of shared lines.
    • If the call is involved in multiple conference calls, the comment field contains multiple conference controller information. This situation may occur when the conference goes down to two parties, and one of these parties starts another conference. If this is the case, the last conference controller information in the comment field identifies the conference controller.
  3. The party that added the participant, known as the requestor party, appears in the CDR comment field. The tags for the requestor information include ConfRequestorDn and ConfRequestorDeviceName. The party that requested to remove a participant, known as the drop requestor, appears in the CDR comment field. The tags for the drop requestor information include DropConfRequestorDn and DropConRequestorDeviceName.

Calls that are part of a conference have multiple records that are logged for them. The number of CDRs that get generated depends on the number of parties in the conference. One CDR exists for each party in the conference, one CDR for the original placed call, and one CDR for each setup call that is used to join other parties to the conference. Therefore, for a three-party ad hoc conference, six CDRs exist:

  • One CDR for the original call.
  • Three CDRs for the parties that are connected to the conference.
  • One CDR for each setup call.
  • One CDR for the final two parties in the conference.

You can associate the setup calls with the correct call leg in the conference by examining the calling leg ID and the called leg ID.

The conference bridge device holds special significance to the Cisco Unified Communications Manager. Calls to the conference bridge appear as calls to the conference bridge device. A special number in the form "b0019901001" shows the conference bridge port. All calls get shown "into" the conference bridge, regardless of the actual direction. You can determine the original direction of each call by examining the setup call CDRs.

The call legs that are connected to the conference have the following values for these fields:

  • finalCalledPartyNumber—Represents a conference bridge "b0019901001".
  • origCalledPartyRedirectOnBehalfOf—Set to Conference (4).
  • lastRedirectRedirectOnBehalfOf—Set to Conference (4).
  • joinOnBehalfOf—Set to Conference (4).
  • comment—Identifies the conference controller.

The original placed call and all setup calls that get used to join parties to the conference have the following values for the fields:

  • origCallTerminationOnBehalfOf—Set to Conference (4).
  • destCallTerminationOnBehalfOf—Set to Conference (4).

Conference drop any party

The Conference Drop Any Party feature terminates calls that look the same as other calls except for a new cause code. The cause code identifies the calls that this feature terminates.

Conference drop any party CDR example

The following table contains an example CDR for a call that connects to a conference and gets dropped by this feature.

Calling

Party

Calling

Partition

Original Called Party

Orig Cause

Original Called Partition

Called Leg

Dest Cause

Final Called

Party

Final Called

Partition

Last Redirect Party

2001

ACNTS

2309

0

MKTG

102

16

2309

MKTG

2001

2001

ACNTS

2309

16

MKTG

115

0

b0029901001

b0029901001

2309

ACNTS

b0029901001

0

116

128

b0029901001

b0029901001

3071111

PSTN

b0029901001

16

117

0

b0029901001

b0029901001

2001

ACNTS

2309

16

PSTN

106

0

3071111

PSTN

30711111

Orig Conversation ID

OrigCall Termination OnBehalfOf

DestCall Termination OnBehalfOf

OriginalCalled Pty Redirect OnBehalfOf

LastRedirect Redirect OnBehalfOf

Join OnBehalfOf

Duration

0

4

4

0

0

0

60

1

12

0

4

4

4

360

1

13

0

4

4

4

200

1

4

4

4

4

4

360

0

4

4

0

0

0

20

Original calling party on transfer

This feature changes the calling party number for a consultation call of a Cisco Unity or Cisco Unity Connection-initiated call transfer. The CDR of the consultation call shows that the original caller calls the transfer destination, not that the Cisco Unity or Cisco Unity Connection port calls the transfer destination.

You must configure this feature in the service parameters in Cisco Unified Communications Manager. See additional information in the "Configuring CDR Service Parameters" section of the CDR Analysis and Reporting Administration Guide.

Original Calling Party on Transfer CDR Example

4001 calls 4002. 4002 transfers the call to 4003. The system generates three CDRs:

  • The call between the original parties (4001 to 4002).
  • The consultation call between the transferring party (4002) to the final transfer destination (4003).
  • The call from the transferred party (4001) to the transfer destination (4003).

Call

CallingPartyNumber

originalCalledPartyNumber

1

4001

4002

2

4002

4003

3

4001

4003


Note


No originalCallingParty field exists in the CDR.


DTMF method

These fields identify the Dual Tone Multi-Frequency (DTMF) method that gets used for the call.

DTMF CDR examples

  1. No Preference Example - The DTMF method that gets used during this call represents No Preference/Best Effort. This call connects for 1 minute.

    Field Names

    CDR

    globalCallID_callId

    200

    origLegCallIdentifier

    16777500

    destLegCallIdentifier

    16777501

    callingPartyNumber

    20000

    origCalledPartyNumber

    20001

    finalCalledPartyNumber

    20001

    lastRedirectDn

    20001

    origCause_Value

    0

    dest_CauseValue

    16

    origDTMFMethod

    0

    destDTMFMethod

    0

    duration

    60

  1. Preferred OOB Example - The DTMF method that is used during this call represents OOB Preferred. This call remains connected for 1 minute.

    Field Names

    CDR

    globalCallID_callId

    201

    origLegCallIdentifier

    16777502

    destLegCallIdentifier

    16777503

    callingPartyNumber

    20000

    origCalledPartyNumber

    20001

    finalCalledPartyNumber

    20001

    lastRedirectDn

    20001

    origCause_Value

    0

    dest_CauseValue

    16

    origDTMFMethod

    1

    destDTMFMethod

    1

    duration

    60

End-to-End Call Trace

The End-to-End Call Trace feature facilitates tracing calls that traverse multiple Cisco voice products, such as Unified CM, Cisco IOS Gateways, and other products.

End-to–End Call Trace example

  1. H323 - Calling party 1003 calls 1004 via H.323 trunk.

    FieldNames

    Values

    cdrRecordType

    1

    globalCallID_callManagerId

    1

    globalCallID_callId

    32009

    origLegCallIdentifier

    19654113

    dateTimeOrigination

    1221263718

    origNodeId

    1

    origSpan

    0

    origIpAddr

    1897990154

    callingPartyNumber

    1004

    origCause_value

    16

    origPrecedenceLevel

    4

    origMediaTransportAddress_IP

    1897990154

    origMediaTransportAddress_Port

    19824

    origMediaCap_payloadCapability

    4

    origMediaCap_maxFramesPerPacket

    20

    destLegIdentifier

    19654114

    destNodeId

    1

    destSpan

    19654114

    destIpAddr

    424630538

    originalCalledPartyNumber

    1003

    finalCalledPartyNumber

    1003

    destCause_value

    0

    destPrecedenceLevel

    4

    destMediaTransportAddress_IP

    -1759442934

    destMediaTransportAddress_Port

    27508

    destMediaCap_payloadCapability

    4

    destMediaCap_maxFramesPerPacket

    20

    dateTimeConnect

    1221263720

    dateTimeDisconnect

    1221263721

    lastRedirectDn

    1003

    Pkid

    c8868f84-0f4e-452c-a814-bf97a7fe69fc

    Duration

    1

    origDeviceName

    SEP003094C2B08C

    destDeviceName

    self-loop

    origCallTerminationOnBehalfOf

    12

    destCallTerminationOnBehalfOf

    0

    origDTMFMethod

    3

    destDTMFMethod

    4

    origMediaCap_Bandwidth

    64

    destMediaCap_Bandwidth

    64

    origIpv4v6Addr

    10.8.33.113

    destIpv4v6Addr

    10.8.33.151

    IncomingProtocolID

    0

    IncomingProtocolCallRef

     

    OutgoingProtocolID

    2

    OutgoingProtocolCallRef

    0053C43F6701B18C030004010A082171

  2. Q931 - 1004 calls 1003 via Q931.

    FieldNames

    Values

    cdrRecordType

    1

    globalCallID_callManagerId

    1

    globalCallID_callId

    32008

    origLegCallIdentifier

    19654111

    dateTimeOrigination

    1221263350

    origNodeId

    1

    origSpan

    2

    origIpAddr

    122640650

    callingPartyNumber

    1004

    origCause_value

    0

    origPrecedenceLevel

    4

    origMediaTransportAddress_IP

    122640650

    origMediaTransportAddress_Port

    17218

    origMediaCap_payloadCapability

    4

    origMediaCap_maxFramesPerPacket

    20

    destLegIdentifier

    19654112

    destNodeId

    1

    destSpan

    0

    destIpAddr

    -1759442934

    originalCalledPartyNumber

    1003

    finalCalledPartyNumber

    1003

    destCause_value

    16

    destPrecedenceLevel

    4

    destMediaTransportAddress_IP

    -1759442934

    destMediaTransportAddress_Port

    23350

    destMediaCap_payloadCapability

    4

    destMediaCap_maxFramesPerPacket

    20

    dateTimeConnect

    1221263351

    dateTimeDisconnect

    1221263352

    lastRedirectDn

    1003

    Pkid

    b576bd8d-9703-4f66-ae45-64ae5c04738e

    Duration

    1

    origDeviceName

    BRI/S1/SU0/P1@nw052b-3640.cisco.com

    destDeviceName

    SEP003094C2D263

    origCallTerminationOnBehalfOf

    0

    destCallTerminationOnBehalfOf

    12

    origDTMFMethod

    1

    destDTMFMethod

    3

    origMediaCap_Bandwidth

    64

    destMediaCap_Bandwidth

    64

    origIpv4v6Addr

    10.89.79.7

    destIpv4v6Addr

    10.8.33.151

    IncomingProtocolID

    4

    IncomingProtocolCallRef

    01-1004-1003

    OutgoingProtocolID

    0

    OutgoingProtocolCallRef

     

Forced authorization code (FAC)

When the FAC feature gets invoked, the system writes the authorization description and level into the CDR. For security reasons, the actual authorization code does not get written to the CDR.

  • The authCodeDescription field contains the description of the authorization code.
  • The authorizationLevel field contains the level of authorization that is associated with the authorization code.

FAC CDR example

45000 calls 9728134987; the system prompts the user for an authorization code and enters 12345. FAC code 12345 gets configured as level 1 and name Legal1. The caller answers the call and talks for 2 minutes.

Field Names

Values

globalCallID_callId

100

origLegCallIdentifier

16777123

destLegCallIdentifier

16777124

callingPartyNumber

45000

origCalledPartyNumber

9728134987

finalCalledPartyNumber

9728134987

lastRedirectDn

9728134987

origCause_Value

0

dest_CauseValue

16

authCodeDescription

Legal1

authorizationLevel

1

duration

120

Forwarded or redirected calls

Forwarded calls generate a single CDR and show the Calling Party, Original Called Number, Last Redirecting Number, Final Called Number, and the associated partitions. If the call gets forwarded more than twice, the intermediate forwarding parties do not populate in the CDR.

Call forwarding can occur on several conditions (always, busy, and no answer). The condition under which the call gets forwarded does not populate in the CDR.

The CDRs for forwarded calls match those for normal calls, except for the originalCalledPartyNumber field and the originalCalledPartyNumberPartition field. These fields contain the directory number and partition for the destination that was originally dialed by the originator of the call. If the call gets forwarded, the finalCalledPartyNumber and finalCalledPartyNumberPartition fields differ and contain the directory number and partition of the final destination of the call.

Also, when a call gets forwarded, the lastRedirectDn and lastRedirectDnPartition fields contain the directory number and partition of the last phone that forwarded or redirected the call.

Call Forwarding uses the redirect call primitive to forward the call. Features that use the redirect call primitive have similar CDRs. Some of the important CDR fields for forwarded calls follow:

  • The originalCalledPartyNumber contains the number of the original called party.
  • The finalCalledPartyNumber represents the number that answered the call.
  • The lastRedirectDn field specifies the number that performed the last redirect.
  • The origCalledPartyRedirectReason represents the reason that the call was redirected the first time. For call forwarding, this field can contain Call Forward Busy=1, Call Forward No Answer=2, Call Forward All=15.
  • The lastRedirectRedirectReason specifies the reason that the call was redirected the last time. For call forwarding, this field can contain Call Forward Busy=1, Call Forward No Answer=2, Call Forward All=15.
  • The origCalledPartyRedirectOnBehalfOf field identifies which feature redirects the call for the first redirect. For call forwarding, this field specifies 5 (Call Forward).
  • The lastRedirectRedirectOnBehalfOf field identifies which feature redirects the call for the last redirect. For call forwarding, this field specifies 5 (Call Forward).

Forwarded calls CDR examples

  1. CFA - Call comes in from the PSTN to extension 2001; the call gets forwarded (CFA) to 2309, where the call is answered, and talk occurs for 2 minutes.

    Field Names

    CDR

    globalCallID_callId

    12345

    origLegCallIdentifier

    100

    destLegCallIdentifier

    102

    callingPartyNumber

    9728134987

    originalCalledPartyNumber

    2001

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2001

    origCause_Value

    0

    dest_CauseValue

    16

    origCalledPartyRedirectReason

    15

    lastRedirectRedirectReason

    15

    origCalledPartyRedirectOnBehalfOf

    5

    lastRedirectRedirectOnBehalfOf

    5

    duration

    120

  2. Multiple Hop CFA & CFNA - Call comes in from the PSTN to extension 1000; the call gets forwarded (CFA) to 2000; then, the call gets forwarded (CFNA) to the voice-messaging system (6000) where the caller leaves a message.

    Field Names

    CDR

    globalCallID_callId

    12346

    origLegCallIdentifier

    102

    destLegCallIdentifier

    105

    callingPartyNumber

    9728134987

    originalCalledPartyNumber

    1000

    finalCalledPartyNumber

    6000

    lastRedirectDn

    2000

    origCause_Value

    0

    dest_CauseValue

    16

    origCalledPartyRedirectReason

    15

    lastRedirectRedirectReason

    2

    origCalledPartyRedirectOnBehalfOf

    5

    lastRedirectRedirectOnBehalfOf

    5

    duration

    15

  3. Multiple Hop CFNA & CFB - Call comes in from the PSTN to extension 4444; the call gets forwarded (CFNA) to 5555; then, it gets forwarded (CFB) to 6666 where the call is answered, and they talk for 30 seconds.

    Field Names

    CDR

    globalCallID_callId

    12347

    origLegCallIdentifier

    106

    destLegCallIdentifier

    108

    callingPartyNumber

    9728134987

    originalCalledPartyNumber

    4444

    finalCalledPartyNumber

    6666

    lastRedirectDn

    5555

    origCause_Value

    16

    dest_CauseValue

    0

    origCalledPartyRedirectReason

    2

    lastRedirectRedirectReason

    1

    origCalledPartyRedirectOnBehalfOf

    5

    lastRedirectRedirectOnBehalfOf

    5

    duration

    30

Hunt list support

Hunt list examples

  1. Answered Calls - In this example, calls go to a hunt list and a member of the hunt list answers the call.
    • Cisco Unified IP Phones 3001, 3002, 3003 and 3004 are part of the hunt list. The display names for the phones are 3001-Name, 3002-Name, 3003-Name and 3004-Name, respectively.
    • Hunt Pilot 2000 is associated with a hunt list. Hunt pilot 2000 is configured with display name as 2000-Name.
    • Phone 1000 calls hunt pilot 2000; call is offered at 3001 and answered.

When the service parameter, Show Line Group Member DN in finalCalledPartyNumber CDR Field, is set to True, the following values from the table display in the CDR.

Field Names

CDR

callingPartyNumber

1000

callingPartyNumberPartition

 

originalCalledPartyNumber

2000

originalCalledPartyNumberPartition

 

finalCalledPartyNumber

3001

finalCalledPartyNumberPartition

 

origDeviceName

Phone 1000

destDeviceName

Phone 3001

huntPilotDN

2000

huntPilotPartition

 

When the service parameter, Show Line Group Member DN in finalCalledPartyNumber CDR Field, is set to False, the following values in the table display in the CDR.

Field Names

CDR

callingPartyNumber

1000

callingPartyNumberPartition

 

originalCalledPartyNumber

2000

originalCalledPartyNumberPartition

 

finalCalledPartyNumber

2000

finalCalledPartyNumberPartition

 

origDeviceName

Phone 1000

destDeviceName

Phone 3001

huntPilotDN

2000

huntPilotPartition

 
  1. Abandoned or Failed Calls - In this example, calls go to a hunt list and a member of the hunt list abandons or fails the call.
    • Cisco Unified IP Phones 3001, 3002, 3003 and 3004 are part of the hunt list.
    • Hunt Pilot 2000 is associated with a hunt list.
    • Phone 1000 calls hunt pilot 2000; call is offered at 3001 and abandoned. When the service parameter, Show Line Group Member DN, in finalCalledPartyNumber CDR field is set to True, the following values from the table display in the CDR:

      Field Names

      CDR

      callingPartyNumber

      1000

      callingPartyNumberPartition

       

      originalCalledPartyNumber

      2000

      originalCalledPartyNumberPartition

       

      finalCalledPartyNumber

      3001

      finalCalledPartyNumberPartition

       

      origDeviceName

      Phone 1000

      destDeviceName

      Phone 3001

      huntPilotDN

       

      huntPilotPartition

       

      calledPartyPatternUsage

      7

Because the call does not get answered, the huntPilotDN is not available in the CDR. The PatternUsage (7 = PATTERN_HUNT_PILOT) field gets set to 7 to indicate that the call was made to a hunt pilot. When the service parameter is enabled, the finalCalledPartyNumber field denotes the member hunt DN and the originalCalledPartyNumber field denotes the huntPilot DN.

When the service parameter, Show Line Group Member DN, in the finalCalledPartyNumber CDR field is set to False, the following values in the table display in the CDR:

Field Names

CDR

callingPartyNumber

1000

callingPartyNumberPartition

 

originalCalledPartyNumber

2000

originalCalledPartyNumberPartition

 

finalCalledPartyNumber

2000

finalCalledPartyNumberPartition

 

origDeviceName

Phone 1000

destDeviceName

Phone 3001

huntPilotDN

 

huntPilotPartition

 

calledPartyPatternUsage

7

Because the call is not answered, the huntPilotDN is not available in the CDR. The PatternUsage (7 = PATTERN_HUNT_PILOT) field gets set to 7 to indicate that the call was made to a hunt pilot. When the service parameter is not enabled, the finalCalledPartyNumber field denotes the member hunt DN.

H.239

Cisco Unified Communications Manager supports H.239. This feature defines the procedures for use of up to two video channels in H.320-based systems and for labeling individual channels with a role of "presentation" or "live." This procedure indicates the requirements for processing the channel and the role of the channel content in the call. Role labels apply to both H.320 and H.245 signaling-based systems.

Several new CDR fields support a second video channel for both the origination and destination devices. This CDR provides an example of these new fields.

H.239 CDR example

When A and B declare H.239 capability in Terminal Capability Set (TCS) and one, or both, of the endpoints initiates the receiving channel to have an extended video channel in an H.239 mechanism for presentation or video feed, the new CDR fields display in the CDR in addition to the existing fields of a video call.

Calling party 51234 calls the called party 57890. Let 103 represent H.264, 187962284 represents 172.19.52.11, 288625580 represents 172.19.52.17, and 352 represents 352K.

Field Names

CDR

globalCallID_callId

121

origLegCallIdentifier

101

destLegCallIdentifier

102

callingPartyNumber

51234

originalCalledPartyNumber

57890

finalCalledPartyNumber

57890

lastRedirectDn

57890

origCause_Value

0

destCause_Value

16

origVideoCap_Codec

103

origVideoCap_Bandwidth

352

origVideoCap_Resolution

0

origVideoTransportAddress_IP

187962284

origVideoTransportAddress_Port

2406

destVideoCap_Codec

103

destVideoCap_Bandwidth

352

destVideoCap_Resolution

0

destVideoTransportAddress_IP

288625580

destVideoTransportAddress_Port

2328

origVideoCap_Codec_Channel2

103

origVideoCap_Bandwidth_Channel2

352

origVideoCap_Resolution_Channel2

0

origVideoTransportAddress_IP_Channel2

187962284

origVideoTransportAddress_Port_Channel2

2410

origVideoChannel_Role_Channel2

0

destVideoCap_Codec_Channel2

103

destVideoCap_Bandwidth_Channel2

352

destVideoCap_Resolution_Channel2

0

destVideoTransportAddress_IP_Channel2

288625580

destVideoTransportAddress_Port_Channel2

2330

destVideoChannel_Role_Channel2

0

iLBC calls

Internet Low Bit Rate Codec (iLBC) enables graceful speech quality degradation in a lossy network where frames get lost. For iLBC calls, the codec specifies Media_Payload_ILBC = 86.

The system adds an audio bandwidth field to the CDR for iLBC calls.

Field Names

Definitions

origMediaCap_bandwidth

This integer field contains the audio bandwidth.

destMediaCap_bandwidth

This integer field contains the audio bandwidth.

The system populates the bandwidth fields based on the following table:

Codec

Bandwidth

G711Alaw64k

64

G711Alaw56k

56

G711mu-law64k

64

G711mu-law56k

56

G722 64k

64

G722 56k

56

G722 48k

48

G7231

7

G728

16

G729

8

G729AnnexA

8

Is11172AudioCap

0

Is13818AudioCap

0

G729AnnexB

8

G729AnnexAwAnnexB

8

GSM Full Rate

13

GSM Half Rate

7

GSM Enhanced Full Rate

13

Wideband 256K

256

Data 64k

64

Data 56k

56

G7221 32K

32

G7221 24K

24

AAC-LD (mpeg4-generic)

256

AAC-LD (MP4A-LATM) 128K

128

AAC-LD (MP4A-LATM) 64K

64

AAC-LD (MP4A-LATM) 56K

56

AAC-LD (MP4A-LATM) 48K

48

AAC-LD (MP4A-LATM) 32K

32

AAC-LD (MP4A-LATM) 24K

24

GSM

13

iLBC

15 or 13

iSAC

32

XV150 MR 729A

8

NSE VBD 729A

8

iLBC call CDR example

This example applies to a call with iLBC codec.

Field Names

iLBC CDR

globalCallID_callId

121

origLegCallIdentifier

101

destLegCallIdentifier

102

callingPartyNumber

51234

originalCalledPartyNumber

57890

finalCalledPartyNumber

57890

lastRedirectDn

57890

origCause_Value

0

dest_CauseValue

16

origMediaCap_payloadCapability

86

origMediaCap_Bandwidth

15

destMediaCap_payloadCapability

86

destMediaCap_Bandwidth

15

Immediate divert (to voice-messaging system)

Immediate Divert (IDivert) gets invoked in three different call states:

  • You can invoke the IDivert feature while the incoming call is ringing. The CDR for the ringing case acts very similar to call forwarding, but the origCalledPartyRedirectOnBehalfOf and the lastRedirectRedirectOnBehalfOf fields specify Immediate Divert = 14.
  • You can invoke the IDivert feature while the call is connected or on hold. These scenarios generate two CDRs. Both CDRs have the same globalCallID_CallId field. The first CDR applies to the original connection, and the second CDR applies to the call redirected to the voice-messaging system. The first call has the origTerminationOnBehalfOf and destTerminationOnBehalfOf fields set to Immediate Divert = 14.
  • The call that gets redirected to the voice-messaging system has the origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields set to Immediate Divert = 14.

IDivert CDR examples

  1. IDivert during Alerting – 40003 calls 40001, and while 40001 is ringing, 40001 presses the IDivert button, and call diverts to the voice-messaging system 40000.

    Note


    If the call gets redirected by IDivert in the Alerting state, only one CDR gets generated.


    Field Names

    Original call CDR

    globalCallID_callId

    37

    origLegCallIdentifier

    16777327

    destLegCallIdentifier

    16777329

    callingPartyNumber

    40003

    origCalledPartyNumber

    40001

    finalCalledPartyNumber

    40000

    lastRedirectDn

    40001

    origCause_Value

    16

    dest_CauseValue

    0

    origCalledPartyRedirectReason

    50

    lastRedirectRedirectReason

    50

    origCalledPartyRedirectOnBehalfOf

    14

    lastRedirectRedirectOnBehalfOf

    14

    joinOnBehalfOf

    14

  2. IDivert during Connect – 40003 calls 40001, and 40001 answers the call. 40001 decides to divert the caller to the voice-messaging system and presses the IDivert softkey. 40003 gets diverted to the voice-messaging system 40000. Because the call gets connected before the redirect, two CDRs get generated: one for the original connected call, and another for the call that is diverted to the voice-messaging system.

    Field Names

    Original Connected Call CDR

    Diverted Call CDR

    globalCallID_callId

    38

    38

    origLegCallIdentifier

    16777330

    16777330

    destLegCallIdentifier

    16777331

    16777332

    callingPartyNumber

    40003

    40003

    origCalledPartyNumber

    40001

    40001

    finalCalledPartyNumber

    40001

    40000

    lastRedirectDn

    40001

    40001

    origCause_Value

    0

    16

    dest_CauseValue

    0

    0

    origCalledPartyRedirectReason

    0

    50

    lastRedirectRedirectReason

    0

    50

    origCalledPartyRedirectOnBehalfOf

     

    14

    lastRedirectRedirectOnBehalfOf

     

    14

    origTerminationOnBehalfOf

    14

    14

    destTerminationOnBehalfOf

    14

    12

    joinOnBehalfOf

     

    14

Intercom calls

The Intercom feature provides one-way audio; therefore, the CDR reflects one-way audio. For talk-back intercom, two-way audio exists, and the CDR reflects two-way audio.

The Intercom feature requires a partition (intercom partition), and existing CDR partition fields get used to identify intercom calls.

The following two examples show CDRs for intercom.

Intercom CDR examples

  1. Whisper Intercom - Phone 20000 invokes the intercom. The configured intercom partition name specifies "Intercom."

    Field Names

    Original Call CDR

    globalCallID_callId

    1111000

    origLegCallIdentifier

    21822467

    destLegCallIdentifier

    21822468

    callingPartyNumber

    20000

    originalCalledPartyNumber

    20001

    finalCalledPartyNumber

    20001

    origCause_Value

    16

    dest_CauseValue

    0

    origMediaTransportAddress_IP

    0

    origMediaTransportAddress_Port

    0

    destMediaTransportAddress_IP

    -47446006

    destMediaTransportAddress_Port

    28480

    origCalledPartyNumberPartition

    Intercom

    callingPartyNumberPartition

    Intercom

    finalCalledPartyNumberPartition

    Intercom

    duration

    5

  2. Talk-Back Intercom - Phone 20000 presses the intercom button. 20001 invokes Talk-Back and talks to 20000. The configured intercom partition name specifies "Intercom."

    Field Names

    Original Call CDR

    globalCallID_callId

    1111000

    origLegCallIdentifier

    21822469

    destLegCallIdentifier

    21822470

    callingPartyNumber

    20000

    originalCalledPartyNumber

    20001

    finalCalledPartyNumber

    20001

    origCause_Value

    16

    dest_CauseValue

    0

    origMediaTransportAddress_IP

    -131332086

    origMediaTransportAddress_Port

    29458

    destMediaTransportAddress_IP

    -47446006

    destMediaTransportAddress_Port

    29164

    origCalledPartyNumberPartition

    Intercom

    callingPartyNumberPartition

    Intercom

    finalCalledPartyNumberPartition

    Intercom

    duration

    5

IPv6 calls

Cisco Unified Communications Manager supports IPv6 in this release. There are two new fields in the CDR for this feature:

  • origIpv4v6Addr—This field identifies the IP address of the device that originates the call signaling. The field can be in either IPv4 or IPv6 format depending on the IP address type that gets used for the call.
  • destIpv4v6Addr—This field identifies the IP address of the device that terminates the call signaling. The field can be in either IPv4 or IPv6 format depending on the IP address type that gets used for the call.

The following CDR examples display IPv6 with successful and unsuccessful calls.

Successful calls

  1. A talks to B; A hangs up. A is configured as v4_only and B is configured as v4_only. The new fields origIpv4v6Addr and destIpv4v6Addr get populated with the format of their respective v4 addresses.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    352737802

    destIpAddr

    1878566390

    origIpv4v6Addr

    10.90.6.21

    destIpv4v6Addr

    10.90.7.144

    duration

    60

  2. A talks to B; A hangs up. A is configured as v6_only and B is configured as v6_only. The new fields origIpv4v6Addr anddestIpv4v6Addr get populated with the format of their respective v6 addresses.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    0

    destIpAddr

    0

    origIpv4v6Addr

    2001:fecd:ba23:cd1f:dcb1:1010:9234:40881

    destIpv4v6Addr

    2001:420:1e00:e5:217:8ff:fe5c:2fa9

    duration

    60

  3. A talks to B; A hangs up. A is configured as v4_only and B is configured as v6_only. The new fields origIpv4v6Addr and destIpv4v6Addr get populated with the format of their respective v4/v6 addresses.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    352737802

    destIpAddr

    -1878566390

    origIpv4v6Addr

    10.90.6.21

    destIpv4v6Addr

    10.90.7.144

    duration

    60

  4. A talks to B; A hangs up. A is configured as v4_v6 and B is configured as v4_only. In this case, media negotiates v4. The new fields origIpv4v6Addr and destIpv4v6Addr get populated with the format of their respective v4 addresses.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    352737802

    destIpAddr

    -1878566390

    origIpv4v6Addr

    10.90.6.21

    destIpv4v6Addr

    10.90.7.144

    duration

    60

  5. A talks to B; A hangs up. A is configured as v4_v6 and B is configured as v6_only. In this case, media negotiates v6. The new fields origIpv4v6Addr and destIpv4v6Addr get populated with the format of their respective v6 addresses.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    352737802

    destIpAddr

    0

    origIpv4v6Addr

    2001:fecd:ba23:cd1f:dcb1:1010:9234:4088

    destIpv4v6Addr

    2001:420:1e00:e5:217:8ff:fe5c:2fa9

    duration

    60

Unsuccessful calls

  1. A calls B; A abandons the call. A is configured as v4_only and B is configured as v6_only. The new field origIpv4v6Addr gets populated with the format of its v4 address. The new field destIpv4v6Addr does not get populated.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    352737802

    destIpAddr

    -569419254

    origIpv4v6Addr

    10.90.15.222

    destIpv4v6Addr

    duration

    0

  2. A calls B; the call fails. A is configured as v6_only and B is configured as v4_v6. The new field origIpv4v6Addr gets populated with the format of its v6 address. The new field destIpv4v6Addr does not get populated in this case.

    Field Names

    Values

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origIpAddr

    0

    destIpAddr

    0

    origIpv4v6Addr

    2001:fecd:ba23:cd1f:dcb1:1010:9234:4088

    destIpv4v6Addr

    duration

    0

Legacy Call Pickup

Legacy Call Pickup calls act similar to forwarded calls. Legacy Call Pickup uses the redirect call control primitive like call forwarding. Some of the important CDR fields for Legacy Call Pickup calls follow:

  • The originalCallPartyNumber field contains the number of the original called party.
  • The finalCalledPartyNumber field specifies the number of the party that picks up the call.
  • The lastRedirectDn field specifies the number that rings when the call gets picked up.
  • The origCalledPartyRedirectReason field specifies the reason that the call gets redirected the first time. For call pickup calls, this field can contain Call Pickup = 5.
  • The lastRedirectRedirectReason field specifies the reason that the call gets redirected the last time. For call pickup, this field can contain Call Pickup = 5.
  • The origCalledPartyRedirectOnBehalfOf field identifies which feature redirects the call for the first redirect. For call pickup, this field specifies Pickup = 16.
  • The lastRedirectRedirectOnBehalfOf field identifies which feature redirects the call for the last redirect. For call pickup, this field specifies Pickup = 16.

Legacy Call Pickup CDR example

Call from the PSTN to extension 2001; 2001 and 2002 exist in the same pickup group. 2002 picks up the call that rings on 2001. 2002 answers the call, and the call connects between the PSTN caller and 2002. They talk for 2 minutes.

Field Names

CDR

globalCallID_callId

22

origLegCallIdentifier

1

destLegCallIdentifier

2

callingPartyNumber

9728134987

originalCalledPartyNumber

2001

finalCalledPartyNumber

2002

lastRedirectDn

2001

origCause_Value

0

dest_CauseValue

16

origCalledPartyRedirectReason

0

lastRedirectRedirectReason

5

origCalledPartyRedirectOnBehalfOf

16

lastRedirectRedirectOnBehalfOf

16

duration

120

Local route groups and called party transformation

In this release, Cisco Unified Communications Manager supports the new feature, local route groups and called party transformation. The device reports the Called Party Number that it outpulsed back to Call Control only if called party transformation occurs. This action gets recorded in the CDR in the new field outpulsedCalledPartyNumber.

Local route groups and called party normalization CDR example

A call gets placed from an enterprise phone in Dallas to the PSTN; the dialed number specifies 9.5551212.

The translation causes the called party number to take the digits as dialed by the originator, discard PreDot and add the Prefix +1 214.

The finalCalledPartyNumber in the CDR comprises the globally unique E.164 string +12145551212.

If a San Jose gateway gets selected, it transforms the global string +1 214 555 1212 into 12145551212, and if a Dallas gateway gets selected, the global string gets transformed into 2145551212.

The device returns this global string to Call Control as the outpulsedCalledPartyNumber; it gets recorded in the CDR.

The following CDR gets created if the San Jose gateway gets selected.

Field Names

Values

globalCallID_callId

1

origLegCallIdentifier

100

destLegCallIdentifier

101

callingPartyNumber

2001

originalCalledPartyNumber

+12145551212

finalCalledPartyNumber

2309

lastRedirectDn

2309

origCause_Value

16

dest_CauseValue

0

duration

60

outpulsedCalledPartyNumber

12145551212

The following CDR gets created if the Dallas gateway gets selected.

Field Names

Values

globalCallID_callId

1

origLegCallIdentifier

100

destLegCallIdentifier

101

callingPartyNumber

2001

originalCalledPartyNumber

+12145551212

finalCalledPartyNumber

+12145551212

lastRedirectDn

+12145551212

origCause_Value

16

dest_CauseValue

0

duration

60

outpulsedCalledPartyNumber

2145551212

Logical partitioning calls

The Telecom Regulatory Authority of India (TRAI) requires that voice traffic over an enterprise data network and a PSTN network remain separate. The logical partitioning feature ensures that a single system can be used to support both types of calls as long as calls that pass through a PSTN gateway can never directly connect to a VoIP phone or VoIP PSTN gateway in another geographic location (geolocation).

CDR example for call termination cause code CCM_SIP_424_BAD_LOCATION_INFO

A SIP trunk call goes from cluster1 to cluster2. The call contains a geolocation header but does not include an XML location. Cluster2 releases the call with a SIP Status code of 424 (bad location information [decimal value = 419430421]).

Cause code CCM_SIP_424_BAD_LOCATION_INFO gets logged for calls that are cleared because of bad location information by the SIP trunk on the Cisco Unified Communications Manager. The remote endpoint on the SIP trunk can send the 424 SIP Status code for cases when the geolocation information is bad for some of the following reasons:

  • The geolocation header indicates the inclusion of PIDF-LO, but the message body does not carry this information.
  • The geolocation header has a CID header that refers to a URL, but no corresponding Content-IP header with the same URL exists.
  • The geolocation header has a URL other than the CID header (that is a SIP, or SIPS URL).

Refer to additional CDR examples for more information on other call termination cause codes.

Field Names

Values

globalCallID_callId

1

origLegCallIdentifier

100

destLegCallIdentifier

101

callingPartyNumber

2001

originalCalledPartyNumber

9900

finalCalledPartyNumber

9900

lastRedirectDn

9900

origCause_Value

0

dest_CauseValue

419430421

duration

0

CDR Example for Call Termination Cause Code 503

Call 82291002 from cluster1 gets call-forwarded to the PSTN 41549901. A call occurs from cluster2 from DN 89224001 to cluster1 DN 82291002. The call gets denied because of logical partitioning with a call termination cause code of CCM_SIP_503_SERVICE_UNAVAIL_SER_OPTION_NOAVAIL [decimal value of -1493172161]) for the dest_CauseValue.

Cause code CCM_SIP_503_SERVICE_UNAVAIL_SER_OPTION_NOAVAIL gets logged for calls that get cleared because of restricted logical partitioning policy checks during the call establishment phase (basic call, call forwarding, call pickup, call park, meet-me conferences, and so forth). Refer to additional CDR examples for more information on other call termination cause codes.

Field Names

Values

globalCallID_callId

1

origLegCallIdentifier

100

destLegCallIdentifier

101

callingPartyNumber

89224001

originalCalledPartyNumber

82291002

finalCalledPartyNumber

41549901

lastRedirectDn

82291002

origCause_Value

0

dest_CauseValue

-1493172161

duration

0

Malicious calls

When a call gets identified as a malicious call (button press), the local Cisco Unified Communications Manager network flags the call. The Comment field flags the malicious call.

Malicious calls CDR example

The following table contains an example CDR of a customer call that gets marked as malicious.

Calling Party

Calling Partition

Original Called Party

Original Called Partition

Orig Cause

Dest Cause

Comment

9728552001

CUST

5555

ACNTS

0

16

"callFlag=MALICIOUS"

Meet-Me conferences

A meet-me conference occurs when several parties individually dial into a conference bridge at a predetermined time.

The Cisco Secure Conference feature uses the existing callSecuredStatus field to display the highest security status that a call reaches. For meet-me conferences, the system clears calls that try to join the conference but do not meet the security level of the meet-me conference with a terminate cause = 58 (Bearer capability not presently available).

Meet-Me conference CDR example

The following table contains an example CDR for the following scenario. 5001 specifies the dial-in number. The conference bridge device signifies special significance to the Cisco Unified Communications Manager, and calls to the conference bridge appear as forwarded calls; that is, User A phones the predetermined number (5001); the call gets forwarded to a conference bridge port. The conference bridge port appears with a special number of the form "b0019901001."

  • User A (2001) calls into a meet-me conference bridge with the phone number 5001.
  • User B (2002) calls into a meet-me conference bridge with the phone number 5001.
  • User C (2003) calls into a meet-me conference bridge with the phone number 5001.
 

Calling Party

Calling Partition

Original Called Party

Original Called Partition

Final Called Party

Final Called Partition

Last Redirect Party

Last Redirect Partition

Duration

A

2001

Accounts

5001

b0019901001

b0019901001

70

B

2002

Accounts

5001

b0019901001

b0019901001

65

C

2003

Accounts

5001

b0019901001

b0019901001

80

Mobility

Cisco Unified Communications Manager supports the following Mobility features:

  • Hand-In
  • Hand-Out
  • Cell Pickup
  • Interactive Voice Response (IVR)

The system generates a standard CDR for every call that uses the Mobility features. When a call gets split, redirected, or joined by the Mobility feature, the corresponding OnBehalfOf code represents a new value that is designated to the Mobility feature. The CAR Loader checks the following OnBehalfOf fields:

  • origCallTerminationOnBehalfOf
  • destCallTerminationOnBehalfOf
  • origCalledPartyRedirectOnBehalfOf
  • lastRedirectRedirectOnBehalfOf
  • joinOnBehalfOf

If any of the preceding OnBehalfOf codes has the Mobility code of 24, the CDR has the Mobility call type that the CAR Loader determines. Four RedirectReason codes apply for Mobility features: Hand-In (code 303), Hand-Out (code 319), Cell Pickup (code 335), and IVR (code 399).

Mobility CDR examples

  1. Mobility Follow Me - A dual-mode phone has the Enterprise number of 22285 and the cell number of 9728324124. 22202 calls 22285, and both 22285 and 9728324124 ring. The cell phone answers the call. The system generates a single CDR for this Follow Me call. The parties talk for 80 seconds.

    Field Names

    Follow Me Call CDR

    globalCallID_callId

    861

    origLegCallIdentifier

    22481077

    destLegCallIdentifier

    22481078

    callingPartyNumber

    22202

    originalCalledPartyNumber

    22285

    finalCalledPartyNumber

    9728324124

    lastRedirectDn

    22285

    origCause_Value

    16

    dest_CauseValue

    0

    lastRedirectRedirectReason

    0

    lastRedirectRedirectOnBehalfOf

    0

    origTerminationOnBehalfOf

     

    destTerminationOnBehalfOf

     

    joinOnBehalfOf

    0

    duration

    80

  2. Mobility HandIn - A dual-mode phone with the Enterprise number of 22285 and the cell number of 9728324124 calls to the cell phone 9728324214. They talk for 39 seconds; then, the dual-mode phone gets carried into the Enterprise network, and the call gets switched from the cell network to the Enterprise network. The parties continue to talk for another 15 seconds.

    Field Names

    Call to cell #9728324214 CDR

    HandIn Call to the Enterprise CDR

    globalCallID_callId

    864

    864

    origLegCallIdentifier

    22481083

    22481083

    destLegCallIdentifier

    22481085

    22481087

    callingPartyNumber

    22202

    22202

    originalCalledPartyNumber

    919728324124

    22285

    finalCalledPartyNumber

    919728324124

    22285

    lastRedirectDn

    919728324124

    22285

    origCause_Value

    393216

    0

    dest_CauseValue

    393216

    16

    lastRedirectRedirectReason

    0

    303

    lastRedirectRedirectOnBehalfOf

    0

    24

    origTerminationOnBehalfOf

    24

    24

    destTerminationOnBehalfOf

    24

    12

    joinOnBehalfOf

    0

    24

    duration

    39

    15

  3. Mobility HandOut - A dual-mode phone has the Enterprise number of 22285 and the cell number of 9728324124. The handout number (H-number) specifies 555123. A call goes to the Enterprise number 22285. They talk for 21 seconds; then, the dual-mode phone gets carried out of the Enterprise network and into the cell network. The call gets switched from the Enterprise network to the cell network (9728324124). The parties continue to talk for another 39 seconds.

    Field Names

    Enterprise Call to 22285 CDR

    Server Call from cell phone to H-Number CDR

    Handout Call CDR

    globalCallID_callId

    964

    965

    964

    origLegCallIdentifier

    22481083

    22481095

    22481093

    destLegCallIdentifier

    22481094

    22481096

    22481095

    callingPartyNumber

    22202

    9728324124

    22202

    originalCalledPartyNumber

    22285

    555123

    9728324124

    finalCalledPartyNumber

    22285

    555123

    9728324124

    lastRedirectDn

    22285

    555123

    9728324124

    origCause_Value

    393216

    393216

    0

    dest_CauseValue

    393216

    393216

    16

    lastRedirectRedirectReason

    0

    0

    319

    lastRedirectRedirectOnBehalfOf

    0

    0

    24

    origTerminationOnBehalfOf

    24

    24

    24

    destTerminationOnBehalfOf

    24

    24

    12

    joinOnBehalfOf

    0

    0

    24

    duration

    21

    0

    39

  4. Mobility Cell Pickup - A dual-mode phone with the Enterprise number of 22285 and the cell number of 9728324124, establishes a call to the Enterprise number 22285. They talk for 40 seconds; then, Cell Pickup gets invoked. The call gets switched from the Enterprise phone to the cell phone. The parties continue to talk for another 111 seconds.

    Field Names

    Enterprise Call to 22285 CDR

    Server Call to Cell Phone CDR

    Final Handout Call CDR

    globalCallID_callId

    555

    566

    964

    origLegCallIdentifier

    22481111

    22481222

    22481111

    destLegCallIdentifier

    22481112

    22481223

    22481222

    callingPartyNumber

    22202

    2202

    22202

    originalCalledPartyNumber

    22285

    22285

    22285

    22285

    finalCalledPartyNumber

    22285

    9728324124

    22285

    lastRedirectDn

    22285

    22285

    22285

    origCause_Value

    393216

    393216

    0

    dest_CauseValue

    393216

    393216

    16

    lastRedirectRedirectReason

    0

    0

    415

    lastRedirectRedirectOnBehalfOf

    0

    24

    24

    origTerminationOnBehalfOf

    24

    24

    24

    destTerminationOnBehalfOf

    24

    24

    12

    joinOnBehalfOf

    0

    24

    24

    duration

    40

    0

    111

  5. Mobility IVR - A call comes into the Cisco Unified Communications Manager with string DID#RemoteDest#TargetNum#. The call gets redirected to the TargetNum. 9728131234 calls into an IVR, and data gets collected. The target destination specifies 812345, and the call gets redirected to 812345. The call remains connected for 60 seconds.

    Field Names

    Redirected Call CDR

    globalCallID_callId

    12345

    origLegCallIdentifier

    16677100

    destLegCallIdentifier

    16677102

    callingPartyNumber

    9728131234

    originalCalledPartyNumber

    8005559876

    finalCalledPartyNumber

    812345

    lastRedirectDn

    8005559876

    origCause_Value

    0

    dest_CauseValue

    16

    lastRedirectRedirectReason

    399

    lastRedirectRedirectOnBehalfOf

    24

    origTerminationOnBehalfOf

    0

    destTerminationOnBehalfOf

    0

    duration

    60

Normal calls (Cisco Unified IP Phone to Cisco Unified IP Phone)

Normal calls log three records per call; one CDR and two CMRs, one for each endpoint. In the CDR, the "originalCalledPartyNumber" field contains the same Directory Number as the "finalCalledPartyNumber" field.

Successful normal calls CDR examples

A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.

  1. The caller terminates a 60-second call. Because the calling party hangs up, the orig_CauseValue specifies 16 (Normal Clearing).

    Field Names

    CDR

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origCause_Value

    16

    dest_CauseValue

    0

    duration

    60

  2. The called party clears a 60-second call. Because the called party hangs up, the dest_CauseValue specifies 16 (Normal Clearing).

    Field Names

    CDR

    globalCallID_callId

    1

    origLegCallIdentifier

    100

    destLegCallIdentifier

    101

    callingPartyNumber

    2001

    originalCalledPartyNumber

    2309

    finalCalledPartyNumber

    2309

    lastRedirectDn

    2309

    origCause_Value

    0

    dest_CauseValue

    16

    duration

    60

Original calling party on transfer

This feature changes the calling party number for a consultation call of a Cisco Unity or Cisco Unity Connection-initiated call transfer. The CDR of the consultation call shows that the original caller calls the transfer destination, not that the Cisco Unity or Cisco Unity Connection port calls the transfer destination.

You must configure this feature in the service parameters in Cisco Unified Communications Manager. See additional information at "Configuring CDR Service Parameters" section of the CDR Analysis and Reporting Administration Guide.

Original calling party on transfer CDR example

4001 calls 4002. 4002 transfers the call to 4003. The system generates three CDRs:

  • The call between the original parties (4001 to 4002).
  • The consultation call between the transferring party (4002) to the final transfer destination (4003).
  • The call from the transferred party (4001) to the transfer destination (4003).

Call

CallingPartyNumber

originalCalledPartyNumber

1

4001

4002

2

4002

4003

3

4001

4003


Note


No originalCallingParty field exists in the CDR.


Personal assistant calls

This section contains information about Personal Assistant Calls.

Personal assistant direct call

A personal assistant direct call acts similar to the Blind Transfer from the Calling Party call type.

Personal assistant direct call CDR example

The following table contains an example CDR for this scenario:

  • User A (2101) calls Personal Assistant route point (2000) and says "call User B."
  • The call transfers to User B (2105). In this case, User B did not configure any rules.

Note


In the following example, 2000 represents the main personal assistant route point to reach personal assistant, 21XX represents the personal assistant interceptor route point, and 2001 - 2004 represents the media port.


In all cases, 2101 specifies the calling number.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2101

16777217

PAManaged

16777219

2004

Phones

2000

1023970182

2000

Phones

34

2004

16777221

Phones

16777222

2105

PAManaged

2105

1023970182

2105

PAManaged

0

2101

16777217

PAManaged

16777222

2105

PAManaged

2105

1023970191

2105

PAManaged

5

Related References

Personal assistant interceptor going to media port and transferring call

This scenario acts similar to Blind Transfer from the Calling Party and Forwarded Calls actions.

Personal assistant interceptor going to media port and transferring the call CDR example

The following table contains an example CDR for this scenario:

  • User A (2101) dials 2105.
  • The personal assistant interceptor (21XX) picks up the call and redirects it to a media port (2002).
  • Personal assistant processes the call according to the rules (if any) and transfers the call to the destination (2105), which has not configured any rules.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2002

16777234

Phones

16777285

2105

PAManaged

2105

1023970478

2105

PAManaged

2

2101

16777230

PAManaged

16777232

2002

PA

2105

1023970478

21xx

" "

9

2105

16777235

PAManaged

16777230

2101

" "

" "

1023970483

" "

" "

5

Personal assistant interceptor going directly to destination

This scenario can have two different cases: with rules and with no rules.

Example personal assistant interceptor going directly to destination with no rules CDR

The following table contains an example CDR for this scenario:

  • User A (2101) dials 2105.
  • The personal assistant interceptor (21XX) picks up the call, processes it according to the rules (if any), and redirects the call to the destination (2105).

The following table contains an example CDR for this scenario:

Calling Party Number

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Number

FinalCalled Party Number Partition

Original Called Party Number

Original Called Party Number Partition

Last Redirect DN

Last Redirect DN Partition

Duration(secs)

2101

16777240

PAManaged

16777242

2105

PA

2105

1023970710

21XX

" "

8

Example personal assistant going directly to destination with rule to forward calls to different destination CDR

The following table contains an example CDR for this scenario:

  • User A (2101) dials 2105.
  • The Personal Assistant interceptor (21XX) picks up the call and processes it according to the rules.
  • The Personal Assistant interceptor then redirects the call to the final destination (2110). In this case, 2105 configured a rule to forward the call to extension 2110.

Calling Party Number

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Number

FinalCalled Party Number Partition

Original Called Party Number

Original Called Party Number Partition

Last Redirect DN

Last Redirect DN Partition

Duration(secs)

2101

16777240

PAManaged

16777242

2110

PA

2105

1023970710

21XX

" "

8

Personal assistant interceptor going to multiple destinations

This scenario can have several different cases. In each case, User B (2105) configures a rule to reach him at extension 2110 or 2120. This rule can activate when a caller calls Personal Assistant route point (2000) and says "call User B" (direct case) or when the caller dials User B (2105) directly (interceptor case).

Personal assistant interceptor going to multiple destinations CDR examples

The following sections contain examples of each case. The following tables contain example CDRs for each of these scenarios:

  • Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at first destination)
  • Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at second destination)
  • Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at third destination)
  • Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at first destination)
  • Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at second destination)
  • Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at third destination)
Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at first destination)
  • User A calls personal assistant and says, "call User B."
  • User B answers the call at 2110 extension.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2004

16777262

Phones

16777263

2110

PAManaged

2110

1023971303

2110

PAManaged

6

2101

16777258

PAManaged

16777260

2004

Phones

2000

1023971303

2000

Phones

22

2110

16777263

PAManaged

16777258

2101

" "

" "

1023971312

" "

" "

9

Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at second destination)
  • User A calls personal assistant and says, "call User B."
  • User B answers the call at 2120 extension.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2001

16777269

Phones

16777270

2110

PAManaged

2110

1023971456

2110

PAManaged

0

2001

16777272

Phones

16777273

2120

PAManaged

2120

1023971467

2120

PAManaged

4

2101

16777265

PAManaged

16777267

2001

Phones

2000

1023971467

2000

Phones

37

2120

16777273

PAManaged

16777265

2101

" "

" "

1023971474

" "

" "

7

2110

16777275

PAManaged

0

" "

" "

" "

1023971476

" "

" "

0

Personal assistant direct multiple destinations: 2110 and 2120 (call accepted at third destination)
  • User A calls personal assistant and says, "call User B."
  • User B does not answer at either extension 2110 or 2120.
  • Personal Assistant transfers the call to the original destination (2105), and User B then answers at that extension.

Note


2105 (the original destination) represents the third destination in this case.


Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2002

16777281

Phones

16777282

2110

PAManaged

2110

1023971602

2110

PAManaged

0

2002

16777284

Phones

16777285

2120

PAManaged

2120

1023971615

2120

PAManaged

0

2101

16777277

PAManaged

16777279

2002

Phones

2000

1023971619

2000

Phones

38

2002

16777287

Phones

16777288

2105

PAManaged

2105

1023971619

2105

PAManaged

0

2101

16777277

PAManaged

16777288

2105

PAManaged

2105

1023971627

2105

PAManaged

7

2105

16777289

PAManaged

0

" "

" "

" "

1023971629

" "

" "

0

Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at first destination)
  • User A calls personal assistant and says, "call User B."
  • User B answers the call at extension 2110.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2003

16777295

Phones

16777296

2110

PAManaged

2110

1023971740

2110

PAManaged

4

2101

16777291

PAManaged

16777293

2003

PA

2105

1023971740

21XX

" "

10

2110

16777296

PAManaged

16777291

2101

" "

" "

1023971749

" "

" "

9

Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at second destination)
  • User A calls personal assistant and says, "call User B."
  • User B answers the call at extension 2120.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2004

16777302

Phones

16777303

2110

PAManaged

2110

1023971815

2110

PAManaged

0

2004

16777305

Phones

16777306

2120

PAManaged

2120

1023971824

2120

PAManaged

3

2101

16777298

PAManaged

16777300

2004

PA

2105

1023971824

21XX

" "

22

2120

16777306

PAManaged

16777298

2101

" "

" "

1023971832

" "

" "

8

Personal assistant intercept multiple destinations: 2110 and 2120 (call accepted at third destination)
  • User A calls personal assistant and says, "call User B."
  • User B does not answer at either extension 2110 or 2120.
  • Personal assistant transfers the call to the original destination (2105), which User B then answers.

Note


2110 (the original destination) represents the third destination in this case.


Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

Original Called Party Num

Original Called Party Number Partition

Last Redir DN

Last Redirect DN Partition

Duration (secs)

2001

16777312

Phones

16777313

2110

PAManaged

2110

1023971923

2110

PAManaged

0

2001

16777315

Phones

16777316

2120

PAManaged

2120

1023971936

2120

PAManaged

0

2101

16777308

PAManaged

16777310

2001

PA

2105

1023971940

21XX

" "

30

2001

16777318

Phones

16777319

2105

PAManaged

2105

1023971940

2105

PAManaged

0

2101

16777308

PAManaged

16777319

2105

PAManaged

2105

1023971953

2105

PAManaged

12

Personal assistant conferencing

Personal assistant conferencing acts similar to the ad hoc conferences call type.

Personal assistant conferencing CDR example

The following table contains an example CDR for this scenario:

  • User A calls personal assistant route point (2000) and says, "conference User B (2105) and User C (2110)."
  • Personal assistant conferences User B and C into User A conference.

Calling Party Num

OrigLegCall Identifier

Calling Party Number Partition

DestLeg Identifier

Final Called Party Num

Final Called Party Number Partition

2003

16777345

Phones

16777346

2105

PAManaged

2101

16777340

PAManaged

16777342

2003

Phones

2003

16777350

Phones

16777351

2002

PAManaged

2003

16777342

Phones

16777347

2110

" "

2110

16777351

PAManaged

16777352

b00110201001

" "

2105

16777346

PAManaged

16777349

b00110201001

" "

2101

16777340

PAManaged

16777348

b00110201001

" "

This table continues with this additional information.

Original CalledParty Number

Original Called Party Number Partition

Last Redirect DN

Last Redirect DN Partition

Duration (seconds)

2105

1023972575

2105

PAManaged

6

2000

1023972576

2003

Phones

62

2110

1023972595

2110

PAManaged

39

b00110201001

1023972601

b00110201001

" "

25

b00110201001

1023972609

b00110201001

" "

14

b00110201001

1023972610

b00110201001

" "

34

b00110201001

1023972610

b00110201001

" "

34

Related References

Precedence calls (MLPP)

Precedence calls take place the same as other calls except the precedence level fields get set in the CDR. Also, when a higher level precedence call preempts a call, the cause codes indicate the reason for the preemption.

Precedence call CDR examples

  1. A call to another IP phone occurs by dialing a precedence pattern (precedence level 2).

    Field Names

    Precedence Call CDR

    globalCallID_callId

    100

    origLegCallIdentifier

    12345

    destLegCallIdentifier

    12346

    callingPartyNumber

    2001

    origCalledPartyNumber

    826001

    origCause_Value

    0

    dest_CauseValue

    16

    origPrecedenceLevel

    2

    destPrecedenceLevel

    2

  2. A precedence call gets received from another network (precedence level 1).

    Field Names

    Precedence Call CDR

    globalCallID_callId

    102

    origLegCallIdentifier

    11111

    destLegCallIdentifier

    11112

    callingPartyNumber

    9728552001

    origCalledPartyNumber

    6001

    origCause_Value

    16

    dest_CauseValue

    0

    origPrecedenceLevel

    1

    destPrecedenceLevel

    1

  3. A call gets preempted by a higher precedence level call.

    Field Names

    Original call CDR

    Higher Level Call CDR

    globalCallID_callId

    10000

    10001

    origLegCallIdentifier

    12345678

    12345680

    destLegCallIdentifier

    12345679

    12345681

    callingPartyNumber

    2001

    9728551234

    origCalledPartyNumber

    826001

    826001

    origCause_Value

    0

    0

    dest_CauseValue

    9

    16

    origPrecedenceLevel

    2

    1

    destPrecedenceLevel

    2

    1

Redirection (3xx) calls

This example shows CDRs for a the redirection feature (3xx).

When a call is redirected by the Redirection Feature (3xx), the origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf fields specify Unified CM Redirection = 19. The origCalledPartyRedirectReason and the lastRedirectRedirectReason fields specify Redirection = 162.

Redirection (3xx) CDR example

Activate CFA on phone 10010 that is running SIP (registered to Cisco Unified Communications Manager) with a CFA destination of 10000. 35010 calls 10010, which is CFA to 10000. The call gets redirected from 10010 to 10000. 10000 answers the call and talks for 1 minute.

Field Names

Original Call CDR

globalCallID_callId

11

origLegCallIdentifier

21832023

destLegCallIdentifier

21832026

callingPartyNumber

35010

originalCalledPartyNumber

10010

finalCalledPartyNumber

10000

lastRedirectDn

10010

origCause_Value

0

dest_CauseValue

16

origCalledPartyRedirectReason

162

lastRedirectRedirectReason

162

origCalledPartyRedirectOnBehalfOf

19

lastRedirectRedirectOnBehalfOf

19

origTerminationOnBehalfOf

0

destTerminationOnBehalfOf

12

joinOnBehalfOf

19

duration

60

Refer calls

See the replaces calls topic for an example of Refer with Replaces.

Related References

Replaces calls

The examples show CDRs for various types of Replaces calls.

Replaces CDR examples

  1. Invite with Replaces – Phone 35010 that is running SIP calls phone 35020 that is running SIP. The transfer button gets pressed on 35010, and a call gets placed to SCCP phone 3000, 3000 answers the call; then, phone 35010 completes the transfer. The final transferred call occurs between 35020 and 3000.

    Note


    When the transfer is complete, the system sends an Invite with Replaces to Cisco Unified Communications Manager.


    Field Names

    Original Call CDR

    Reverted Call CDR

    globalCallID_callId

    5045247

    5045248

    origLegCallIdentifier

    21822467

    21822469

    destLegCallIdentifier

    21822468

    21822468

    callingPartyNumber

    35010

    35020

    originalCalledPartyNumber

    3000

    3000

    finalCalledPartyNumber

    3000

    3000

    lastRedirectDn

    3000

    35010

    origCause_Value

    393216

    0

    dest_CauseValue

    393216

    16

    origCalledPartyRedirectReason

    0

    0

    lastRedirectRedirectReason

    0

    146

    origCalledPartyRedirectOnBehalfOf

    0

    0

    lastRedirectRedirectOnBehalfOf

    0

    18

    origTerminationOnBehalfOf

    18

    0

    destTerminationOnBehalfOf