Cisco Specific Integrations
Purpose
This page provides an overview of the various recording options provided by us when Call Recording is paired with a Cisco contact center. We can record media traffic from a variety of Cisco devices using several types of media capture. This page describes the various recording methods available, the overall architecture, and what can be recorded. Configuration and supported scenarios are provided in separate sections.
A list of supported CUCM versions can be found here - Supported Platforms.
Cisco Recording Methods
The oldest method of Cisco recording is Passive SPAN-based Recording. This method is still an option in the following cases:
Recording on a SIP trunk without active CTI control.
Passive Recording with JTAPI signaling is an improved version of passive recording. It ensures the capture of all the scenarios listed in the Supported Call Scenarios for recording. It is useful for installations in which you can't record actively. For example, installations with phones that don't support silent monitoring (phones without built-in bridges).
Active Recording with JTAPI offers the best functionality and reliability on a Cisco platform. It is recommended whenever possible.
Please note that one JTAPI process can handle maximum of 2500 devices. So if you have more than 2500 devices to observe by this user then create additional users and assign them to appropriate JTAPI adapters in the Eleveo application.
Passive SPAN-Based Recording
Passive Recording is an older approach to call recording from an IP PBX. It doesn't require direct support from the IP PBX and is suitable for situations where another active recording method cannot be used. For example, when Cisco IP phones do not support the "Build-in Bridge" function.
Passive Recording of voice calls means:
capturing and interpreting a telephony signaling protocol
interpreting call events based on this information
capturing voice traffic as it flows between IP endpoints. No direct interaction with a PBX or with endpoints is necessary. Therefore, you don't need special support on the side of PBX.
Call Recording connects to the SPAN (Switched Port Analyzer) port to monitor all network traffic and pick out only the VoIP traffic to record. It "sniffs" for signaling and RTP (Real-Time Protocol) packets via the SPAN port. These packets are taken directly from the network flow based on the call’s header (sender, recipient, and type of traffic). Call Recording uses a network adapter in promiscuous mode on the recording server from a SPAN port on a network switch to detect header information.
Since IPT communication happens in real-time, the capture of the packets should also be in real-time. Captured packets are stored temporarily and processed when the call ends. The main challenge is the independence of UDP packets used for the transmission of data. As every packet can use a different path from the sender to the recipient, they may arrive out of sequence.
Therefore, in very wide networks, the passive recording system should monitor every possible route of the packets.
There are two main ways to capture the RTP packets with the SPAN port:
SPAN the VOIP Gateway port for all the inbound and outbound traffic. This offers one contact point for recording. However, this method can't capture internal, peer-to-peer (phone to phone) calls since the VOIP traffic is sent directly between the phones and doesn't flow through the gateway port.
Set up a VLAN (Virtual LAN) and include all phones within it then use a SPAN to monitor all the phones on that VLAN. This allows the recording of all inbound, outbound, and internal traffic. Its disadvantage is that not all phones are on the same VLAN at all times. Therefore, multiple SPANs are often needed.
Multi-Site Passive Recording
In a multi-site deployment for Passive Recording on a Cisco platform (as the signaling is only available at the SPAN port of each site), you should have a Recording Server on each site. The media recorded is synchronized on a Replay Server. You can use the Replay Server to play back the recordings for all sites centrally.
Cisco Enhanced Passive Recording With JTAPI Signaling
The active detection of calls through JTAPI is an enhancement of the purely passive method of recording. A CTI (Computer Telephony Integration) interface provides information about call events. Voice media should be captured from the network through a SPAN port. The active detection of calls needs interconnection with a soft switch through the CTI protocol. Direct support on the soft switch is needed to provide call events.
Advantages of Passive Recording with JTAPI:
Through the use of JTAPI signaling to detect the calls, Call Recording can capture the RTP streams for more complicated scenarios. For example, Conferences.
Through the use of RSPAN and VLAN, you can direct the RTPs to a switch in another location.
Disadvantages of Passive Recording with JTAPI:
The use of SPAN ports puts an extra load on the switches since all traffic should be mirrored.
Cisco Active Recording With JTAPI
Active recording captures the call data and the call stream through a direct connection with the PBX platform. This means the signaling information can't be lost. Active recording achieves close to 100% capture reliability. Additionally, other call data contained on the platform can be captured and stored in Call Recording.
Instead of monitoring the stream directly, as in Passive (SPAN) Recording, the CUCM controls the Active Recording. It identifies the calls to be recorded based on recording profiles. When a call with a valid recording profile is detected, the voice stream is copied directly to the Call Recording recorder server. When the calls are decoded, they are immediately available within the Call Recording web-based user interface. Cisco also refers to this method as "phone-based media forking" or "device-based recording". Active Recording through the CUCM doesn't require the SPAN port to monitor network traffic and identify VoIP traffic. However, it does require the configuration of system options in the CUCM. Refer to the Cisco Unified Communications Manager Features and Services Guide for more details.
Only Cisco 3G IP phones and newer can be recorded through Active Recording.
For an up-to-date list of all Cisco phones that support Active Recording see the Unified CM Silent Monitoring Recording Supported Device Matrix or the CTI (TAPI/JTAPI) Supported Device Matrix.
These IP phones must:
Support Active Recording (silent monitoring)
Have their built-in bridge enabled
Have the Automatic Call Recording Enabled option set in their line appearance
Have a valid Recording Profile associated with their line appearance
Have JTAPI signaling
Advantages of using Active Recording:
It is easy to administer.
It is adaptable to your network topology.
It doesn't use SPAN ports. Therefore, it frees resources for network monitoring.
There is no need for each site to have its own recorder.
There is no need for a replay server that only replays remote sites.
Because the PBX is aware of recording it can supply notification tones when legal compliance is required.
Active recording increases reliability and control.
Recording Limitation Linked to the Configuration
Cisco Selective User Recording
QM supports the Cisco User selective Recording feature. In fact, Selective User Recording represents a variation of the Cisco Active Recording with JTAPI described in the section above. The active recording captures the call data and the call stream through direct connection with the PBX platform. This means that the signaling information can't be lost. Selective User Recording achieves close to 100% reliability in offering the user to record and store a specific call. Additionally, other call data contained on the platform can be captured and stored in Call Recording. All the data is immediately available within Eleveo for further use.
Also, by this method, the CUCM controls the active recording. It identifies the calls to be offered to the user for recording based on the User Selective recording profiles. When a call with a valid recording profile is detected and the user, press the Record button, the voice stream is copied directly to the Call Recording recorder server. When the calls are decoded they are immediately available within the Call Recording web-based user interface. Cisco refers to this method as "phone-based media forking" or "device-based recording". User Selective Recording through the CUCM doesn't require the SPAN port to monitor network traffic and identify VoIP traffic. However, it does require the configuration of system options in the CUCM. Refer to the Cisco Unified Communications Manager Features and Services Guide for more details.
Selective User Recording only works if Recording Rules are NOT set! More on Recording Rules.
Only Cisco 3G IP phones can be recorded through Selective User Recording.
For an up-to-date list of all Cisco phones that support Active Recording see Unified CM Silent Monitoring Recording Supported Device Matrix or the CTI (TAPI/JTAPI) Supported Device Matrix.
In selective user recording, an agent or an IP Phone user may start or stop a recording session using a soft key or programmable line key. In selective user recording, the call recording status displays on the Cisco IP phone.
These IP phones must:
Support Active Recording (silent monitoring).
Have their built-in bridge enabled.
Have the Selective Call Recording Enabled option set in their line appearance.
Have a valid Recording Profile associated with their line appearance.
Have JTAPI signaling.
DIAGRAM: SELECTIVE USER RECORDING – TYPICAL CALL FLOW
Following is a typical call flow for selective user recording:
A call is received and answered on a line configured for selective recording (DIAGRAM: Steps 1 and 2).
The called party starts the recording session by pressing the ‘Record’ soft key or programmable line key (DIAGRAM: Step 3).
Cisco Unified Communications Manager automatically sends two call setup messages to the BiB (Called) device: one to set up the media stream from the called party and the second to set up the media stream from the calling party (DIAGRAM: Steps 4 and 5).
Cisco Unified Communications Manager sends an INVITE to the recorder via SIP trunk for both calls (DIAGRAM: Steps 6 and 7).
The recorder accepts both calls and receives two RTP streams from the device BiB.
The phone displays the status of the recording session. The Record key toggles to Stop Recording.
The typical use case for the Cisco Selective User Recording is a situation within a company back office or even a Call Center where for any reason it's not necessary to record all interactions, only those of particular interest are to be recorded. In such situations, the telephony user can trigger the recording start by pressing a soft key or programmable link key. The user can stop and restart the recording at any time during the call using the Record and Stop keys. This is particularly useful for PCI DSS compliance, for example.
Such a recorded call is represented within the Call Recording server User Interface as flows. The part of the call before the recording start is not displayed at all. The recorded part is displayed as usual. The sections of the call which were not recorded are represented as silence, and when the recording is resumed it shows up as usual.
Cisco Basic Selective Silent Recording
Eleveo supports another capability of the Cisco Unified Communication Manager (CUCM). The Basic Selective Silent Recording is a variation of Cisco Active Recording with JTAPI described in the section above. Active recording captures the call data and call stream through direct connection with the PBX platform. This means the signaling information can't be lost. Selective Silent Recording achieves close to 100% reliability in offering to the eligible user or to a system user, like the Call and Screen Recording Server, to record and store calls of particular interest. Additionally, other call data contained on the platform can be captured and stored in Call Recording. All the data is immediately available within the Eleveo for further use. Contact center supervisors and/or to the Recording Server can select which calls to be recorded temporarily based on business rules and events.
When a recording session is invoked selectively, Unified Communications Manager delivers the unadulterated speech (two RTP streams) to the recording server through a Session Initiation Protocol (SIP) trunk established between the Unified Communications Manager server and recording server.
When in progress, the Silent recording is indicating the recording to both call participants by a silent beep tone every 20 seconds.
The use of Basic Selective Silent Recording will significantly decrease your network traffic when only a defined portion of customer interaction needs to be recorded.
Only Cisco 3G IP phones can be recorded through Selective User Recording.
For an up-to-date list of all Cisco phones that support Active Recording see Unified CM Silent Monitoring Recording Supported Device Matrix or the CTI (TAPI/JTAPI) Supported Device Matrix or the CTI (TAPI/JTAPI) Supported Device Matrix.
These IP phones must:
Support Active Recording (silent monitoring).
Have their built-in bridge enabled.
Have the Selective Call Recording Enabled option set in their line appearance.
Have a valid Recording Profile associated with their line appearance.
Have JTAPI signaling.
Have recording Rule set within the QMS.
Following is a typical call flow for selective silent recording:
A call is received and answered on a line configured for selective recording.
The CUCM sends a JTAPI message to the recorder which according to its recording rules request or reject the recording session.
Cisco Unified Communications Manager sends upon the request two call setup messages to the BiB (Called) device: one to set up the media stream from the called party and the second to set up the media stream from the calling party.
Cisco Unified Communications Manager sends an INVITE to the recorder via SIP trunk for both calls.
The recorder accepts both calls and receives two RTP streams from the device BiB.
The typical use case for the Cisco Selective Silent Recording is a situation within a company back office or even a Call Center where for any reason it's not necessary to record all interactions, only those of particular interest are to be recorded. In such situations, QM can trigger the recording start according to the recording rules.
Such a recorded call is represented within the Call Recording server User Interface together with all other call attached data provided or by the CUCM or by the Contact Center system.
Cisco Active Recording Integrated With UCCE
In addition to active recording the integration with UCCE can provide additional service-related information. For example: Service, Agent, Skill Group, Caller Entered Digits, User Variables, and Wrapup Data. This is provided through CTI protocol.
Active Recording Integrated With UCCX
In addition to active recording the integration with UCCX can provide additional service-related information. For example: Service, Agent, Skill Group, Caller Entered Digits, User Variables, and Wrapup Data. This is provided through CCX CTI protocol.
CUBE Active SIP Recording
Overview
Active SIP Recording (ASR) is an Eleveo recording method that is based on the dial-peer forking feature of Cisco Unified Border Element (CUBE). Eleveo is able to record calls and video forked by CUBE, regardless what type of communication manager you use in your Contact center. The only condition is that the calls and video have to go through the Cisco CUBE:
To record internal calls, it is necessary to configure your network so that all internal calls go through the CUBE
ASR requires configuration on CUBE only, there is no need for configuration on the CUCM side. ASR enables recording of all calls that go through the CUBE and it doesn't need a JTAPI connection to CUCM, therefore you can record non-JTAPI devices such as Cisco Jabber clients without CTI support.
Cisco Jabber Clients supporting CTI/JTAPI integrations are suitable to be recorded via Active Recording with JTAPI. For a list of Cisco Jabber Clients with CTI support, refer to the Cisco Devnet site.
Recording Rules
The Call Recording server accepts ALL recording sessions going through ASR/CUBE regardless of the pre-configured CR recording rules. The standard Recording Rules are ignored. If you wish to limit the recording to a specific range, it is necessary to create a DO NOT RECORD rule for all numbers except those you wish to record.
Enabling CUBE Active SIP Recording
There are two steps necessary to enable the CUBE Active SIP Recording feature:
Configure your platform. The steps are described in the section: Preparing CUBE for Network-Based Recording
Enable Active Sip Recording (ASR): Configuring ASR Driver
Configure your Eleveo: Setting up the Eleveo Server Node
List of supported calls scenarios can be found here - Supported Call Scenarios by Recording Method
SIPREC Recording
The SIPREC recording method can be considered as a variation of the above mentioned CUBE ASR. All parts are identical with one but important difference. The Session Initiation Protocol (SIP) used this time corresponds more to the latest SIP RFC standardization. The Session Border Controller serving as Media forking point and SIP signaling provider is also in this case the Cisco Unified Border Element (CUBE).
SIPREC requires configuration on CUBE only there is no need for configuration on the IP PBX side. Our SIPREC enables recording of all calls that go through the CUBE and it doesn't need any IP Telephony integration with the PBX, therefore you can also record non-CTI devices and applications.
The Call Recording server accepts ALL recording sessions going trough ASR/CUBE regardless of the pre-configured CR recording rules. The standard Recording Rules are ignored. If you wish to limit the recording to a specific range, it is necessary to create a DO NOT RECORD rule for all numbers except those you wish to record. Any calls that don't match the criteria of the configured call recording rules are recorded. In a situation where no call recording rules have been configured all calls are recorded.
Enabling SIPREC Recording
There are two steps necessary to enable the SIPREC Recording feature:
Configure your platform. The steps are described in the section: Configuring CUBE for SIPREC Recording
Enable Active Sip Recording (ASR): Configuring ASR Driver
Configure your Eleveo server: Setting up the Eleveo Server Node
A list of supported calls scenarios can be found here - Supported Call Scenarios by Recording Method