Cisco Unified Communications Manager Features and Services Guide, Release 9.1(1)
Monitoring and Recording
Download this chapter
Monitoring and RecordingMonitoring and Recording
Download the complete book
Cisco Unified Communications Manager Features and Services Guide, Release 9.1(1)Cisco Unified Communications Manager Features and Services Guide, Release 9.1(1) (PDF - 22 MB)
 Feedback

Contents

Monitoring and Recording

This chapter provides information about Silent Call Monitoring and Call Recording.

Call centers need to be able to guarantee the quality of customer service that an agent in a call center provides. To protect themselves from legal liability, call centers need to be able to archive agent-customer conversations.

The Silent Call Monitoring feature allows a supervisor to eavesdrop on a conversation between an agent and a customer; neither the agent nor the customer can hear the supervisor voice.

The Call Recording feature allows system administrators or authorized personnel to archive conversations between the agent and the customer.

Cisco Unified Communications Manager supports the Silent Call Monitoring and Call Recording features only within a single cluster. Cisco Business Edition 5000 supports the Silent Call Monitoring and Call Recording features.

Silent call monitoring specifies one of the three call monitoring modes.(The other modes specify whisper call monitoring and active call monitoring.) In whisper monitoring mode, the supervisor can listen to the conversation between an agent and a customer and can talk to the agent without making the customer aware of the presence of the supervisor. In active monitoring mode, the supervisor can participate fully in the conversation between the agent and the customer.

The Silent Monitoring and Call Recording features specify generic features in Cisco Unified Communications Manager. Cisco makes these features available to any deployment or installation where monitoring- and recording-enabled applications are available. Descriptions in this document use terms such as supervisor, agent, and customer to see the parties that participate in call monitoring and recording sessions.

Set up Monitoring and Recording

Call centers need to be able to guarantee the quality of customer service that an agent in a call center provides. To protect themselves from legal liability, call centers need to be able to archive agent-customer conversations.

The silent call monitoring feature allows a supervisor to eavesdrop on a conversation between an agent and a customer; neither the agent nor the customer can hear the supervisor voice. The call recording feature allows system administrators or authorized personnel to archive conversations between the agent and the customer.

Perform the following steps to set up monitoring and recording.

