McDewey

Operational Factors Three major operational factors exist for conference call CDRs: 1. When a conference decreases to two parties, the two parties connect directly and release the conference resource. This change generates an additional CDR for the call between the last two parties in the conference call. For example, if four people connect in a conference call (Amy, Dustin, Spencer, Ethan), when Ethan hangs up, three people remain in the conference call that is connected to the conference bridge (Amy, Dustin, Spencer). When Spencer hangs up, only two people remain in the conference call (Amy and Dustin). The system joins Amy and Dustin directly, and, the conference resource gets released. Directly joining Amy and Dustin creates an additional CDR between the last two parties in the conference. 2. The system adds the conference controller information to the comment field in the CDR. This information identifies the conference controller. No need now exists to examine the consultation call to determine who is the conference controller. The following example shows this information: Comment field = “ConfControllerDn=1000;ConfControllerDeviceName=SEP0003E333FEBD” • The conference controller DN + conference controller device name uniquely identify the conference controller. A need for the device name exists in the case of shared lines. • If the call is involved in multiple conference calls, the comment field contains multiple conference controller information. This situation may occur when the conference goes down to two parties, and one of these parties starts another conference. If this is the case, the last conference controller information in the comment field identifies the conference controller. 3. The party that added the participant, known as the requestor party, appears in the CDR comment field. The tags for the requestor information include ConfRequestorDn and ConfRequestorDeviceName. The party that requested to remove a participant, known as the drop requestor, appears in the CDR comment field. The tags for the drop requestor information include DropConfRequestorDn and DropConRequestorDeviceName. Calls that are part of a conference have multiple records that are logged for them. The number of CDRs that get generated depends on the number of parties in the conference. One CDR exists for each party in the conference, one CDR for the original placed call, and one CDR for each setup call that is used to join other parties to the conference. Therefore, for a three-party ad hoc conference, six CDRs exist: • One CDR for the original call. • Three CDRs for the parties that are connected to the conference. • One CDR for each setup call. • One CDR for the final two parties in the conference. You can associate the setup calls with the correct call leg in the conference by examining the callinglegID and the calledlegID. The conference bridge device holds special significance to the 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: Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs 286 CDR Records Operational Factors