The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
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.
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.
The system populates the bandwidth fields based on the following table:
This example applies to a call with AAC-LD (mpeg4-generic) codec:
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.
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 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.
CDR6: Dave -> Conference Bridge (conference call) |
||||||
---|---|---|---|---|---|---|
3 |
||||||
22 |
||||||
26 |
||||||
1003 |
||||||
b0029901222 |
||||||
b0029901222 |
||||||
1003 |
||||||
4 |
||||||
4 |
||||||
98 |
||||||
4 |
||||||
0 |
0 |
0 |
0 |
0 |
||
0 |
0 |
0 |
0 |
2222 |
2222 |
|
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 |
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 |
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. |
CDR6: Carol -> Conference Bridge (conference call) |
||||||
---|---|---|---|---|---|---|
3 |
||||||
22 |
||||||
25 |
||||||
1003 |
||||||
b0029901001 |
b0029901222 |
|||||
b0029901001 |
b0029901222 |
|||||
1003 |
||||||
10 |
||||||
10 |
||||||
98 |
||||||
4 |
||||||
0 |
0 |
0 |
0 |
0 |
||
0 |
0 |
0 |
0 |
1111 |
2222 |
|
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 |
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 |
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.
CDR6: Carol -> Conference Bridge (conference call) |
||||||
---|---|---|---|---|---|---|
3 |
||||||
22 |
||||||
25 |
||||||
1002 |
||||||
b0029901001 |
b0029901222 |
|||||
b0029901001 |
b0029901222 |
|||||
1003 |
||||||
10 |
||||||
10 |
||||||
98 |
||||||
4 |
||||||
0 |
0 |
0 |
0 |
0 |
||
0 |
0 |
0 |
0 |
1111 |
2222 |
|
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) |
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 |
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. |
CDR6: Carol -> Conference Bridge (conference call) |
||||||
---|---|---|---|---|---|---|
3 |
||||||
22 |
||||||
25 |
||||||
1002 |
||||||
b0029901001 |
b0029901222 |
|||||
b0029901001 |
b0029901222 |
|||||
1003 |
||||||
10 |
||||||
10 |
||||||
98 |
||||||
4 |
||||||
0 |
0 |
0 |
0 |
0 |
||
0 |
0 |
0 |
0 |
1111 |
2222 |
|
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 |
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 |
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.
CDR6: Carol -> Conference Bridge (conference call) |
||||||
---|---|---|---|---|---|---|
3 |
||||||
22 |
||||||
25 |
||||||
1002 |
||||||
b0029901001 |
b0029901222 |
|||||
b0029901001 |
b0029901222 |
|||||
1003 |
||||||
10 |
||||||
10 |
||||||
98 |
||||||
4 |
||||||
0 |
0 |
0 |
0 |
0 |
||
0 |
0 |
0 |
0 |
1111 |
2222 |
|
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 |
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 |
ConfControllerDn=10 03;ConfControllerDe viceName=SEP0003E33 3FAD1;ConfRequestor Dn-1003;ConfRequest orDeviceName=SEP000 3E333FAD1 |
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.
The customer (1001) calls the agent (1006).
The agent (1006) answers the call. The customer and the agent connect.
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.
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.
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.
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. |
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 |
|||
destLegCallIdentifier |
|||
callingPartyNumber |
|||
origCalledPartyNumber |
|||
finalCalledPartyNumber |
|||
lastRedirectDn |
|||
origCause_Value |
|||
dest_CauseValue |
|||
origCalledPartyRedirectReason |
0 |
114 |
0 |
lastRedirectRedirectReason |
|||
lastRedirectRedirectOnBehalfOf |
|||
joinOnBehalfOf |
|||
destConversationID |
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 |
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.
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.
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.
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.
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.
50003 calls 50002; 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code (44444).
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 Example – 50003 calls 50002; 50002 presses the Park softkey. Nobody picks up the parked call; the parked call reverts to 50002, and 50002 answers.
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.
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.
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 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. |
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.
Note | If the CDR Log Calls with Zero Duration Flag service parameter is set to true, two additional server call records are created. |
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.
Recording Call CDR2 |
|||
---|---|---|---|
11 |
|||
16777122 |
|||
16777123 |
|||
BIB |
|||
90000 |
|||
90000 |
|||
90000 |
|||
0 |
|||
0 |
|||
354 |
|||
354 |
|||
27 |
|||
27 |
|||
16777111 |
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.
Recording Call CDR 2 |
|||
---|---|---|---|
110 |
|||
16777222 |
|||
16777223 |
|||
BIB |
|||
90000 |
|||
90000 |
|||
90000 |
|||
16 |
|||
0 |
|||
354 |
|||
354 |
|||
27 |
|||
27 |
|||
16777113 |
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.
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.
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.
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.
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).
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.
40003 calls 40001, and 40001 answers; 40001' (shared line) on another phone presses the cBarge button.
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.
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.
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:
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. |
Conference CDR 2 |
Conference CDR 3 |
Final CDR |
||||
---|---|---|---|---|---|---|
1 |
||||||
101 |
||||||
102 |
||||||
2001 |
||||||
b0029901001 |
b0029901001 |
b0029901001 |
2309 |
|||
3071111 |
b0029901001 |
b0029901001 |
b0029901001 |
2309 |
||
3071111 |
b0029901001 |
b0029901001 |
b0029901001 |
b0029901001 |
||
98 |
||||||
4 |
0 |
0 |
4 |
|||
0 |
0 |
4 |
4 |
4 |
0 |
|
0 |
4 |
4 |
4 |
4 |
||
4 |
4 |
4 |
4 |
|||
0 |
1 |
0 |
||||
Three major operational factors exist for conference call CDRs:
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.
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.
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:
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.
The following table contains an example CDR for a call that connects to a conference and gets dropped by this feature.
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.
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).
Note | No originalCallingParty field exists in the CDR. |
These fields identify the Dual Tone Multi-Frequency (DTMF) method that gets used for the call.
No Preference Example - The DTMF method that gets used during this call represents No Preference/Best Effort. This call connects for 1 minute.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
The system populates the bandwidth fields based on the following table:
This example applies to a call with iLBC codec.
A call is made to PSTN. The gateway has it in the learned IME route and the call is extended to IME trunk. Call is successfully routed out through IME trunk.
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
lastRedirectRedirectOnBehalfOf |
30 |
lastRedirectRedirectReason |
0 |
duration |
10 |
A call is made to PSTN. The gateway has it in the learned IME route and the call is extended to IME trunk. The IME trunk rejects the call, and the call treatment does not cause the call to be redirected to the PSTN, so the call gets rejected. Depending on the reason of IME trunk reject, different lastRedirectRedirectReason can be reported.
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
origTerminationOnBehalfOf |
30 |
lastRedirectRedirectOnBehalfOf |
30 |
lastRedirectRedirectReason |
496 OR 512 OR 528 OR 544 OR 560 OR 576 OR 592 OR 608 OR 624 OR 640 OR 656 OR 672 OR 688 OR 704 |
origCause_Value |
31 |
duration |
0 |
A call is made to PSTN. The gateway has it in the learned IME route and the call is extended to IME trunk. The IME Trunk rejects the call, and the call treatment DOES cause the call to be redirected to the PSTN, so the call gets rejected. Depending on reason of IME trunk reject, different lastRedirectRedirectReason can be reported.
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
lastRedirectRedirectOnBehalfOf |
30 |
lastRedirectRedirectReason |
496 OR 512 OR 528 OR 544 OR 560 OR 576 OR 592 OR 608 OR 624 OR 640 OR 656 OR 672 OR 688 OR 704 |
duration |
10 |
A call is made to PSTN. The gateway has it in the learned IME route and the call is extended to IME trunk. Call is routed out through IME trunk. Bad QoS later discovered and call falls back to PSTN.
Two CDRs are generated in this case; one for the IME call and one for fallback to PSTN call.
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
OrigTerminationOnBehalfOf |
30 |
lastRedirectRedirectOnBehalfOf |
30 |
origCause_value |
132 |
duration |
5 |
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
lastRedirectRedirectOnBehalfOf |
31 |
joinOnBehalfOf |
31 |
lastRedirectRedirectReason |
722 |
duration |
5 |
A call is made to PSTN. The gateway has it in the learned IME route and the call is extended to IME trunk. Call is routed out through IME trunk. Bad QoS is discovered later and fall back initiated to PSTN. Call is rejected by PSTN gateway. Call is intercepted by Fallback Manager which clears the call. IME call remains untouched.
Two CDRs are generated in this case; one for the IME call and one for fallback to PSTN call.
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
lastRedirectRedirectOnBehalfOf |
30 |
lastRedirectRedirectReason |
0 |
duration |
5 |
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
OrigTerminationOnBehalfOf |
31 |
origCause_value |
Existing PSTN GW cause codes |
duration |
0 |
A call is made to PSTN. The gateway has it in the learned IME route and the call is extended to IME trunk. Call is routed out through IME trunk. Bad QoS is discovered later and fall back initiated to PSTN. Cannot find link to IME call. Call is intercepted by Fallback Manager which clears the call. IME call remains untouched.
Two CDRs are generated in this case; one for the IME call and one for fallback to PSTN call.
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
lastRedirectRedirectOnBehalfOf |
30 |
lastRedirectRedirectReason |
0 |
duration |
5 |
Field Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
callingPartyNumber |
2001 |
originalCalledPartyNumber |
9728134987 |
OrigTerminationOnBehalfOf |
31 |
origCause_value |
133 OR 134 OR existing cause codes |
duration |
0 |
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 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. |
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.
The incoming invite to Cisco Unified Communications Manager contains:
Icid: 5802170000010000000000A85552590A (say, PCV1) and orig_ioi: rcdn-85.swyan.open-ims.test (say, IOI_1).
The INVITE from the Cisco Unified Communications Manager to IMS B will have the same icid as 5802170000010000000000A85552590A (PCV1), orig_ioi as rcdn-85.swyan.open-ims.test (IOI_1).
CDR |
Side A |
Side B |
||||
---|---|---|---|---|---|---|
parties |
icid |
orig_ioi |
term_ioi |
icid |
orig_ioi |
term_ioi |
A-B |
PCV1 |
IOI_1 |
IOI_2 |
PCV1 |
IOI_1 |
IOI_2 |
Fields Names |
CDR |
---|---|
globalCallID_callId |
3 |
origLegCallIdentifier |
300 |
destLegCallIdentifier |
301 |
origDeviceName |
CUCM_ISC_TRUNK1 |
destDeviceName |
CUCM_ISC_TRUNK2 |
IncomingICID |
5802170000010000000000A85552590A |
IncomingOrigIOI |
rcdn-85.swyan.open-ims.test |
IncomingTermIOI |
rcdn-86.swyan.open-ims.test |
OutgoingICID |
5802170000010000000000A85552590A |
OutgoingOrigIOI |
rcdn-85.swyan.open-ims.test |
OutgoingTermIOI |
rcdn-86.swyan.open-ims.test |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The following CDR gets created if the Dallas gateway gets selected.
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).
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.
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.
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.
The following table contains an example CDR of a customer call that gets marked as malicious.
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).
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.
The following call detail record (CDR) fields apply specifically to Mobility calls. If the call does not invoke a mobility feature, these fields remain empty:
mobileCallingPartyNumber
finalMobileCalledPartyNumber
origMobileDeviceName
destMobileDeviceName
origMobileCallDuration
destMobileCallDuration
mobileCallType
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 Mobility. If any of the following OnBehalfOf fields has the Mobility code of 24, the CDR has the Mobility call type:
The following table displays the field values for the mobileCallType CDR field. Cisco Analysis and Reporting (CAR) uses the mobileCallType field to determine the CAR call type. If a single call invokes more than one mobility feature, the value of the mobileCallType field will represent the integer values added together. For example, if a call uses the Mobile Connect feature and then invokes Hand-Out, the mobile call type will be 136 (8 + 128).
Mobility Feature |
mobileCallType Value |
---|---|
Nonmobility call |
0 |
Dial via Office Reverse Callback |
1 |
Dial via Office Forward |
2 |
Reroute remote destination call to enterprise network |
4 |
Mobile Connect |
8 |
Interactive Voice Response |
10 |
Enterprise Feature Access |
20 |
Hand-In |
40 |
Hand-Out |
80 |
Redial |
100 |
Least Cost Routing with dial-via-office reverse callback |
200 |
Least Cost Routing with dial-via-office forward |
82 |
Send call to mobile |
800 |
Session handoff |
1000 |
In legacy deployments prior to 10.0, CAR uses the lastRedirectReason field to identify the mobility call type. The following table shows the Mobility values for lastRedirectReason.
Mobility Feature |
lastRedirectReason Value |
---|---|
Hand-In |
303 |
Hand-Out |
319 |
Mobile Connect |
335 |
Redial |
351 |
Interactive Voice Response |
399 |
Dial via Office Reverse Callback |
401 |
Enterprise Feature Access |
402 |
Session Handoff |
403 |
Send call to mobile |
415 |
Reroute remote destination call to enterprise network |
783 |
The following examples demonstrate how mobility features display in CDR records:
Mobile phone initiates Dial via Office Reverse Callback - A mobile phone with a device name of BOTSAU, a mobile number of 2145551234, and an enterprise number of 1000 invokes the dial-via-office Reverse callback feature to place a call to extension 2000. The MAC address of the called device is SEP001FCAE90004. The IP address of the SIP gateway is 10.194.108.70. The total call duration is 55 seconds.
Field |
Dial via Office Reverse Callback CDR |
---|---|
origCallTerminationOnBehalfOf |
0 |
destCallTerminationOnBehalfOf |
12 |
origCalledRedirectOnBehalfOf |
24 |
lastRedirectOnBehalfOf |
24 |
joinOnBehalfOf |
24 |
origCalledPartyRedirectReason |
401 |
lastRedirectReason |
401 |
origDeviceName |
10.194.108.70 |
destDeviceName |
SEP001FCAE9004 |
finalCalledPartyNumber |
2000 |
huntPilotDN |
|
mobileCallingPartyNumber |
2145551234 |
finalMobileCalledPartyNumber |
|
origMobileDeviceName |
BOTSAU |
destMobileDeviceName |
|
origMobileCallDuration |
55 |
destMobileCallDuration |
|
mobileCallType |
1 |
Mobile phone initiates Dial via Office Forward - Mobile phone 2145551234 initiates the Dial via Office Forward feature to place a call. The mobile phone has a device name of BOTSAU and is mapped to enterprise number 1000. The called number is extension 823006 with a device MAC address of SEP001FCAE90004. The call crosses a SIP gateway at 10.194.108.70 and lasts for a total duration of 120 seconds.
Field |
Dial via Office Forward CDR |
---|---|
origCallTerminationOnBehalfOf |
0 |
destCallTerminationOnBehalfOf |
12 |
origCalledRedirectOnBehalfOf |
0 |
lastRedirectOnBehalfOf |
0 |
joinOnBehalfOf |
0 |
origCalledPartyRedirectReason |
0 |
lastRedirectReason |
0 |
origDeviceName |
10.194.108.70 |
destDeviceName |
SEP001FCAE90004 |
finalCalledPartyNumber |
823006 |
huntPilotDN |
|
mobileCallingPartyNumber |
2145551234 |
finalMobileCalledPartyNumber |
|
origMobileDeviceName |
BOTSAU |
destMobileDeviceName |
|
origMobileCallDuration |
120 |
destMobileCallDuration |
0 |
mobileCallType |
2 |
Call to remote destination is rerouted to enterprise number - Cisco Unified IP Phone SEP001FCAE90004, at extension 2000, dials mobile number 2145551234. The destination mobile phone is mapped to enterprise number 1000 and has the Reroute Remote Destination Calls to Enterprise Number service parameter enabled in Cisco Unified Communications Manager. Cisco Unified Communications Manager reroutes the mobile call to enterprise number 1000. The call crosses SIP gateway GW_SIP and lasts for a total duration of 60 seconds.
Field |
Reroute Remote Detination CDR |
---|---|
origCallTerminationOnBehalfOf |
0 |
destCallTerminationOnBehalfOf |
12 |
origCalledRedirectOnBehalfOf |
24 |
lastRedirectOnBehalfOf |
24 |
joinOnBehalfOf |
0 |
origCalledPartyRedirectReason |
783 |
lastRedirectReason |
783 |
origDeviceName |
SEP001FCAE90004 |
destDeviceName |
GW_SIP |
finalCalledPartyNumber |
1000 |
huntPilotDN |
|
mobileCallingPartyNumber |
|
finalMobileCalledPartyNumber |
2145551234 |
origMobileDeviceName |
|
destMobileDeviceName |
2145551234:rdp |
origMobileCallDuration |
0 |
destMobileCallDuration |
60 |
mobileCallType |
4 |
Mobile phone invokes deskphone call pickup - Cisco Unified IP Phone SEP001FCAE90004 calls extension 1000, which is shared between a desk phone and a mobile device. The mobile phone answers the call and then hangs up, triggering the dekstop pickup feature. The desktop call pickup timer runs for about 10 seconds before expiring. After the timer expires, the call is resumed on a Wi-Fi device for another 10 seconds.
Field |
Desktop Call Pickup CDR |
---|---|
origCallTerminationOnBehalfOf |
0 |
destCallTerminationOnBehalfOf |
12 |
origCalledRedirectOnBehalfOf |
0 |
lastRedirectOnBehalfOf |
0 |
joinOnBehalfOf |
0 |
origCalledPartyRedirectReason |
0 |
lastRedirectReason |
0 |
origDeviceName |
SEP001FCAE90004 |
destDeviceName |
GW_SIP |
finalCalledPartyNumber |
1000 |
huntPilotDN |
|
mobileCallingPartyNumber |
|
finalMobileCalledPartyNumber |
|
origMobileDeviceName |
|
destMobileDeviceName |
|
origMobileCallDuration |
0 |
destMobileCallDuration |
10 |
mobileCallType |
8 |
Mobile Connect Call - Single Number Reach Voicemail policy set to Timer Control - Cisco Unified IP Phone SEP001FCAE90004, at extension 2000, calls enterprise number 1000. Mobile Connect is invoked and both the desk phone and mobile phone ring. The mobile phone uses a mobile identity with a device name of BOTSARAH. The Single Number Reach Voicemail policy is set to Timer Control. The call traverses a SIP gateway and lasts for 10 minutes.
Field |
CDR |
---|---|
origCallTerminationOnBehalfOf |
0 |
destCallTerminationOnBehalfOf |
12 |
origCalledRedirectOnBehalfOf |
0 |
lastRedirectOnBehalfOf |
0 |
joinOnBehalfOf |
0 |
origCalledPartyRedirectReason |
0 |
lastRedirectReason |
0 |
origDeviceName |
SEP001FCAE90004 |
destDeviceName |
GW_SIP |
finalCalledPartyNumber |
1000 |
huntPilotDN |
|
mobileCallingPartyNumber |
|
finalMobileCalledPartyNumber |
2145551234 |
origMobileDeviceName |
|
destMobileDeviceName |
BOTSARAH |
origMobileCallDuration |
0 |
destMobileCallDuration |
10 |
mobileCallType |
8 |
Mobile Connect Call - Single Number Reach Voicemail Policy set to UserControl Mode -Cisco Unified IP Phone SEP001FCAE91231 at enterprise number 238011 calls across a SIP gateway, GW_SIP. The called party is SEP001FCEA91289, at enterprise number 238006 and mobile number 14089022179. Three CDRs are produced.
Field |
Announcement to user |
0 Duration Call |
IP Phone to Mobile Phone |
---|---|---|---|
origCallTerminationOnBehalfOf |
24 |
24 |
12 |
destCallTerminationOnBehalfOf |
24 |
24 |
24 |
origCalledRedirectOnBehalfOf |
24 |
24 |
24 |
lastRedirectOnBehalfOf |
24 |
24 |
24 |
joinOnBehalfOf |
0 |
0 |
24 |
origCalledPartyRedirectReason |
335 |
335 |
335 |
lastRedirectReason |
335 |
335 |
335 |
origDeviceName |
SEP001FCAE91231 |
ParkingLotDevice |
SEP001FCAE91231 |
destDeviceName |
GW_SIP |
GW_SIP |
GW_SIP |
finalCalledPartyNumber |
238006 |
238006 |
238006 |
huntPilotDN |
|||
mobileCallingPartyNumber |
|||
finalMobileCalledPartyNumber |
14089022179 |
14089022179 |
14089022179 |
origMobileDeviceName |
|||
destMobileDeviceName |
14089022179:rdp |
14089022179:rdp |
14089022179:rdp |
origMobileCallDuration |
0 |
0 |
|
destMobileCallDuration |
3 |
6 |
|
mobileCallType |
8 |
8 |
8 |
Mobile phone makes an Enterprise Feature Access (EFA) call with two-stage dialing - Remote destination deepak-RDP, at 4089022179 with shared-line desk phone SEP001EBE90DE95 and enterprise number 238006, calls internal desk phone SEP001FCAE91231, at enterprise number 238011, using Enterprise Feature Access two-stage dialing. Total call duration is 30 seconds. Two CDRs are produced: one for the mobile phone dialing the EFA access codes into Cisco Unified Communications Manager and the second for the mobile phone to desk phone conversation.
Field |
Mobile Phone to Unified Communications Manager |
Mobile Phone to Desk Phone |
---|---|---|
origCallTerminationOnBehalfOf |
24 |
12 |
destCallTerminationOnBehalfOf |
24 |
24 |
origCalledRedirectOnBehalfOf |
24 |
24 |
lastRedirectOnBehalfOf |
24 |
24 |
joinOnBehalfOf |
24 |
24 |
origCalledPartyRedirectReason |
402 |
402 |
lastRedirectReason |
402 |
402 |
origDeviceName |
GW_SIP |
GW_SIP |
destDeviceName |
ParkingLotDevice |
SEP001FCAE91231 |
finalCalledPartyNumber |
00111101001 |
238011 |
huntPilotDN |
||
mobileCallingPartyNumber |
14089022179 |
14089022179 |
finalMobileCalledPartyNumber |
||
origMobileDeviceName |
14089022179:rdp |
14089022179:rdp |
destMobileDeviceName |
||
origMobileCallDuration |
5 |
25 |
destMobileCallDuration |
0 |
|
mobileCallType |
32 |
32 |
Mobile phone makes a Mobile Voice Access call - Remote destination 4089022179, with shared line desk phone SEP001EBE90DE95 at enterpise number 238006, uses Mobile Voice Access to call an internal desk phone SEP00000000000002 at enterprise number 238011. The remote destination has a remote destination profile of deepak-rdp. The call traverses SIP gateway GW_SIP and lasts for 60 seconds.
Field |
Mobile Phone to Desk Phone |
---|---|
origCallTerminationOnBehalfOf |
12 |
destCallTerminationOnBehalfOf |
0 |
origCalledRedirectOnBehalfOf |
24 |
lastRedirectOnBehalfOf |
24 |
joinOnBehalfOf |
24 |
origCalledPartyRedirectReason |
399 |
lastRedirectReason |
399 |
origDeviceName |
GW_SIP |
destDeviceName |
SEP00000000000002 |
finalCalledPartyNumber |
238011 |
huntPilotDN |
|
mobileCallingPartyNumber |
14089022179 |
finalMobileCalledPartyNumber |
|
origMobileDeviceName |
14089022179:rdp |
destMobileDeviceName |
|
origMobileCallDuration |
60 |
destMobileCallDuration |
|
mobileCallType |
16 |
Mobility Hand-In - Cisco Unified IP Phone SEP001FCAE91231 at enterprise number 238011, calls enterprise number 238006, which is unregistered on the VoIP side, but registered to the smartphone TCTSAU. The mobile identity of the smartphone is 14089022179. At the beginning of the call TCTSAU is located in a cellular network, but the device moves into Wi-Fi range and the Hand-In feature is invoked to move the call into the enterprise. The total call duration is 85 seconds, with the called device in Wi-Fi range for the last 30 seconds.
Field |
IP Phone to Cellular Phone |
IP Phone to IP Phone |
---|---|---|
origCallTerminationOnBehalfOf |
24 |
12 |
destCallTerminationOnBehalfOf |
24 |
24 |
origCalledRedirectOnBehalfOf |
0 |
0 |
lastRedirectOnBehalfOf |
0 |
24 |
joinOnBehalfOf |
0 |
24 |
origCalledPartyRedirectReason |
0 |
303 |
lastRedirectReason |
0 |
303 |
origDeviceName |
SEP001FCAE91231 |
SEP001FCAE91231 |
destDeviceName |
GW_SIP |
TCTSAU |
finalCalledPartyNumber |
238006 |
238006 |
huntPilotDN |
||
mobileCallingPartyNumber |
||
finalMobileCalledPartyNumber |
14089022179 |
|
origMobileDeviceName |
||
destMobileDeviceName |
TCTSAU |
|
origMobileCallDuration |
0 |
0 |
destMobileCallDuration |
55 |
|
mobileCallType |
8 |
72 |
Mobility Hand-Out - Cisco Unified IP Phone SEP001FCAE94005 at enterprise number 238011, calls a dual-mode smartphone with a mobile identity of 14089022179, at enterprise number 238006. The smartphone is in local Wi-Fi range when the call is answered and the two parties speak for 27 seconds. The smartphone moves out of the enterprise network and the call is switched to the cell network, after which the parties continue to speak for another 25 seconds.
Field |
IP Phone to IP Phone |
IP Phone to Cell Network |
---|---|---|
origCallTerminationOnBehalfOf |
24 |
0 |
destCallTerminationOnBehalfOf |
24 |
12 |
origCalledRedirectOnBehalfOf |
0 |
0 |
lastRedirectOnBehalfOf |
0 |
24 |
joinOnBehalfOf |
0 |
24 |
origCalledPartyRedirectReason |
0 |
0 |
lastRedirectReason |
0 |
319 |
origDeviceName |
SEP001FCAE94005 |
SEP001FCAE94005 |
destDeviceName |
TCTSAU |
GW_SIP |
finalCalledPartyNumber |
238006 |
238006 |
huntPilotDN |
||
mobileCallingPartyNumber |
||
finalMobileCalledPartyNumber |
14089022179 |
|
origMobileDeviceName |
||
destMobileDeviceName |
TCTSAU |
|
origMobileCallDuration |
0 |
0 |
destMobileCallDuration |
0 |
23 |
mobileCallType |
0 |
128 |
Mobile phone invokes Least Cost Routing Hand-Out using Dial via Office Reverse Callback - A dual-mode phone, BOTSAU, with a mobile identity of 14089022179, is within the enterprise wifi network and registered to enterprise number 238006. The phone invokes Dial via Office Reverse Callback (DVOR) using least cost routing to call enterprise number 238011. The two parties speak for 25 seconds, but the mobile phone moves out of Wi-Fi range, tiggering the handout feature to the cellular network. On the cell network, the two parties speak for another 35 seconds.
Field |
DVOR callback |
IP phone to IP phone |
Mobile phone to IP phone |
---|---|---|---|
origCallTerminationOnBehalfOf |
24 |
24 |
0 |
destCallTerminationOnBehalfOf |
24 |
24 |
12 |
origCalledRedirectOnBehalfOf |
0 |
0 |
0 |
lastRedirectOnBehalfOf |
0 |
0 |
24 |
joinOnBehalfOf |
0 |
0 |
24 |
origCalledPartyRedirectReason |
0 |
0 |
0 |
lastRedirectReason |
0 |
0 |
319 |
origDeviceName |
ParkingLotDevice |
BOTSAU |
GW_SIP |
destDeviceName |
GW_SIP |
SEP001FCAE91231 |
SEP001FCAE91231 |
finalCalledPartyNumber |
238006 |
238011 |
238011 |
huntPilotDN |
|||
mobileCallingPartyNumber |
14089022179 |
||
finalMobileCalledPartyNumber |
14089022179 |
||
origMobileDeviceName |
BOTSAU |
||
destMobileDeviceName |
BOTSAU |
||
origMobileCallDuration |
0 |
0 |
35 |
destMobileCallDuration |
0 |
0 |
|
mobileCallType |
0 |
0 |
512 |
Mobile Phone invokes Least Cost Routing Hand-Out using Dial via Office Forward - A dual-mode phone, BOTSAU, with a mobile number of 14089022179, is mapped to enterprise number 238006 and is within Wi-Fi range of the enterprise. The phone invokes Dial via Office Forward with least cost routing to place a call to enterprise number 238011, which is registered to a Cisco Unified IP Phone SEP001FCAE91006. The two parties talk for 30 seconds before the mobile phone moves out of Wi-Fi range and the call is handed out to the cell network, following which the call continues for another 25 seconds.
Field |
IP Phone to IP Phone |
Mobile Phone to IP Phone |
---|---|---|
origCallTerminationOnBehalfOf |
24 |
12 |
destCallTerminationOnBehalfOf |
24 |
0 |
origCalledRedirectOnBehalfOf |
0 |
0 |
lastRedirectOnBehalfOf |
0 |
24 |
joinOnBehalfOf |
0 |
24 |
origCalledPartyRedirectReason |
0 |
0 |
lastRedirectReason |
0 |
319 |
origDeviceName |
BOTSAU |
GW_SIP |
destDeviceName |
SEP001FCAE91006 |
SEP001FCAE91006 |
finalCalledPartyNumber |
238011 |
238011 |
huntPilotDN |
||
mobileCallingPartyNumber |
14089022179 |
|
finalMobileCalledPartyNumber |
||
origMobileDeviceName |
BOTSAU |
|
destMobileDeviceName |
||
origMobileCallDuration |
0 |
0 |
destMobileCallDuration |
0 |
25 |
mobileCallType |
0 |
130 |
Send Call to Mobile - A Cisco Unified IP Phone SEP001FCAE90001 at 238011, makes a call to enterprise number 238006. The called party answers the call on Cisco Unified IP Phone SEP001FCAE90022. The conversation continues for 45 seconds before the called party presses the Mobility soft key to send the call to the mobile phone, BOTSAU, at 12145551234. The call continues on the mobile phone for another 35 seconds. The total call duration is 55 seconds.
Field |
Announcement |
IP Phone to IP Phone |
IP Phone to Mobile Phone |
---|---|---|---|
origCallTerminationOnBehalfOf |
24 |
24 |
24 |
destCallTerminationOnBehalfOf |
24 |
24 |
12 |
origCalledRedirectOnBehalfOf |
0 |
0 |
0 |
lastRedirectOnBehalfOf |
0 |
0 |
24 |
joinOnBehalfOf |
0 |
0 |
24 |
origCalledPartyRedirectReason |
0 |
0 |
0 |
lastRedirectReason |
0 |
0 |
415 |
origDeviceName |
SEP001FCAE90001 |
SEP001FCAE90001 |
SEP001FCAE90001 |
destDeviceName |
GW_SIP |
SEP001FCAE90022 |
GW_SIP |
finalCalledPartyNumber |
238006 |
238006 |
238006 |
huntPilotDN |
|||
mobileCallingPartyNumber |
|||
finalMobileCalledPartyNumber |
12145551234 |
12145551234 |
|
origMobileDeviceName |
|||
destMobileDeviceName |
BOTSAU |
BOTSAU |
|
origMobileCallDuration |
0 |
0 |
0 |
destMobileCallDuration |
0 |
0 |
35 |
mobileCallType |
0 |
0 |
2048 |
Session Handoff - Cisco Unified IP Phone SEP001FCAE90001, at extension 1000, calls extension 2500. The phone rings at both a desk phone and a mobile phone. The called party answers on a mobile phone, BOTSAU at mobile number 2145551234 and a conversation begins. After 35 seconds, the called party triggers the Session Handoff feature and transfers the call to a desk phone. The call continues on desk phone SEP001FCAE90022 for another 60 seconds.
Field |
Parking Lot to Desk Phone |
IP Phone to Mobile Phone |
IP Phone to IP Phone |
---|---|---|---|
origCallTerminationOnBehalfOf |
24 |
24 |
24 |
destCallTerminationOnBehalfOf |
24 |
24 |
12 |
origCalledRedirectOnBehalfOf |
0 |
0 |
0 |
lastRedirectOnBehalfOf |
0 |
0 |
24 |
joinOnBehalfOf |
0 |
0 |
24 |
origCalledPartyRedirectReason |
0 |
0 |
0 |
lastRedirectReason |
0 |
0 |
403 |
origDeviceName |
SEP001FCAE90001 |
SEP001FCAE90001 |
SEP001FCAE90001 |
destDeviceName |
SEP001FCAE90022 |
BOTSARAH |
SEP001FCAE90022 |
finalCalledPartyNumber |
2500 |
2500 |
2500 |
huntPilotDN |
|||
mobileCallingPartyNumber |
|||
finalMobileCalledPartyNumber |
2145551234 |
||
origMobileDeviceName |
|||
destMobileDeviceName |
BOTSARAH |
||
origMobileCallDuration |
0 |
0 |
0 |
destMobileCallDuration |
0 |
15 |
10 |
mobileCallType |
0 |
0 |
5096 |
The Native Call Queuing feature provides an enhanced capability to handle incoming calls to a hunt pilot number. Unified CM provides call queuing natively to users so that callers can be held in a queue until hunt members are available to answer them. Callers in a queue receive an initial greeting announcement followed by music on hold or tone on hold. If the caller remains in queue for a period of time, a secondary announcement is played at a configured interval until the call can be answered—or until the maximum wait timer expires.
Cisco Unified Communications Manager cluster has four IP Phones: DN 1000, 1001, 1002, and 1003.
A hunt pilot (HP) 2000 is created with line group DN 1000 associated with it. So, this hunt pilot 2000 can only handle one call. Now, Check the "Queuing" enabled flag on the hunt pilot 2000 configuration page. Set the "Max Call Waiting Timer" to be 30 seconds, and select "Route the call to this destination" to be DN 1003. Ideally, if a caller has been put into that queue for 30 seconds, then it will be routed to DN 1003.
Field Names |
CDR |
---|---|
globalCallID_callId |
87029 |
origLegCallIdentifier |
30117105 |
callingPartyNumber |
1002 |
originalCalledPartyNumber |
2000 |
wasCallQueued |
1 |
totalWaitTimeInQueue |
30 |
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.
A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.
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.
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).
Note | No originalCallingParty field exists in the CDR. |
This section contains information about Personal Assistant Calls.
A personal assistant direct call acts similar to the Blind Transfer from the Calling Party call type.
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.
This scenario acts similar to Blind Transfer from the Calling Party and Forwarded Calls actions.
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).
" " |
||||||||||
" " |
" " |
" " |
" " |
This scenario can have two different cases: with rules and with no rules.
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:
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.
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).
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)
" " |
" " |
" " |
" " |
" " |
" " |
" " |
|||||||
" " |
" " |
" " |
" " |
" " |
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. |
" " |
" " |
" " |
" " |
" " |
" " |
||||||||||
" " |
" " |
" " |
" " |
" " |
||||||||||
" " |
" " |
" " |
" " |
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. |
" " |
||||||||||
Personal assistant conferencing acts similar to the ad hoc conferences call type.
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.
" " |
|||||
" " |
|||||
" " |
This table continues with this additional information.
" " |
||||
" " |
||||
" " |
||||
" " |
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.
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.
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.
When the redirecting number transformation feature is enabled, original called and last redirecting number are transformed before it sends out in outgoing setup message.
On SIP trunk, redirecting party CSS is configured which has the partitions P1 and there is a Calling Party transformation pattern associated with P1. This pattern has external phone number mask enabled.
Scenario
A - calls Phone B ---- CFA - Phone C CFA --- SIP Trunk --- SIP Gateway
B - Original Called Party, C - Last Redirecting Party
There are 2 diversion headers corresponding to original and last redirecting party that is sent out in outgoing SIP INVITE message and these diversion headers have transformed redirecting number, that is, +91110001 and +91220002.
These values are also stored in CDR records. Transformed original called number will be stored in outpulsedOriginalCalledPartyNumber and transformed last redirecting number will be stored in outpulsedLastRedirectingNumber.
Field Names |
CDR |
---|---|
globalCallID_callId |
115010 |
origLegCallIdentifier |
30751507 |
callingPartyNumber |
180000 |
outpulsedCallingPartyNumber |
880003 |
outpulsedOriginalCalledPartyNumber |
+91110001 |
outpulsedLastRedirectingNumber |
+91220002 |
See the replaces calls topic for an example of Refer with Replaces.
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. |
Refer with Replaces – Phone 35010 that is running SIP calls SCCP 3000, the transfer button gets pressed on 35010, and a call is placed to SCCP 3001; 3001 answers the call; then, phone 35010 completes the transfer. The final transferred call occurs between 3000 and 3001.
Note | When the transfer completes, a Refer with Replaces gets sent to Cisco Unified Communications Manager. |
0 |
0 |
||
0 |
0 |
||
0 |
0 |
||
0 |
0 |
||
These fields identify the status of RSVP reservation for the call. Be aware that the Cisco Unified Communications Manager RSVP CDR status field value gets concatenated, and the system retains the last 32 status values for the call.
For example, if a call is established with "Optional" policy, and the initial RSVP reservation is successful, and then it subsequently loses its bandwidth reservation and then regains its bandwidth reservation after retry, for several times during middle of the call, the call ends with a successful RSVP reservation. The CDR shows the following string as the Unified Communication RSVP reservation status for that particular stream: "2:5:2:5:2:5:2" (success:lost_bw:success:lost_bw:success:lost_bw:success).
The example represents a call that gets established with "Optional" policy, and the initial RSVP reservation succeeds. The parties talk for 5 minutes.
The example represents a call that is established with "Optional" policy, and the initial RSVP reservation succeeds, then it loses its bandwidth reservation but regains it after a retry. The parties talk for 1 minute.
The following example shows a CDR for a meet-me secure conference. 35010 calls into a secure meet-me conference, but 35010 is a non-secure phone. Because 35010 does not meet the minimum security level of the meet-me conference, the call gets cleared with the cause code of 58 (meet-me conference minimum security level not met).
A short call, with a CdrLogCallsWithZeroDurationFlag set at True and a duration of less than 1 second, appears as a zero duration call in the CDR. The DateTimeConnect field, which shows the actual connect time of the call, differentiates these calls from failed calls. For failed calls (which never connected), this value equals zero.
The following table contains an example of a successful On Net call with a duration of less than 1 second that the called party cleared.
Calling and called parties can have SIP calls where the extension number is a URL. The extension number can use all printable ASCII characters. Do not leave any spaces in the URL. For example, extension "1000 1001" does not get accepted as a valid URL.
Note | Printable ASCII characters represent characters with ASCII code (in decimal) from 33 to 126. |
The SIP trunk of the Cisco Unified Communications Manager receives an incoming call. The call contains a SIP URL for the callingPartyNumber.
A successful call between two Cisco Unified IP Phones generates a single CDR at the end of the call.
The following table contains two examples:
Calls that are transferred generate multiple CDRs. One CDR exists for the original call, one for the consultation call, and another for the final transferred call.
For the original call, the origCause_value and destCause_value gets set to split = 393216, which indicates the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields get set to Transfer = 10 to indicate that this call was involved in a transfer.
For the consultation call, the origCause_value and destCause_value fields get set to split = 393216, which indicates that the call was split. The origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields get set to Transfer = 10 to indicate that this call was involved in a transfer.
For the final transferred call, the joinOnBehalfOf field gets set to Transfer = 10 to indicate that this call resulted from a transfer.
The following examples, which are not an exhaustive set, illustrate the records that would be generated under the stated circumstances. These examples help clarify what records are generated on transferred calls.
Call goes from extension 2001 to a PSTN number; they talk for 120 seconds. 2001 initiates a blind transfer to 2002. CDR 1 (original call) shows a call from extension 2001 to a PSTN number, talking for 120 seconds. CDR 2 (consultation call) shows a call from 2001 to extension 2002. CDR 3 represents the final transferred call where 2001 completes the transfer, drops out of the call, and leaves a call between the PSTN and 2002.
Call goes from extension 2001 to a PSTN number; they talk for 60 seconds. 2001 initiates a consultation transfer to 2002 and talks for 10 seconds before the transfer completes. The final transferred call talks for 360 seconds. CDR 1 (original call) shows a call from extension 2001 to a PSTN number, talking for 60 seconds. CDR 2 (consultation call) shows a call from 2001 to extension 2002, talking for 10 seconds. CDR 3 represents the final transferred call where 2001 completes the transfer, drops out of the call, and leaves a call between the PSTN and 2002.
Call goes from 50000 to 50001; they talk for 120 seconds. 50001 initiates a blind transfer to 50002. CDR 1 (original call) shows a call from extension 50001 to 50002, talking for 120 seconds. CDR 2 (consultation call) shows a call from 50001 to extension 50002. CDR 3 represents the final transferred call where 50001 completes the transfer, drops out of the call, and leaves a call between 50000 and 50002.
Call goes from 50000 to 50001; they talk for 120 seconds. 50000 initiates a blind transfer to 50002. CDR 1 (original call) shows a call from extension 50000 to a 50001, talking for 120 seconds. CDR 2 (consultation call) shows a call from 50000 to extension 50002. CDR 3 represents the final transferred call where 50000 completes the transfer, drops out of the call, and leaves a call between 50001 and 50002.
Calling party 51234 calls the called party 57890. In the following example, let 100 = H.261, 187962284 = 172.19.52.11, 288625580 = 172.19.52.17, 320 = 320K, and 2 = QCIF.
Calls that are part of a video conference have multiple records logged. The number of CDR records that are generated depends on the number of parties in the video conference. One CDR record exists for each party in the video conference, one for the original placed call, one for each setup call that was used to join other parties to the video conference, and one for the last two parties that are connected in the video conference.
Therefore, for a three party ad hoc video conference, six CDR records exist:
1 record for the original call
3 records for the parties that connected to the conference
1 record for each setup call
1 record 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 has 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.
All calls in or out of the conference bridge get shown going into the conference bridge, regardless of the actual direction. By examining the setup call CDR records, 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 identifies the conference controller. You need the device name in the case of shared lines.
If the call is involved in multiple conference calls, the comment field will contain multiple conference controller information. This could happen in case 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 will identify the conference controller.
The call legs that are connected to the conference will have the following fields information:
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 will have the following fields:
Call from 2001 to 2309; 2309 answers, and they talk for 60 seconds.
2001 presses the conference softkey and dials 3071111.
307111 answers and talks for 20 seconds; 2001 presses the conference softkey to complete the conference.
The three members of the conference talk for 360 seconds.
3071111 hangs up; 2001 and 2309 stay in the conference. Because only two participants remain in the conference, the conference feature joins the two directly together, and they talk for another 55 seconds.
Note | Each video conference call leg gets shown placing a call into the conference bridge. The call gets shown as a call into the bridge, regardless of the actual direction of the call. |