Procedure
    Step 1   Turn on IP phone BIB to allow monitoring or recording.
    Step 2   Add user for monitoring or recording application.
    Step 3   Add user to groups that allow monitoring and recording.
    Step 4   Optional. Configure tones for monitoring or recording.
    Step 5   Configure DN for a monitoring calling search space.
    Step 6   Enable recording for a line appearance.
    Step 7   Optional. Add the Record softkey or programmable line key to the device template.
    Step 8   Create a recording profile.
    Step 9   Optional. Create a SIP profile for recording.
    Step 10   Create a SIP trunk that points to the recorder.
    Step 11   Create a route pattern for the recorder.
    Step 12   Configure recorder redundancy.

    Monitoring and Recording feature

    This section describes call monitoring and recording.

    Terminology for Call Monitoring and Call Recording

    This document uses the following terms to discuss call monitoring and call recording:

    • Agent - The call party that is monitored or recorded.
    • Call recording - A Cisco Unified Communications Manager feature that allows a recording device to record a conversation between or among other parties.
    • Customer - Any call participant other than the agent or the supervisor.
    • Local stream - The media stream from agent to customer.
    • Recorder - The media capture server.
    • Recording application - Any application that invokes a call recording or captures the media.
    • Remote stream - The media stream from customer to agent.
    • Supervisor - The person silently observing (monitoring) the call.
    • Supervisor desktop application - A silent monitoring-enabled application that is used to invoke a monitoring session.
    • Silent monitoring - A mode of call monitoring. The Cisco Unified Communications Manager silent monitoring feature allows a monitoring party (a supervisor) to listen to a conversation between a near-end party (an agent) and a far-end party (a customer); neither the near-end party nor the far-end party hears the monitoring party voice.

    Call Recording overview

    Call recording is a Cisco Unified Communications Manager feature that enables a recording server to archive agent conversations. The following types of call recording exist:

    • Automatic Recording—All agent calls are recorded automatically.
    • Selective Recording—Only selected agent calls are recorded.

    The following figure illustrates call recording.

    Figure 1. Call Recording Overview

    Monitoring and Recording architecture

    Call monitoring and call recording represent essential features in call centers. Environments other than the traditional call center sometimes use call monitoring and call recording to meet regulatory or quality requirements that an enterprise faces.

    Various architectures can accomplish call monitoring and call recording. Cisco Unified Communications Manager uses an IP phone-based architecture to provide call monitoring and call recording. The IP phone-based architecture exhibits the following methods:

    • IP phone-based call monitoring - The agent phone mixes the agent voice with the customer voice and sends the mix of both voices to the supervisor phone.
    • IP phone-based call recording - The agent phone forks two streams to the recorder: one recording stream comprises the agent voice and the other recording stream comprises the customer voice.

    See the SIP header enhancements for Call Recording for a discussion of the SIP header enhancements that were made in Release 8.5(1).

    The following figure illustrates the IP phone-based architecture for monitoring and recording. In the figure, the blue lines indicate the agent voice stream, the red lines indicate the customer voice stream, and the green line indicates the mix of customer and agent voice streams that gets sent to the supervisor.

    Figure 2. IP Phone-Based Architecture for Monitoring and Recording

    The following figure illustrates the streaming through the agent IP phone. In the figure, the blue lines indicate the agent voice stream, the red lines indicate the customer voice stream, and the green line indicates the mix of customer and agent voice streams that gets sent to the supervisor.

    Figure 3. Streaming Through the Agent IP Phone With IP Phone-Based Monitoring and Recording

    The call monitoring and call recording features impose requirements upon the following areas:

    • CTI/JTAPI/TSP
    • Call processing
    • Cisco Unified Communications Manager Administration
    • Cisco Unified Communications Manager database
    • IP Phone Firmware

    Determine device support for Call Monitoring and Call Recording

    Recorders
    Recorders must interface with Cisco Unified Communications Manager SIP trunk to receive recording calls. Consult with the recording vendor to determine which third-party recording applications and versions support the call recording feature.

    Introduction to Call Monitoring

    With silent call monitoring, the supervisor can listen in on an agent call for quality control and performance evaluation. By default, the agent is not aware of the monitoring session. In IP phone-based silent call monitoring, the monitoring stream comprises a mix of the customer voice and the agent voice. Only an application can trigger a monitoring session. The following figure shows the flow during a typical monitoring session.

    Figure 4. Silent Call Monitoring Session Flow

    Applications can invoke monitoring through the JTAPI or TAPI interfaces of Cisco Unified Communications Manager. Monitoring exhibits these characteristics:

    • Because monitoring is call based, the monitoring target specifies a specific call on a line appearance of an agent.
    • A start monitoring request from the application triggers the supervisor phone to go off hook automatically and make a monitoring call to the agent.
    • The agent phone automatically accepts the monitoring call. The monitoring call does not get presented to the agent.

    The following requirements apply:

    • The application user needs to be a member of the Standard CTI Allow Call Monitoring user group.
    • The agent device needs to be in the application user CTI control list.

    Invocation of a silent monitoring session

    A supervisor can initiate a silent monitoring session by using a desktop application after the agent answers a call.

    The following figure illustrates a silent monitoring session.

    Figure 5. Silent Monitoring Session

    When the supervisor initiates a monitoring session, the following steps take place:

    1. The customer calls into the call center. The call gets routed to the agent.
    2. The agent answers the call. A two-way media stream gets set up between the agent IP phone and the customer.
    3. The supervisor selects the agent from his desktop application, and then clicks Monitoring.
    4. The supervisor phone automatically goes off hook.
    5. The supervisor phone makes a monitoring call to the agent.
    6. The built-in bridge (BIB) of the agent phone automatically accepts the monitoring call. The agent phone starts to mix media of the agent voice and the customer voice and sends the mix to the supervisor phone.

    However, the supervisor can transfer the monitoring call anywhere after the monitoring call is initiated.

    The supervisor can terminate the monitoring call anytime after the call starts, either through the application or simply by hanging up.

    The supervisor can put the monitoring call on hold (no MOH gets inserted) and resume the monitoring call from the same or a different device.

    Supervisor transfers the monitoring call

    The following figure illustrates the supervisor transfer of a monitoring call.

    Figure 6. Supervisor Transfers the Monitoring Call

    During a monitoring call, the supervisor transfers the monitoring call, and the following steps take place:

    1. Supervisor 1 presses the Transfer softkey and dials the phone number of supervisor 2.
    2. Supervisor 2 answers the call.
    3. Supervisor 1 completes the transfer by pressing the Transfer softkey again.
    4. The monitoring call transfers to supervisor 2. Supervisor 2 starts to receive the mix of the agent voice and the customer voice.

    Agent cannot control a monitoring call

    The agent does not have direct control over the monitoring call; however, the agent action on the primary call causes a corresponding action for the monitoring call.

    When an agent puts the customer on hold, Cisco Unified Communications Manager also puts the monitoring call on hold, but no MOH gets inserted. When the agent hangs up the call with the customer, the monitoring call terminates.

    The following figure illustrates the scenario where the agent puts the customer on hold while the supervisor is monitoring the agent.

    Figure 7. Agent Does Not Control the Monitoring Call

    While an agent is being monitored, the agent puts the customer on hold, and the following steps take place:

    1. The agent puts the customer on hold. MOH gets inserted and played to the customer.
    2. Cisco Unified Communications Manager automatically puts the supervisor on hold. No MOH gets inserted to the supervisor.

    Multiple monitoring sessions

    The following figure illustrates the call flows during multiple monitoring sessions.

    Figure 8. Multiple Monitoring Sessions

    During multiple monitoring sessions, the following steps take place:

    1. Customer 2 calls the agent while the agent is in a call with customer 1 and supervisor is monitoring the agent call with customer 1.
    2. The agent puts customer 1 on hold; MOH gets inserted to customer 1.
    3. Cisco Unified Communications Manager puts the supervisor on hold. No MOH gets inserted to the supervisor.
    4. The agent answers customer 2 call.
    5. The supervisor initiates a second monitoring request for the agent call with customer 2.
    6. The supervisor phone automatically puts the first monitoring call on hold.
    7. The supervisor phone goes off hook and makes the second monitoring call to the agent.
    8. The agent IP phone (BIB of the agent IP phone) automatically accepts the monitoring call. The mix of agent voice and customer 2 voice gets sent to the supervisor phone.

    Barging or monitoring an agent call

    If the agent call is being monitored, the barge-in call from a shared line fails.

    If the agent call is barged in, the monitoring request gets rejected with a No resource error.

    Monitoring an agent in a conference

    An agent in a call center sometime needs to bring in another party into the conversation with the customer.

    The following figure illustrates a case where agent1 starts an ad hoc conference to include agent2 in the conversation with the customer. The supervisor for agent1 monitors the original call with the customer.

    During the setting-up process, the media of the monitoring call disconnect briefly. After the conference completes, the supervisor can hear all the parties that are included in the conference.

    Figure 9. Monitoring an Agent in a Conference

    Agent conferences in the supervisor

    The agent may create a conference with the supervisor while that supervisor is monitoring that agent.

    The supervisor must put the monitoring call on hold before joining the conference.

    This figure shows the final connection when the supervisor puts the monitoring call on hold and joins the conference. The monitoring session remains in the hold state while the supervisor participants in the conference. After the supervisor leaves the conference, he can then resume the monitoring session.

    Figure 10. Agent Conferences in the Supervisor

    Supervisor conferences in another supervisor

    A supervisor can conference another supervisor for the monitoring session.

    Supervisors can hear and talk to each other, and both can hear the conversation of the agent with the customer.

    The following figure illustrates this scenario.

    Figure 11. Supervisor Conferences in Another Supervisor

    In the example shown, supervisor 1, who started a monitoring call to the agent, conferences in supervisor 2 to the monitoring call. The customer and agent can still hear each other and are not aware of any of the monitoring supervisors. Both supervisor 1 and the supervisor 2 can hear the conversation of the agent with the customer. The two supervisors can hear each other.

    Whisper coaching

    Whisper coaching is an enhancement to silent call monitoring feature that allows supervisors to talk to agents during a monitoring session. This feature provides applications the ability to change the current monitoring mode of a monitoring call from Silent Monitoring to Whisper Coaching and vice versa. As for silent monitoring, a CTI/JTAPI/TSP application is required to use the Whisper Coaching feature.

    To enable Whisper Coaching in the Cisco Unified Communications Manager Administration application, choose Device > Phone, locate the Cisco Unified IP Phone that you want to configure. Scroll to the Device Information Layout pane and set Built-in Bridge to On or Default. If Built-in Bridge is set to Default, in the Cisco Unified Communications Manager Administration application, choose System > Service Parameter and select the appropriate Server and Service. Scroll to the Clusterwide Parameters (Device - Phone) pane and set Built-in Bridge Enable to On.

    Introduction to Call Recording

    In IP phone-based call recording, recording streams are forked from an agent IP phone to the recorder: The agent voice and the customer voice are sent separately.

    The administrator configures the recorder in Cisco Unified Communications Manager as a SIP trunk device.

    This section provides the following information:

    • General topics that apply to call recording.
    • Detailed call flows and detailed explanations of the following use cases when an agent device is configured for automatic call recording.
    • Detailed call flows and explanations of use cases when an agent device is configured for selective call recording.
    • Additional call-recording use cases.

    Call Recording session flow

    The following figure illustrates IP phone-based call recording session flow.

    Figure 12. IP Phone-Based Call Recording

    Call Recording modes

    The following modes of call recording exist:

    • Automatic call recording—In automatic call recording, the recording session automatically establishes when the agent call connects.
    • Selective call recording—In selective call recording, recording can be initiated using a softkey or programmable line key assigned to the device, a CTI-enabled application, or both interchangeably.

    Note

    In all call recording modes, the agent call must be active before call recording takes place.

    The administrator configures the recording option and recording profile on the agent line appearance. By default, the recording option specifies Call Recording Disabled.

    When the recording option is set to either Automatic Call Recording Enabled or Selective Call Recording Enabled, the line appearance can be associated with a recording profile. The recording profile specifies the following parameters: Recording Calling Search Space and Recording Destination Address.

    When automatic call recording is enabled, start and stop recording requests using a softkey, programmable line key, or CTI-enabled application are rejected.

    SIP header enhancements for Call Recording

    Release 8.5(1) of Cisco Unified Communications Manager introduces enhancements to the SIP headers that are used in the SIP messages that are sent to the recorder when call recording calls are made. These enhancements entail the following changes:

    • Cisco Unified Communications Manager sends both the agent (near-end) and customer (far-end) call information to the recorder via SIP messages. Messages travel through the SIP trunk. (Prior to this enhancement, only the near-end information was sent via SIP messages; retrieval of the far-end information required a CTI connection to Cisco Unified Communications Manager.)
    • The enhancement increases scalability: the recorder no longer requires a CTI connection to Cisco Unified Communications Manager to obtain far-end call information from Cisco Unified Communications Manager.
    • The enhancement supports automatic recording through use of the Open Recording Architecture (ORA) Cisco MediaSense recorder. Thus, a complete call-recording solution that uses only Cisco products is now available. The Cisco MediaSense recorder provides a basic and powerful recording capability and does not rely on CTI to obtain the far-end information.

    The From header contains the near-end call info. The near-end call information contains refci or the call ID of the near-end party, near-end device name, near-end directory number or address.

    With the SIP header enhancement, the far-end call information gets added to the INVITE message From header. The far-end call information contains farendRefCI or the call ID of the far-end party, far-end device name, and far-end directory number.

    Previously, Cisco Unified Communications Manager only sent a SIP INVITE message to a recorder. Now, when the far-end call info changes due to feature interaction, Cisco Unified Communications Manager sends a SIP UPDATE message to the recorder.

    The From header also includes an isfocus indicator, which indicates that an agent is in a conference call.

    Examples of the previous INVITE message and the new INVITE and UPDATE messages follow.

    Previous From Header in SIP INVITE Message
    From: <sip:3005@10.89.81.56;x-nearend;x-refci=25471846;x-nearenddevice=SEP001B535CDC62 >;
    New From Header in SIP INVITE and UPDATE Messages
    From: <sip:3005@10.89.81.56;x-nearend;x-refci=25471846;x-nearenddevice=SEP001B535CDC62 ;x-farendrefci=25471847;x-farenddevice=CFB_2;x-farendaddr=b097865452;isfocus>;

    In the new From header, the text in bold indicates the new information that the SIP header enhancement includes.

    Recorder as SIP trunk device

    The SIP trunk points directly to the recorder. Many recorders (such as those from Witness and Nice) consist of proxy, logger or storage and database.

    The recorder accepts recording calls from Cisco Unified Communications Manager in SIP.

    A directory number gets assigned to the recorder; a route pattern gets configured for the SIP trunk.

    Automatic Call Recording

    In automatic call recording, after an agent call becomes active, two server calls get made to the built-in bridge (BIB) of the agent phone. The agent phone automatically answers. Two server calls then get redirected to the recorder.

    The following figure illustrates automatic call recording.

    Figure 13. Automatic Call Recording

    In this example of an automatic call recording session, the following entities participate:

    • The customer call originates from DN 1000 device A.
    • The agent receives the call at DN 2000 device B.

    During an automatic call recording session, the following steps take place:

    1. A customer, party A (the far-end party) with DN 1000, calls into the call center.
    2. The call routes to the agent, who is party B with DN 2000. The agent answers the call. The agent IP phone starts to exchange media streams with the customer.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the agent IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the agent IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.

    In previous releases, the INVITE message contained only near-end information, but customer information was unknown. A CTI connection to Cisco Unified Communications Manager was required to obtain the customer information.

    Be aware that the two INVITE messages for the two separate voice streams contain the same near-end and far-end call information. The only difference in the two From headers is the first x- parameter, which indicates whether the call is for the near-end voice stream or for the far-end voice stream. x-nearend indicates the near-end voice stream. x-farend indicates the far-end voice stream.

    The INVITE message that is explained here (another INVITE message gets sent) contains the agent recording call.

    Note the header information of the INVITE messages from step 5 and step 6. The SIP header enhancement feature adds the information in bold text to the INVITE message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
 x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-farend;x-refci=ci2;x-nearenddevice=deviceB; 
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag2

    In both message headers,

    x-farendrefci specifies the far-end (customer) call leg caller ID.

    x-farenddevice specifies the far-end device name.

    x-farendaddr specifies the far-end DN.

    Local cluster far-end party hold/resume

    In this use case for automatic call recording, the far-end party that belongs to the local cluster places the call on hold and resumes the call from a different device. The following figure illustrates this use case.

    Figure 14. Far-End Party in Local Cluster Holds and Resumes Call From Different Device

    In this use case, the following entities participate:

    • The customer call originates from DN 1000 device A.
    • The agent receives the call at DN 2000 device B.
    • After placing the call on hold, the customer resumes the call from DN 1000 device A’.

    During an automatic call recording session that involves a customer (far-end party) in the local cluster that places the call on hold then resumes the call from a different device, the following steps take place:

    1. Party A (far-end party = customer in local cluster) calls party B (near-end party = agent).
    2. Party B answers the call.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the agent IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the agent IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    7. Party A (far-end party = customer in local cluster) places the call on hold.
    8. Party A (far-end party = customer in local cluster) resumes the held call from device A’ (a different device with same DN). Upon call resumption, party B is now connected to the new far-end party A’. The far-end call information has changed.
    9. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    10. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • Insertion of MOH when the far-end party places the call on hold does not cause a change in the far-end party.
    • When another device that shares the line resumes the call, a SIP UPDATE message gets sent to the recorder with the new far-end party device name.

    The UPDATE message that is explained here contains the agent (near-end) recording call. The other UPDATE for the customer (far-end) recording call contains the same information for the x-farend.

    Note the header information of the INVITE message from step 5 and the UPDATE message from step 9. The SIP header enhancement feature adds the information in bold text to the message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB; 
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 9 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB; 
x-farendrefci=ci1;x-farenddevice=deviceA’;x-farendaddr=1000>;tag=fromtag1
    Far-end party transfers call to another far-end party in local cluster

    In this use case for automatic call recording, the far-end party in the local cluster transfers the call to another far-end party in the same local cluster. The following figure illustrates this use case.

    Figure 15. Far-End Party in Local Cluster Transfers Call to Another Far-End Party in Local Cluster

    In this use case, the following entities participate:

    • The customer call originates from DN 1000 device A in the local cluster.
    • The agent receives the call at DN 2000 device B.
    • The customer transfers the call to DN 1100 device C in the same local cluster.

    During an automatic call recording session that involves a customer (far-end party) in the local cluster that places the call to the agent and then later transfers the call to another far-end party in the local cluster, the following steps take place:

    1. Party A (far-end party = customer in local cluster) calls party B (near-end party = agent).
    2. Party B answers the call.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the agent IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the agent IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    7. Party A (far-end party = customer in local cluster) initiates a consultation transfer of the call to another party, party C at DN 1100, in the local cluster.
    8. Party C answers the transferred call.
    9. Party A completes the transfer.
    10. Because party B is now connected to a new far-end party, party C, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    11. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    12. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • After first press of the Transfer key, because no change in the far-end party information occurs, Cisco Unified Communications Manager does not update the recorder.
    • After the second press of the Transfer key, Cisco Unified Communications Manager sends the SIP UPDATE message to the recorder with updated far-end party information.

    Note the following particularities of call processing that apply in this use case:

    1. Insertion of MOH when the far-end party places the call on hold does not cause a change in the far-end party.
    2. When another device that shares the line resumes the call, a SIP UPDATE message gets sent to the recorder with the new far-end party device name.

    Note the header information of the INVITE message from step 5 and the UPDATE message from step 10. The SIP header enhancement feature adds the information in bold text to the message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 10 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci4;x-farenddevice=deviceC;x-farendaddr=1100>;tag=fromtag1

    When you compare the INVITE message header in step 5 with the UPDATE message header in step 10, notice that the far-end values (farendrefci, farenddevice, and farendaddr) all change because of the transfer.

    Near-end party transfers call to another near-end party in local cluster

    In this use case for automatic call recording, the near-end party transfers a call to another near-end party in the local cluster. The following figure illustrates this use case.

    Figure 16. Near-End Party Transfers Call to Another Near-End Party in Local Cluster

    In this use case, the following entities participate:

    • The customer call originates from DN 1000 device A.
    • The agent receives the call at DN 2000 device B.
    • The agent transfers the call to DN 2001 device D.

    During an automatic call recording session where the agent on the call transfers the call to another party in the same local cluster, the following steps take place:

    1. Party A (far-end party = customer in local cluster) calls party B (near-end party = agent).
    2. Party B (near-end party = agent in local cluster) answers the call.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the agent IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the agent IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    7. Party B initiates the consultation transfer. This action implicitly places the call on hold.
    8. Cisco Unified Communications Manager terminates recording of the agent voice by sending a BYE message to the recorder through a SIP trunk.
    9. Cisco Unified Communications Manager terminates recording of the customer voice by sending a BYE message to the recorder through a SIP trunk.
    10. Party B calls party D (another far-end party = agent in local cluster).
    11. Party D answers the call from party B.
    12. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager makes a recording call to the built-in bridge (BIB) of the party B IP phone for the agent voice.
    13. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B IP phone for the customer voice.
    14. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    15. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the party A (customer) voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    16. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager makes a recording call to the built-in bridge (BIB) of the party D IP phone for the agent voice.
    17. Cisco Unified Communications Manager makes the second recording call to the BIB of the party D IP phone for the customer voice.
    18. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the party D (agent) voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    19. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the party A (customer) voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    20. Party B completes the transfer.
    21. Cisco Unified Communications Manager terminates recording of the party B (agent) voice (the consultation call) by sending a BYE message to the recorder through a SIP trunk.
    22. Cisco Unified Communications Manager terminates recording of the party A (customer) voice by sending a BYE message to the recorder through a SIP trunk.
    23. Because party D is now connected to a new far-end party, party A, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    24. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party D (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    25. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party A (customer) voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • When the near-end party B presses Transfer, the call is implicitly put on hold, and the recording session with party A terminates.
    • When party B dials party D and party D answers, a new recording session starts for party D.
    • When party B completes the transfer, party D and party A get connected and the recorder receives an update with information about the new far-end party A.

    Generally, each time an agent puts a recording call on hold, the current recording session terminates. Each time the agent invokes a supplementary service, such as Transfer or hold, the call is implicitly put on hold. Each time the far-end information changes, Cisco Unified Communications Manager sends a SIP UPDATE message to the recorder.

    Note the header information of the INVITE messages from step 5, step 14, step 18, and the UPDATE message from step 23. The SIP header enhancement feature adds the information in bold text to the message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 14 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci3;x-nearenddevice=deviceB;
x-farendrefci=ci4;x-farenddevice=deviceD;x-farendaddr=2001>;tag=fromtag2
    Step 18 INVITE Message Header Information
    From: <sip:2001@ucm1;x-nearend;x-refci=ci4;x-nearenddevice=deviceD;
x-farendrefci=ci3;x-farenddevice=deviceB;x-farendaddr=2000>;tag=fromtag2
    Step 23 UPDATE Message Header Information
    From: <sip:2001@ucm1;x-nearend;x-refci=ci4;x-nearenddevice=deviceD;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag2
    Far-end party transfers call to CFNA-enabled party

    In this use case for automatic call recording, the far-end party blind-transfers the call to a party that has Call Forward No Answer (CFNA) enabled. The following figure illustrates this use case.

    Figure 17. Far-End Party Transfers Call to CFNA-Enabled Party

    In this use case, the following entities participate:

    • The customer call originates from DN 1000 device A.
    • The agent receives the call at DN 2000 device B.
    • The customer blind-transfers the call to DN 1100 device C.
    • Device C does not answer but has CFNA enabled to forward to DN 1200 device D.

    During an automatic call recording session where the far-end party (customer) on the call transfers the call to another far-end party in the same local cluster but the far-end party has CFNA enabled, so the call forwards to a third far-end party in the local cluster, the following steps take place:

    1. Party A (far-end party = customer in local cluster) calls party B (near-end party = agent).
    2. Party B (near-end party = agent in local cluster) answers the call.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the agent voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    7. Party A presses Transfer, dials DN 1100 device C, and presses Transfer again (performs a blind transfer).
    8. Cisco Unified Communications Manager rings DN 1100 on device C, but this DN and device have CFNA configured: ringing times out, and Cisco Unified Communications Manager forwards the call to DN 1200 device D.
    9. Far-end party D with DN 1200 on device D answers the call.
    10. Because party B is now connected to a new far-end party, party D, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    11. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    12. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party D (customer) voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • For local-cluster transfers, Cisco Unified Communications Manager updates the recorder only when a new far-end party answers.
    • A SIP UPDATE message that contains updated far-end information gets sent to the recorder when party D answers.

    Note the header information of the INVITE messages from step 5 and step 10. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 10 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci5;x-farenddevice=deviceD;x-farendaddr=1200>;tag=fromtag1
    Far-end party in local cluster creates conference

    In this use case for automatic call recording, the far-end party in a local cluster creates a conference. The following figure illustrates this use case.

    Figure 18. Far-End Party in Local Cluster Creates Conference

    In this use case, the following entities participate:

    • The far-end customer call originates from DN 1000 device A.
    • The near-end agent receives the call at DN 2000 device B.
    • Party A creates a conference by conferencing in DN 1100 device C.

    During an automatic call recording session where the far-end (customer) party in the local cluster creates a conference by bringing an additional far-end party into the call, the following steps take place:

    1. Party A (far-end party = customer in local cluster) calls party B (near-end party = agent).
    2. Party B (near-end party = agent in local cluster) answers the call.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party A (customer) voice stream to the recorder.
    7. Party A initiates a conference by pressing Confn and dialing DN 1100.
    8. Party C DN 1100 device C answers the call.
    9. Party A completes the conference by pressing Confn again.
    10. Because party B is now connected to a new far-end party, CFB_2, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    11. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    12. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for CFB_2 (conference bridge) through a SIP trunk. The agent IP phone forks the conference voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • After the conference gets established, the far-end party is changed to the conference bridge (CFB).
    • Cisco Unified Communications Manager sends a SIP UPDATE message to the recorder.

    Note the header information of the INVITE messages from step 5 and step 10. The SIP header enhancement feature adds the information in bold text to the INVITE message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 10 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci7;x-farenddevice=CFB_2;x-farendaddr=b001234567;isfocus>;tag=fromtag1

    The UPDATE message in step 10 includes isfocus. This isfocus indicates that the near-end party is participating in a conference call. The UPDATE message also includes a b-number as the new far-end address. The b-number specifies the DN of the conference bridge (CFB).

    Near-end party in local cluster creates conference

    In this use case for automatic call recording, the near-end party in a local cluster creates a conference. The following figure illustrates this use case.

    Figure 19. Near-End Party in Local Cluster Creates Conference

    In this use case, the following entities participate:

    • The far-end customer call originates from DN 1000 device A.
    • The near-end agent receives the call at DN 2000 device B.
    • Party B creates a conference by conferencing in DN 1100 device C.

    During an automatic call recording session where the near-end (agent) party in the local cluster creates a conference by bringing an additional far-end party into the call, the following steps take place:

    1. Party A (far-end party = customer in local cluster) calls party B (near-end party = agent).
    2. Party B (near-end party = agent in local cluster) answers the call.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    5. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party A (customer) voice stream to the recorder.
    7. Party B, the near-end party, initiates a conference by pressing Confn. When the near-end party makes a consultation call for a conference participant, the near-end party call automatically gets put on hold.
    8. Cisco Unified Communications Manager terminates recording of the party B (agent) voice (the consultation call) by sending a BYE message to the recorder through a SIP trunk.
    9. Cisco Unified Communications Manager terminates recording of the party A (customer) voice by sending a BYE message to the recorder through a SIP trunk.
    10. Near-end party B dials DN 1100 party C.
    11. Party C answers the call.
    12. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager makes a recording call to the built-in bridge (BIB) of the party B IP phone for the near-end (agent) voice.
    13. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B IP phone for the far-end (customer) voice.
    14. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone starts to fork the near-end (agent) voice stream to the recorder.
    15. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the far-end (customer) voice through a SIP trunk. The agent IP phone starts to fork the customer voice stream to the recorder.
    16. Party B completes the consultation conference by pressing Confn. All parties connect to the conference bridge (CFB_2).
    17. Because party B is now connected to a new far-end party, CFB_2, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    18. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    19. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for CFB_2 (conference bridge) through a SIP trunk. The agent IP phone forks the conference voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • Near-end party creates a conference; the first recording session gets torn down
    • Connection of the consultation call re-establishes the recording session.
    • Far-end party changes to CFB and Cisco Unified Communications Manager sends SIP UPDATE message to the recorder.

    Note the header information of the INVITE messages from step 5 and step 14, and the UPDATE message from step 17. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 14 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci3;x-nearenddevice=deviceB;
x-farendrefci=ci4;x-farenddevice=deviceC;x-farendaddr=1100>;tag=fromtag1
    Step 17 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci7;x-farenddevice=CFB_2;x-farendaddr=B001234567;isfocus>;tag=fromtag1

    The UPDATE message in step 17 includes isfocus. This isfocus indicates that the near-end party is participating in a conference call. The UPDATE message also includes a b-number as the new far-end address. The b-number specifies the DN of the conference bridge (CFB).

    Far-end party in remote cluster transfers call to another party

    In this use case for automatic call recording, the far-end party in a remote cluster transfers the call to another party in the remote cluster. The following figure illustrates this use case.

    Figure 20. Far-End Party in Remote Cluster Transfers Call to Another Party in the Remote Cluster

    In this use case, the following entities participate:

    • The customer call originates from DN 3000 device D in cluster Cisco Unified CM2.
    • The agent receives the call at DN 2000 device B in cluster Cisco Unified CM1.
    • Agent D transfers the call to DN 3100 device E in cluster Cisco Unified CM2.

    During an automatic call recording session where the far-end (agent) party in the remote cluster transfers the call to another party in the remote cluster, the following steps take place:

    1. Party D (far-end party = customer in remote cluster) calls party B (near-end party = agent) in local cluster by dialing 82000.
    2. The remote cluster (Cisco Unified CM2) sends an INVITE message to the local cluster (Cisco Unified CM1) through a SIP trunk. The message contains information about party D.
    3. Party B (near-end party = agent in local cluster) answers the call.
    4. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    5. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    7. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party D (customer) voice stream to the recorder.
    8. Party D in the remote cluster initiates a transfer (presses Transfer) and dials DN 3100 device E, which is also in the remote cluster.
    9. Party E answers the call.
    10. Party D completes the transfer by pressing Transfer.
    11. The remote cluster (Cisco Unified CM2) sends an INVITE message to the local cluster (Cisco Unified CM1) through a SIP trunk. The message contains information about party E.
    12. Because party B is now connected to a new far-end party, party E, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    13. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    14. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party E (customer) voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • Far-end party and transfer-to party are both in the remote (Cisco Unified CM2) cluster. The near-end party sees the far-end party via the SIP trunk that links the two clusters.
    • When the transfer-to party answers, the recorder receives an UPDATE message that contains the far-end address.

    Note the header information of the INVITE message from step 6 and the UPDATE message from step 12. The SIP header enhancement feature adds the information in bold text to the message headers.

    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkTocluster2;x-farendaddr=3000>;tag=fromtag1
    Step 12 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkTocluster2;x-farendaddr=3100>;tag=fromtag1
    Far-end party in remote cluster blind-transfers call

    In this use case for automatic call recording, the far-end party in the remote cluster blind-transfers the call to a remote party that does not answer and has Call Forward No Answer (CFNA) configured. The following figure illustrates this use case.

    Figure 21. Far-End Party in Remote Cluster Blind-Transfers Call to Remote-Cluster Party That Has CFNA Configured

    In this use case, the following entities participate:

    • The customer call originates from DN 3000 device D in cluster Cisco Unified CM2.
    • The agent receives the call at DN 2000 device B in cluster Cisco Unified CM1.
    • Agent D blind-transfers the call to DN 3100 device E in cluster Cisco Unified CM2.
    • Agent E does not answer and the call forwards to DN 3200 device F in cluster Cisco Unified CM2.

    During an automatic call recording session where the far-end (agent) party in the remote cluster blind-transfers the call to another party in the remote cluster, but the second party does not answer and the call forwards to a third party in the remote cluster, the following steps take place:

    1. Party D (far-end party = customer in remote cluster) calls party B (near-end party = agent) in local cluster by dialing 82000.
    2. The remote cluster (Cisco Unified CM2) sends an INVITE message to the local cluster (Cisco Unified CM1) through a SIP trunk. The message contains information about party D.
    3. Party B (near-end party = agent in local cluster) answers the call.
    4. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    5. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    7. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party D (customer) voice stream to the recorder.
    8. Party D in the remote cluster initiates a transfer (presses Transfer) and dials DN 3100 device E, which is also in the remote cluster.
    9. Party E does not answer the call: ringing times out, so Cisco Unified Communications Manager sends the call to party F DN 3200 device F.
    10. The remote cluster (Cisco Unified CM2) sends an UPDATE message to the local cluster (Cisco Unified CM1) through a SIP trunk. The message contains information about party E.
    11. Because party B is now connecting to a new far-end party, party E, local Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    12. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    13. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party E (customer) voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.
    14. Party F answers the forwarded call.
    15. The remote cluster (Cisco Unified CM2) sends an UPDATE message to the local cluster (Cisco Unified CM1) through a SIP trunk. The message contains information about party F.
    16. Because party B is now connected to a new far-end party, party F, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    17. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    18. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party F (customer) voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • Far-end part D in remote cluster transfers call to party E in remote cluster; the remote Cisco Unified Communications Manager updates the recorder.
    • Party E CFNA timer expires and Cisco Unified Communications Manager redirects call to party F; the remote Cisco Unified Communications Manager again updates the recorder.
    • The call state of the local Cisco Unified Communications Manager remains call-active, so Cisco Unified Communications Manager updates the recorder for each forwarded remote device.

    Note the header information of the INVITE messages from step 6, step 11, and step 15. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkTocluster2;x-farendaddr=3000>;tag=fromtag1
    Step 11 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkTocluster2;x-farendaddr=3100>;tag=fromtag1
    Step 15 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkTocluster2;x-farendaddr=3200>;tag=fromtag1
    Far-end party in remote PBX transfers call to phone in local cluster

    In this use case for automatic call recording, the far-end party in a remote PBX transfers a call to a phone in the local cluster. The following figure illustrates this use case.

    Figure 22. Far-End Party in Remote PBX Transfers Call to Phone in Local Cluster

    In this use case, the following entities participate:

    • The customer call originates from DN 3000 device D in PBX1.
    • The agent receives the call at DN 2000 device B in cluster Cisco Unified CM1.
    • Agent D transfers the call to DN 1000 device A in cluster Cisco Unified CM1.

    During an automatic call recording session where the far-end (agent) party in a remote PBX transfers the call to another party in the local cluster, the following steps take place:

    1. Party D (far-end party = customer in remote PBX) calls party B (near-end party = agent) in local cluster by dialing 82000.
    2. The remote PBX sends an setup message to the local cluster (Cisco Unified CM1) through a PRI QSIG gateway. The message contains information about party D.
    3. Party B (near-end party = agent in local cluster) answers the call.
    4. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    5. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    7. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party D (customer) voice stream to the recorder.
    8. Party D in the remote PBX initiates a consultation transfer (presses Transfer) and dials DN 81000 device A, which is in the local cluster.
    9. The remote PBX sends an setup message to the local cluster (Cisco Unified CM1) through a PRI QSIG gateway. The message contains information about party D.
    10. Party A answers the call from party D.
    11. Party D presses Transfer to complete the transfer.
    12. Remote PBX sends UPDATE.
    13. Remote PBX sends UPDATE.
    14. Because party B is now connecting to a new far-end party, party A, local Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    15. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    16. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party A (customer) voice. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • When the far-end party in a remote cluster transfers the call to a party in the local cluster, Cisco Unified Communications Manager sends a SIP UPDATE message with farendaddr for the transferred-to local-cluster party.
    • This transfer specifies a hairpin transfer: the far-end address changed to the local DN 1000 in the UPDATE message.

    Note the header information of the INVITE messages from step 6 and step 14. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=PriQSIGGW;x-farendaddr=3000>;tag=fromtag1
    Step 14 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=PriQSIGGW;x-farendaddr=1000>;tag=fromtag1
    Remote PBX far-end party transfers call to local phone

    In this use case for automatic call recording, a remote PBX far-end party transfers the call to a local phone by using path replacement. The following figure illustrates this use case.

    Figure 23. Remote PBX Far-End Party Transfers Call to Local Phone With Path Replacement

    In this use case, the following entities participate:

    • The customer call originates from DN 3000 device D in PBX1.
    • The agent receives the call at DN 2000 device B in cluster Cisco Unified CM1.
    • Agent D transfers the call to DN 1000 device A in cluster Cisco Unified CM1.

    During an automatic call recording session where the far-end (agent) party in a remote PBX transfers the call to a phone in the local cluster by using path replacement, the following steps take place:

    1. Party D (far-end party = customer in remote PBX) calls party B (near-end party = agent) in local cluster by dialing 82000.
    2. The remote PBX sends an setup message to the local cluster (Cisco Unified CM1) through a PRI QSIG gateway. The message contains information about party D.
    3. Party B (near-end party = agent in local cluster) answers the call.
    4. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    5. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    7. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party D (customer) voice stream to the recorder.
    8. Party D in the remote PBX initiates a consultation transfer (presses Transfer) and dials DN 81000 device A, which is in the local cluster.
    9. The remote PBX sends an setup message to the local cluster (Cisco Unified CM1) through a PRI QSIG gateway. The message contains information about party D.
    10. Local party A answers the call from party D.
    11. Remote party D presses Transfer to complete the transfer.
    12. Remote PBX sends UPDATE.
    13. Remote PBX sends UPDATE.
    14. Because party B is now connecting to a new far-end party, party A, local Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    15. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    16. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party A (customer) voice. The agent IP phone forks the customer voice stream to the recorder.
    17. Local Cisco Unified Communications Manager initiates path replacement process directly connects device A with device  B and eliminates routing through the remote PBX.
    18. Because party B is now connecting to a new far-end party, party A, local Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    19. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    20. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party A (customer) voice. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • Path replacement replaces a hairpin call to remote PBX so that party A and party B are directly connected without routing through the remote PBX.
    • The far-end call information gets updated when transfer completes.
    • When path replacement completes, the far-end device also gets updated.

    Note the header information of the INVITE messages from step 6, step 14, and step 17. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=PriQSIGGW;x-farendaddr=3000>;tag=fromtag1
    Step 14 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=PriQSIGGW;x-farendaddr=1000>;tag=fromtag1
    Step 17 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci4;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Far-end party transfers call across DMS gateway

    In this use case for automatic call recording, the far-end party transfers a call across a DMS gateway. The following figure illustrates this use case.

    Figure 24. Far-End Party Transfers Call Across DMS Gateway

    In this use case, the following entities participate:

    • The customer call originates from DN 9725550001 device D that connects to a DMS switch.
    • The agent receives the call at DN 2000 device B in cluster Cisco Unified CM1.
    • Agent D transfers the call to DN 9725550002 device E that connects to a DMS switch.

    During an automatic call recording session where the far-end (agent) party that connects through a DMS switch transfers the call to a phone that also connects through a DMS switch, the following steps take place:

    1. Party D (far-end party = customer across DMS switch) calls party B (near-end party = agent) in local cluster by dialing 82000.
    2. The DMS switch sends a PriSetup message to the local cluster (Cisco Unified CM1) through a PRI DMS gateway. The message contains information about party D.
    3. Party B (near-end party = agent in local cluster) answers the call.
    4. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    5. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    6. The recorder receives and answers the recording call setup messages that are sent from local Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    7. The recorder receives and answers the recording call setup messages that are sent from local Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party D (customer) voice stream to the recorder.
    8. Party D across the DMS gateway initiates a consultation transfer (presses Transfer) and dials DN 9725550002 device E, which is also across the DMS gateway.
    9. Party E answers the call from party D.
    10. The DMS switch sends a PriNotify message to the local cluster (Cisco Unified CM1) through a PRI DMS gateway. The message contains information about party E.
    11. Because party B is now connecting to a new far-end party, party E, local Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    12. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    13. The recorder receives and answers the recording call UPDATE message that is sent from local Cisco Unified Communications Manager for the party E (customer) voice. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • In general, when a far-end party on the PSTN side transfers a call, Cisco Unified Communications Manager does not know about the transferring nor transferred-to parties. If the DMS switch or PBX supports PriNotify, however, Cisco Unified Communications Manager receives the PriNotify message when the far-end party changes and can update the far-end information to the recorder.

    Note the header information of the INVITE messages from step 6 and step 11. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=PriDMSGW;x-farendaddr=9725550001>;tag=fromtag1
    Step 11 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=PriDMSGW;x-farendaddr=9725550002>;tag=fromtag1
    Desktop pickup of mobile phone call

    In this use case for automatic call recording, mobile phone user sends call to desk phone for pickup. The following figure illustrates this use case.

    Figure 25. Desktop Pickup of Mobile Phone Call

    In this use case, the following entities participate:

    • The customer call originates from mobile device UserACell, enterprise extension 1000 and mobile number 9725551000.
    • The agent receives the call at DN 2000 device B.
    • The customer resumes the call from the customer enterprise phone DN 1000 device A.

    During an automatic call recording session where desktop pickup of a mobile phone call occurs, the following steps take place:

    1. UserACell calls party B DN 2000 device B.
    2. Cisco Unified Mobile Communicator client sends SETUP message
    3. SETUP message travels through H.323 gateway to local Cisco Unified CM1 cluster.
    4. Party B answers the incoming call from UserACell.
    5. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    6. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    7. The recorder receives and answers the recording INVITE messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    8. The recorder receives and answers the recording INVITE messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party UserACell (customer) voice stream to the recorder.
    9. UserACell presses Enterprise Hold on the user A mobile phone.
    10. User A presses Resume on the user A desk phone.
    11. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    12. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • Mobile phone uses the shared-line concept. When the mobile phone call gets put on hold and the desktop phone resumes the call, the far-end party changes. Cisco Unified Communications Manager sends an update to the recorder.
    • The user picks up the call from the user desk phone to continue the conversation that started on the user mobile phone. To do so, use Cisco Unified Communications Manager to place the call on hold (enterprise hold) through the mobile phone data channel; then, resume the call from the desk phone.

    Note the header information of the INVITE messages from step 7 and step 11. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 7 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=UserACell;x-farendaddr=1000>;tag=fromtag1
    Step 11 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Far-end party sends call to mobile phone

    In this use case for automatic call recording, the far-end party sends a call to the user mobile phone for mobile phone pickup. (This scenario specifies the opposite of the scenario that the Desktop pickup of mobile phone call specifies.) The following figure illustrates this use case.

    Figure 26. Far-End Party Sends Call to Mobile Phone for Mobile Phone Pickup

    In this use case, the following entities participate:

    • The customer call originates from DN 1000 device A.
    • The agent receives the call at DN 2000 device B.
    • The customer resumes the call from the customer mobile phone device UserACell enterprise extension 1000 mobile number 9725551000.

    During an automatic call recording session where an enterprise user sends a call to the user mobile phone, the following steps take place:

    1. Enterprise user far-end party A calls party B DN 2000 device B from DN 1000 device A.
    2. Party B DN 2000 answers the incoming call from far-end party A.
    3. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    4. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    5. The recorder receives and answers the recording INVITE messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    6. The recorder receives and answers the recording INVITE messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party A (customer) voice stream to the recorder.
    7. Party A presses Send to Mobile on the user A desk phone.
    8. Cisco Unified Communications Manager sends a Setup message to the User A mobile phone.
    9. User A presses answers the ringing call on device UserACell.
    10. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    11. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone forks the customer voice stream to the recorder.

    Note the following particularities of call processing that apply in this use case:

    • When party UserACell answers the call, the party USerACell information is sent in a SIP UPDATE message to the recorder.

    Note the header information of the INVITE messages from step 5 and step 10. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 5 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=deviceA;x-farendaddr=1000>;tag=fromtag1
    Step 10 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci3;x-farenddevice=UserACell;x-farendaddr=1000>;tag=fromtag1
    Far-end party in remote cluster creates conference

    In this use case for automatic call recording, the far-end party in a remote cluster creates a conference. The following figure illustrates this use case.

    Figure 27. Far-End Party in Remote Cluster Creates Conference

    In this use case, the following entities participate:

    • The far-end customer call originates from DN 3000 device D.
    • The near-end agent receives the call at DN 2000 device B.
    • Party D creates a conference by conferencing in DN 3100 device E.

    During an automatic call recording session where the far-end party in a remote cluster creates a conference, the following steps take place:

    1. Party D (far-end party = customer in remote cluster) calls party B (near-end party = agent) by dialing 82000.
    2. The INVITE message passes over the SIPTrunkToCluster2 SIP trunk.
    3. Party B (near-end party = agent in local cluster) answers the call.
    4. Because the agent line appearance is configured for automatic recording, the recording session for the media streams automatically gets triggered. Cisco Unified Communications Manager first makes a recording call to the built-in bridge (BIB) of the party B (agent) IP phone for the agent voice.
    5. Cisco Unified Communications Manager makes the second recording call to the BIB of the party B (agent) IP phone for the customer voice.
    6. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the agent voice through a SIP trunk. The agent IP phone starts to fork the party B (agent) voice stream to the recorder.
    7. The recorder receives and answers the recording call setup messages that are sent from Cisco Unified Communications Manager for the customer voice through a SIP trunk. The agent IP phone starts to fork the party D (customer) voice stream to the recorder.
    8. Party D initiates a conference by pressing Confn and dialing DN 3100.
    9. Party E DN 3100 device E answers the call.
    10. Party D completes the conference by pressing Confn again.
    11. The UPDATE message passes over the SIPTrunkToCluster2 SIP trunk.
    12. Because party B is now connected to a new far-end party, CFB_2, Cisco Unified Communications Manager sends two UPDATE messages to the recorder.
    13. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for the party B (agent) voice through a SIP trunk. The agent IP phone forks the agent voice stream to the recorder.
    14. The recorder receives and answers the recording call UPDATE message that is sent from Cisco Unified Communications Manager for CFB_2 (conference bridge) through a SIP trunk. The agent IP phone forks the conference voice stream to the recorder.

    Note the following particularities of call processing and configuration that apply in this use case:

    • Cisco Unified Communications Manager has very limited view if a far-end party creates a conference in a remote cluster. The far-end party device is always the trunk that links the two clusters.
    • After the remote conference gets established, the remote Cisco Unified CM2 cluster delivers the b-number (conference bridge identifier) in the SIP UPDATE to the local cluster, Cisco Unified CM1. The Cisco Unified CM1 cluster sends the update to the recorder with the b-number and isfocus indicator.
    • In the figure, the Cisco Unified CM1 cluster gets configured with a SIP trunk, SIPTrunkToCluster2, that links the Cisco Unified CM1 cluster to the Cisco Unified CM2 cluster. The corresponding SIP trunk that is configured in the Cisco Unified CM2 cluster specifies SIPTrunkToCluster1.
    • When the conference gets created by the far-end party with DN 3000, the conference bridge identifier, b001234567, does not get passed to cluster Cisco Unified CM1 by default. If the identifier is not passed, the Cisco Unified CM1 cluster can still include the isfocus flag for the far-end party in the From header to the recorder, but the far-end party address will be empty.
    • To allow the conference bridge identifier (the b-number of the conference bridge) to pass from cluster Cisco Unified CM2 to cluster Cisco Unified CM1, the administrator creates a SIP profile in cluster Cisco Unified CM2, checks the Deliver Conference Bridge Identifier check box, and assigns the SIP profile to SIPTrunkToCluster1 in cluster Cisco Unified CM2. The administrator also creates a SIP profile in cluster Cisco Unified CM1 and assigns this SIP profile to the SIPTrunkToCluster2 in cluster Cisco Unified CM1.
    • For more details about configuring SIP profiles, see the Cisco Unified Communications Manager Administration Guide.

    Note the header information of the INVITE messages from step 6 and step 12. The SIP header enhancement feature adds the information in bold text to the INVITE and UPDATE message headers.

    Step 6 INVITE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkToCluster2;x-farendaddr=3000>;tag=fromtag1
    Step 12 UPDATE Message Header Information
    From: <sip:2000@ucm1;x-nearend;x-refci=ci2;x-nearenddevice=deviceB;
x-farendrefci=ci1;x-farenddevice=SIPTrunkToCluster2;x-farendaddr=b001234567;isfocus>;tag=fromtag1

    The UPDATE message in step 12 includes isfocus. This isfocus indicates that the near-end party is participating in a conference call. The UPDATE message also includes a b-number as the new far-end address. The b-number specifies the DN of the conference bridge (CFB).

    Selective Call Recording

    In selective call recording, recording can be initiated using a softkey or programmable line key assigned to the device, a CTI-enabled application, or both interchangeably.

    Selective call recording supports two modes:

    Silent Recording

    In the silent recording mode the call recording status is not reflected on the Cisco IP device display. Silent recording is typically used in a call center environment to enable a supervisor to record an agent call. A CTI-enabled application running on the supervisor desktop is generally used to start and stop the recording for the agent-customer call.

    User Recording

    In the user recording mode the call recording status is reflected on the Cisco IP device display. A recording may be started or stopped using a softkey, programmable line key, or CTI-enabled application running on the user desktop.

    Selective Call Recording Silent Recording mode

    In this use case for selective call recording silent recording mode, the supervisor manages the recording session from a CTI-enabled desktop.

    The following figure illustrates selective call recording silent recording mode.

    Figure 28. Selective Call Recording Silent Recording Mode

    In this use case:

    • Device A (DN 1000) calls device B (DN 2000).
    • The user on device B answers the call.
    • The supervisor uses a CTI-enabled application to start and stop the call recording session.

    The supervisor starts the recording session using a CTI-enabled desktop. Cisco Unified Communications Manager makes two recording calls to the built-in bridge (BIB) of the Cisco IP device (one call for the near-end media; another call for the far-end media). The recording calls are automatically and silently answered.

    Cisco Unified Communications Manager extends both recording calls to the recording server connected by a SIP trunk.

    The recorder receives and answers both recording calls and the user Cisco IP device starts to fork both media streams to the recorder. The call recording status is not reflected on the Cisco IP device display.

    The CTI-enabled application is used to stop the recording session. Cisco Unified Communications Manager clears both recording calls.

    Selective Call Recording User Recording mode—recording session managed from a CTI-enabled application

    In this use case for selective call recording user recording mode, the user manages the recording session from a CTI-enabled desktop.

    The following figure illustrates selective call recording user recording mode—recording session managed from a CTI-enabled application.

    Figure 29. User Recording Mode Managed from a CTI-Enabled Application

    In this use case:

    • Device A (DN 1000) calls device B (DN 2000).
    • The user on device B answers the call.
    • The user on device B uses a CTI-enabled application to start and stop the call recording session.

    The user starts the recording session using a CTI-enabled desktop. Cisco Unified Communications Manager makes two recording calls to the built-in bridge (BIB) of the Cisco IP device (one call for the near-end media; another call for the far-end media). The recording calls are automatically and silently answered.

    Cisco Unified Communications Manager extends both recording calls to the recording server connected by a SIP trunk.

    The recorder receives and answers both recording calls and the user Cisco IP device starts to fork both media streams to the recorder. The Cisco IP device display updates to reflect Recording. The key toggles from Record to StopRec.

    The CTI-enabled application is used to stop the recording session. Cisco Unified Communications Manager clears both recording calls.

    Selective Call Recording User Recording mode—recording session managed from a Cisco IP device

    In this use case for selective call recording user recording mode, the user presses a softkey or programmable line key on a Cisco IP device to start and stop the call recording session.

    The following figure illustrates selective call recording user recording mode—recording session managed from a Cisco IP device.

    Figure 30. User Recording Mode Managed from a Cisco IP Device

    In this use case:

    • Device A (DN 1000) calls device B (DN 2000).
    • The user on device B answers the call.
    • The user on device B uses the softkey or programmable line key on the Cisco IP device to start and stop the call recording session.

    The user presses the Record key to start the recording session. Cisco Unified Communications Manager makes two recording calls to the built-in bridge (BIB) of the Cisco IP device (one call for the near-end media; another call for the far-end media). The recording calls are automatically and silently answered.

    Cisco Unified Communications Manager extends both recording calls to the recording server connected by a SIP Trunk.

    The recorder receives and answers both recording calls and the user Cisco IP device starts to fork both media streams to the recorder. The Cisco IP device display updates to reflect Recording. The key toggles from Record to StopRec.

    The User presses the StopRec key to stop the recording session.

    Cisco Unified Communications Manager clears both recording calls.

    Recording calls do not survive agent hold

    Recording calls get torn down when the agent puts the call on hold, and they get reestablished when the agent resumes the call.

    The Start Recording Request from an application persists throughout the call.

    The following figure illustrates the scenario in which recording calls do not survive agent hold.

    Figure 31. Recording Calls Do Not Survive Agent Hold

    Recording a barged call

    When recording a barged call, the following recording streams apply: the customer voice alone and the mixed voices of agent 1 and agent 2.

    The following figure illustrates the scenario when a barged call is recorded.

    Figure 32. Recording a Barged Call

    Recording an agent conference

    When a conference is recorded, the following recording streams apply: agent voice alone and the mixed voices from the rest of the conference participants.

    An agent may create a conference while being recorded. During the conference setup process, recording calls get torn down and then reestablished.

    The following figure illustrates the scenario in which an agent conference gets recorded.

    Figure 33. Agent‘s Conference Gets Recorded

    Simultaneous Monitoring and Recording

    Recording can take place when the agent call is being monitored.

    Recording and monitoring get set up independently from each other

    The following figure illustrates simultaneous monitoring and recording.

    Figure 34. Simultaneous Monitoring and Recording

    In the case of simultaneous monitoring and recording, the following steps take place:

    1. A customer calls into the call center.
    2. The call routes to agent. Agent answers the call. A two-way media streaming gets set up between agent IP phone and the customer.
    3. The recording call for the agent voice gets set up between agent phone and the recorder.
    4. The recording call for the customer voice gets set up between agent phone and the recorder.
    5. The supervisor desktop application shows that agent has an active call. On his desktop application, the supervisor clicks the monitor button for current active call of agent.
    6. The supervisor IP phone gets triggered to go off hook and make a monitoring call toward agent.
    7. Agent phone accepts the monitoring call. Agent phone starts to send a stream of mixed voices of the customer and the agent to the supervisor IP phone. Neither the agent nor the customer can hear the supervisor.

    Call characteristics of Monitoring and Recording calls

    This section describes various characteristics of monitoring and recording calls.

    Monitoring and Recording notification tones

    In certain jurisdictions, a requirement exists to inform the agent or the customer that their call is being monitoring or reordered in the form of tones.

    Use the following service parameters to set the default play tone options:

    • Play Recording Notification Tone To Observed Target
    • Play Recording Notification Tone To Observed Connected Parties
    • Play Monitoring Notification Tone To Observed Target
    • Play Monitoring Notification Tone To Observed Connected Parties

    The application also provides the tone option in the monitoring or recording request. The tone plays when either the server parameter or application enables tones.

    The following figure illustrates the observed connected party and the observed target.

    Figure 35. Observed Connected Party and Observed Party

    Play tone behavior

    Monitoring tone and recording tone represent two different tones; they can be enabled or disabled separately.

    By default, the supervisor does not hear monitoring or recording tones. Playing to the supervisor can be enabled optionally through the device recording tone setting.

    The following table specifies the behavior of tones in monitoring and recording scenarios.

    Table 1 Play Tone Behavior

    Play To

    Agent Hears

    Customer Hears

    Supervisor Monitoring Stream

    Agent Recording Stream

    Customer Recording Stream

    None

    None

    None

    None

    None

    None

    Agent

    Tone

    None

    None

    None

    None

    Customer

    None

    Tone

    None

    Tone

    None

    Both

    Tone

    Tone

    None

    Tone

    None

    Codec for Monitoring and Recording calls

    The agent device and the supervisor device negotiate the codec for a monitoring call, subject to Cisco Unified Communications Manager region settings.

    The codecs for recording calls match the codec of the customer-agent call.

    The following figure illustrates the codecs for monitoring and recording calls.

    Figure 36. Codecs for Monitoring and Recording Calls

    Limit codec usage for recording calls

    Because the codecs for recording calls match the codecs for agent-customer calls, you may need to insert transcoders if the recorder does not support the matching codecs.

    Cisco Unified IP Phones adds new codecs that Cisco transcoders do not support.

    Use the following service parameters to enable or disable usage of the G722, iLBC, and iSAC codecs:

    • G722 Codec Enabled
    • iLBC Codec Enabled
    • iSAC Codec Enabled

    Find these service parameters in the Clusterwide Parameters (System - Location and Region) section of the Service Parameter Configuration window.

    You can set these service parameters with the following values:

    • Enabled for All Devices
    • Enabled for All Devices Except Recording-Enabled Devices
    • Disabled

    Monitoring and Recording one-way media

    A monitoring call comprises one-way media from an agent phone to a supervisor phone.

    Recording calls comprise one-way media from an agent phone to the recorder.

    Monitoring calls and recording calls go through normal call admission control; however, each of the streams leaving the BIB destined for the recorder use the same calculations as the two-way media.

    NAT separating agent and supervisor or agent and recorder remain transparent to the monitoring or recording calls (within the limitations of Cisco Unified Communications Manager).

    One-way media and firewalls

    Firewall software needs to know the destination IP address and destination port as well as the source IP address to open the pinhole for an RTP stream.

    Be aware that SCCP messages for media are not symmetric, SIP is OK.

    The SCCP ver 12 enhancement for one-way media provides the following additions:

    • New StartMediaTransmissionAck (SMTACK) message with transmission IP and port
    • OpenReceiveChannel (ORC) with additional transmission IP and port

    The following figure illustrates the issue with one-way media and a firewall.

    Figure 37. One-Way Media and Firewall

    Call preservation in Monitoring and Recording

    If the agent call that is being monitored or recorded goes to call preservation, Cisco Unified Communications Manager puts the monitoring call or recording calls into call preservation mode.

    The agent call does not get affected if the monitoring call or recording call go to call preservation mode.

    Call information and Call Display

    Built-in Bridge (BIB) specifies a component in the device layer. BIB provides the logical representation of the DSP resource in the Cisco Unified IP Phone. Calls that are made to the BIB of the phone device layer remain hidden to the user.

    Monitoring and recording calls (the server calls) to the agent get made to the BIB of the agent.

    For a monitoring call, the supervisor phone displays "From Monitoring [agent user name/DN]."

    For a recording call to the recorder, the special tag in the "from header" of the SIP INVITE message indicates the source of the voice stream.

    For Agent Voice

    From "AgentUserName" <sip:agentDN@ccm;x-nearend;x-refCI=12345; x-nearenddevice=[agent_devicename]”

    For Customer Voice

    From "AgentUserName" <sip:agentDN@ccm;x-farend;x-refCI=12345;x-farenddevice=[farend_devicename]”

    CTI event delivery to application

    CTI Events get delivered to the agent on the primary call leg (or reference call leg), as shown in the following figure.

    Figure 38. CTI Event Delivery to Application

    System requirements for Monitoring and Recording

    The following sections provide the system requirements for monitoring and recording.

    CTI requirements

    Computer Telephony Integration (CTI) provides the ability for applications to monitor calls on a per-call basis. Cisco defines the monitor target as the party that is monitored and the monitor initiator as the monitoring party.

    If a single application observes both the monitor target and the monitor initiator, call events that get reported to the application help the application identify calls on the monitor target and provide the ability to monitor the calls. If different applications observe the monitor target and the monitor initiator, the application that observes the monitor target must provide the call information to the application that observes the monitor initiator. Based on the call information that is available to the application that observes the monitor initiator, a monitoring request can get initiated. Termination of the call at the monitor initiator or monitor target stops the monitoring session.

    For recording, Cisco Unified Communications Manager provides the ability to record all calls automatically. The SIP or SCCP station initiates this automatic recording and is based on configuration of Cisco Unified Communications Manager Administration. Administrators can configure no recording, automatic recording of all calls, or selective recording for a line appearance. In selective call recording, recording can be initiated using a softkey or programmable line key assigned to the device, a CTI-enabled application, or both interchangeably. CTI does not provide the ability to override the administrator configuration in the database.

    Selective recording supports two modes: silent recording and user recording.

    In the silent recording mode the call recording status is not reflected on the Cisco IP device display. Silent recording is typically used in a call center environment to enable a supervisor to record an agent call. A CTI-enabled application running on the supervisor desktop is generally used to start and stop the recording for the agent-customer call.

    In the user recording mode the call recording status is reflected on the Cisco IP device display. A recording may be started or stopped using a softkey, programmable line key, or CTI-enabled application running on the user desktop.

    When invoking recording and monitoring or any other CTI features, delays and unexpected behavior can result if UDP transport is used for phones that are running SIP.

    Applications that intend to monitor or record calls should have the corresponding monitoring and recording privileges enabled for the application user or end user that the application uses.

    For convenience the MonitoringPartyInfo, MonitoredPartyInfo, and RecordPartyInfo all get combined and reported as CallAttributeInfo from CTI to applications.

    Hardware requirements

    The monitoring and recording features support a limited set of phones and related devices. See the Determine device support for Call Monitoring and Call Recording for details.

    Interactions and limitations

    This section provides the interactions and limitations for the monitoring and recording feature.

    Interactions

    This section describes monitoring and recording interactions with other applications and Cisco Unified CM features.

    CTI and JTAPI/TSP applications

    Computer Telephony Integration (CTI), Java Telephony API (JTAPI), and TSP support monitoring and recording of calls. Applications can use these interfaces to monitor or record calls in a Cisco Unified Communications Manager system.

    The initial implementation of this feature presents some limitations. For monitoring, applications must open the line that is to be monitored and the party that will monitor. This requirement exists because the call ID of the call to be monitored should get provided when the monitoring party initiates a request to monitor that call. One way to circumvent this limitation involves using two coordinating applications, one application to open the line for the monitored party and another application to open the line of the monitoring party, and provide the call ID of the party to be monitored through an out-of-band mechanism. Applications such as IPCC Enterprise use the latter approach.

    No backward compatibility implications exist because monitoring and recording as new features do not affect any of the existing features.

    Cisco Unified CM features

    The following features work transparently with monitoring and recording:

    • Forced Authorization Codes (FAC) and Client Matter Codes (CMC)
    • QSIG
    • Multilevel Precedence and Preemption (MLPP)
    • External Call Control

    The following features and other Cisco Unified Communications Manager components interact with monitoring and recording:

    • Call Transfer
    • Immediate Divert (i-Divert)
    • Call Park
    • Barge
    • Music On Hold (MOH)
    • Conferencing
    • Bulk Administration Tool (BAT)

    Limitations

    The following restrictions and limitations exist for monitoring and recording:

    Codec Consideration During Monitoring or Recording

    The codec of the call leg that originates from the IP phone that is being monitored or recorded must remain the same throughout the call.

    Security Handling in Monitoring and Recording

    Cisco Unified Communications Manager allows a supervisor or administrator to monitor a conversation between an agent and a customer without either party knowing that they are being monitored. For information about using and configuring secure call monitoring and recording, see the "Secure Call Monitoring and Recording" chapter in the Cisco Unified Communications Manager Security Guide.

    Intercom

    The system does not allow monitoring nor recording of whisper intercom and talkback intercom calls. Configuration of the intercom calling search space (CSS) specifies this limitation.

    Recording and Call Hold and Resume

    Cisco Unified Communications Manager does not update the recorder when the far-end party puts the call on hold. The recorder will be updated only when a different far-end party resumes the call.

    Cisco Unified Communications Manager updates a recorder when the far-end call information changes. The far-end call information contains a call ID, directory number, and device name. If one of these parameters changes, the far-end call information changes.

    If a far-end party holds and resumes a call from the same device, Cisco Unified Communications Manager does not update a recorder.

    Recording and Call Park and Retrieve

    If the far-end party in a remote cluster parks the call, Cisco Unified Communications Manager updates the recorder with an empty far-end party address, provided the remote cluster connects to the local cluster via a SIP trunk or an H323 intercluster trunk. Cisco Unified Communications Manager updates the recorder again when the far-end party retrieves the call either from the same or a difference device. Cisco Unified Communications Manager does not update the recorder if the far-end party that parks the call is in the local cluster. In this case, Cisco Unified Communications Manager only updates the recorder when the call gets retrieved from a different device.

    For remote Call Park and Retrieve, the remote Cisco Unified Communications Manager sends the display name Call Park update. This update contains an empty directory number/address; therefore, the far-end address changes to empty. Due to the far-end address change, the local Cisco Unified Communications Manager sends the update with the empty far-end address to the recorder.

    In the current Call Park implementation, the far-end or X-Refci may be empty when recording Call Park for Roundtable (RT) phone models such as 997X, 995X and 896X.

    Recording and Call Forward No Answer (CFNA)

    If the far-end party in a remote cluster blind-transfers the call to a party that has CFNA enabled, Cisco Unified Communications Manager updates the recorder with the ringing party as the far-end party address, provided the remote cluster connects to the local cluster with a SIP trunk or an H.323 intercluster trunk. Cisco Unified Communications Manager updates the recorder again when the call gets forwarded to the CFNA target. Cisco Unified Communications Manager does not update the recorder if the far-end party that blind-transfers g the call is in the local cluster. In this case, Cisco Unified Communications Manager only updates the recorder when the CFNA target answers the call.

    When a remote call becomes active, the call state stays active in a local cluster. When a remote far-end party performs a blind call transfer to a new remote far-end party and the party rings, the local Cisco Unified Communications Manager still sees the call state as active. Thus, for remote Call Forward No Answer, the local Cisco Unified Communications Manager sends UPDATE messages to the recorder for a new party because the call state is active.

    When a local call becomes active, the call state can change from active to ringing state. The local Cisco Unified Communications Manager can find out a current call state. Thus, for local Call Forward No Answer, the local Cisco Unified Communications Manager sends UPDATE messages to the recorder after a new far-end party answers a call.

    Recording and Conference Chaining

    If two or more near-end parties are in two or more conferences that are chained together, Cisco Unified Communications Manager can only update the recorder that they are using; separate conferences are identified by the different conference identifiers (b-number). The conference chaining information can be obtained via Call Detailed Records (CDRs).

    Cisco Unified Communications Manager sends UPDATE messages to a recorder if the far-end call information changes. For a conference case, the far-end party address specifies the b-number. If the far-end b-number remains unchanged, Cisco Unified Communications Manager does not send the UPDATE messages to the recorder.

    Using Route List and/or Multiple Destination Addresses on a SIP Trunk for Multiple Recorders

    When using a route list and/or multiple destination addresses on a SIP trunk for multiple recorders, the near-end and far-end recording calls of the same recording session can go to different recorders.

    If a Cisco Unified Communications Manager administrator configures a route list with multiple SIP trunks such that each SIP trunk points to a different recorder, Cisco Unified Communications Manager may not send the two recording calls of a recording session to the same SIP trunk, or to the same recorder. Depending on the selection algorithm that is provisioned in the route group, the likelihood of the two recording calls being sent to the same recorder may vary considerably. Similarly, Cisco Unified Communications Manager may not send the two recording calls to the same recorder if the administrator provisioned multiple IP addresses on a SIP trunk such that each IP address points to a different recorder. In this case, the calls get sent to the recorder that is randomly selected from the provisioned IP addresses.

    T configure Cisco Unified Communications Manager to support a recorder cluster configuration where a recording session may be redirected to another of the recorders in the cluster, configure a route list or provision multiple destinations on the recording SIP trunk.

    Configure Monitoring and Recording

    This section provides detailed examples of the steps that are necessary to configure monitoring and recording. The configuration checklist summarizes the steps in a single table and points to additional Cisco Unified Communications Manager documentation that discusses each menu option in detail.


    Tip

    Before you configure monitoring and recording, review the configuration summary task for this feature.

    Related Tasks

    Turn on IP phone BIB to allow Monitoring and Recording

    The built-in bridge of the agent phone must be set to On to allow its calls to be monitored or recorded.

    You can also set the Built-in Bridge Enable service parameter to On and leave the Built-in Bridge in the Phone Configuration window set to Default.

    Use the Device > Phone menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates turning on the IP phone BIB to allow monitoring or recording.

    Figure 39. Setting the Phone Built In Bridge to On

    Add user for Monitoring and Recording application

    You must first create the application user who is capable of invoking monitoring or recording, and the application user must belong to a group with monitoring and recording privileges.

    Add an application or end user from Application User Configuration window or the End User Configuration window.

    Use the User Management > Application User menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates adding a user for the monitoring or recording application.

    Figure 40. Adding a User for the Monitoring or Recording Application

    Add user to groups that allow Monitoring and Recording

    Add the user to the user groups: Standard CTI Allow Call Monitoring user group and the Standard CTI Allow Call Recording user group.

    Also add the user to Standard CTI Enabled user group.

    Use the User Management > Application User menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates adding the user to these user groups.

    Figure 41. Adding User to the Appropriate User Groups

    Configure tones for Monitoring or Recording

    Set the service parameters for playing tone to True to allow tone to be played either to agent only, to customer only, or to both.

    Applications that invoke monitoring or recording can also pass the play tone option to Cisco Unified Communications Manager. The monitoring tone or recording tone plays when either the service parameter or the application specifies the play tone option.

    Use the System > Service Parameters menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates using service parameters to configure tones.

    Figure 42. Using Service Parameters to Configure Tones

    Configure monitoring Calling Search Space

    The monitoring calling search space of the supervisor line appearance must include the agent line or device partition to allow monitoring the agent.

    Set the monitoring calling search space on the supervisor line appearance window.

    Use the Device > Phone menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration. When you display the Phone Configuration window for a phone, click on a line, such as Line [1], in the Association Information pane. (You can choose either a DN that has already been associated with this phone or you can add a new DN to associate with this phone.) In the Directory Number Configuration window that displays, configure the Monitoring Calling Search Space field for the chosen line on this phone.

    The following figure illustrates configuring the monitoring calling search space.

    Figure 43. Configuring DN for Monitoring Calling Search Space

    Enable recording for a line appearance

    To enable recording of an agent, set the Recording Option in the line appearance of the agent to one of the following options:

    • Automatic Call Recording Enabled
    • Selective Call Recording Enabled

    Select a pre-created recording profile from the drop-down list box. (Use Device > Device Settings > Recording Profile to configure a recording profile.)

    Use the Call Routing > Directory Number menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates enabling recording for a line appearance.

    Figure 44. Enabling Recording for a Line Appearance

    Add the Record softkey or programmable line key to the device template (optional)

    To enable a user to start and stop recording from a Cisco IP device, add the Record softkey or programmable line key to the device template.

    To add the Record softkey, use the Device > Device Settings > Softkey Template menu option in Cisco Unified Communications Manager Administration to create or modify a nonstandard softkey template. Configure the softkey layout for call state connected to have the Record softkey in the selected softkeys list.

    To add the Record programmable line key, use the Device > Device Settings > Phone Button Template menu option in Cisco Unified Communications Manager Administration. Enter the button template name, feature, and label.

    Create recording profile

    Create a recording profile from the Device Setting pull-down menu.

    Enter the recording profile name, recording calling search space, and recording destination address.

    Use the Device > Device Settings > Recording Profile menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates creating a recording profile.

    Figure 45. Creating a Recording Profile

    Create SIP profile for recorder (optional)

    Create a SIP profile for recording. Use the Device > Device Settings > SIP Profile menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    You can check the Deliver Conference Bridge Identifier check box, which delivers additional information (specifically, the b-number that identifies a conference bridge) to the recorder across the SIP trunk. If the check box is left unchecked, the far-end information for the remote conference remains empty.

    Check the Deliver Conference Bridge Identifier check box on the remote cluster SIP profile as well.


    Note

    Checking this check box is not required for recording, but the conference bridge identifier helps to update the recorder when recording calls that involve a conference bridge. If you do not create a new SIP profile for recording, you can use the Standard SIP Profile.

    See the Cisco Unified Communications Manager Administration Guide for details of configuring SIP profiles.

    The following figure illustrates creating a SIP profile for recording.

    Figure 46. Creating a SIP Profile for Recording

    Create a SIP trunk that points to the recorder

    Create a SIP trunk that points to the recorder.

    Enter the recorder DN, which must match a route pattern for the SIP trunk or a route list that includes the recorder.

    Choose the appropriate SIP profile that you configured for recording.

    Use the Device > Trunk menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates creating a SIP trunk that points to the recorder.

    Figure 47. Creating a SIP Trunk That Points to the Recorder

    Create a route pattern for the recorder

    Create a route pattern for the recorder SIP trunk. The Recording Destination Address in the recording profile must match this pattern.

    Select the SIP trunk that points to the recorder, or select a route list of which the recorder is a member.

    Use the Call Routing > Route/Hunt > Route Pattern menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates creating a route pattern for the recorder.

    Figure 48. Creating a Route Pattern for the Recorder

    Create recorder redundancy

    Many recorders have built-in proxy and redundancy functionalities, for example, Nice/Witness recorders.

    You can also use the following mechanism to achieve recorder redundancy:

    • Use the SRV record for the recorder destination address in SIP trunk configuration.
    • Use multiple recorders for redundancy and load balance. Create a SIP trunk for each recorder; create a route list to include the route groups that have individual SIP trunks as a member.

    Use the Device > Trunk menu option in Cisco Unified Communications Manager Administration to perform the necessary configuration.

    The following figure illustrates enabling SRV for a SIP trunk.

    Figure 49. Enabling SRV for a SIP Trunk

    Set the Monitoring and Recording service parameters

    This section describes the service parameters that are related to call monitoring and call recording features.

    Notification

    The following service parameters affect the playing of notification tones to the parties that are monitored or recorded by the call monitoring and call recording features:

    Clusterwide Parameters (Feature - Call Recording)
    • Play Recording Notification Tone To Observed Target
    • Play Recording Notification Tone To Observed Connected Parties
    Clusterwide Parameters (Feature - Monitoring)
    • Play Monitoring Notification Tone To Observed Target
    • Play Monitoring Notification Tone To Observed Connected Parties

    The default value for these service parameters specifies False. You must change the value of each parameter to True to enable the particular notification tone to play.

    See the Monitoring and Recording notification tones for more information about these service parameters.

    Codec usage

    Use the following service parameters to enable or disable usage of the G722, iLBC, and iSAC codecs:

    Clusterwide Parameters (System - Location and Region)
    • G722 Codec Enabled
    • iLBC Codec Enabled
    • iSAC Codec Enabled

    See the Limit codec usage for recording calls for more information about these service parameters.

    Built-In Bridge

    The following service parameter enables or disables the built-in bridge on phones:

    Clusterwide Parameters (Device - Phone)
    • Built-in Bridge Enable

    See the Turn on IP phone BIB to allow Monitoring and Recording for more information about this service parameter.