Dial-peer Based Recording
The Dial-peer Based Recording feature supports software-based forking for Real-time Transport Protocol (RTP) streams. Media forking provides the ability to create midcall multiple streams (or branches) of audio and video associated with a single call and then send the streams of data to different destinations. To enable network-based recording using Cisco Unified Border Element (CUBE), you can configure specific commands or use a call agent. CUBE acts as a recording client and MediaSense Session Initiation Protocol (SIP) recorder acts a recording server.
Feature Information
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Feature Name |
Releases |
Feature Information |
---|---|---|
Security Readiness Criteria (SRC)—Modified the command show sip-ua calls . |
Cisco IOS XE Gibraltar Release 16.11.1a |
Command show sip-ua calls is modified to display local crypto key and remote cryto key. |
Deployment Scenarios for CUBE-based Recording
CUBE as a recording client has the following functions:
-
Acts as a SIP user agent and sets up a recording session (SIP dialog) with the recording server.
-
Acts as the source of the recorded media and forwards the recorded media to the recording server.
-
Sends information to a server that helps the recording server associate the call with media streams and identifies the participants of the call. This information sent to the recording server is called metadata.
Note |
CUBE simply forwards the RTP streams it receives to the SIP recorder. It does not support omitting any pre-agent VRU activity from the recording. If you want to omit the VRU segment from a recording, you must use the Unified CVP to route the agent segment of the call back through CUBE. To do this, you need to separate ingress and media forking function from one another, which means you must either route the call through the ingress router a second time, or route it through a second router. |
Given below is a typical deployment scenario of a CUBE-based recording solution. The information flow is described below:
-
Incoming call from SIP trunk.
-
Outbound call to a Contact Centre
-
Media between endpoints flowthrough CUBE
-
CUBE sets up a new SIP session with MediaSense based on policy.
-
CUBE forks RTP media to MediaSense. For an audio call, audio is forked. For a video call, both audio and video are .forked. For an audio-only configuration in a audio-video call, only audio is forked. There will be two or four m-lines to the recording server, based on the type of recording
The metadata carried in the SIP session between the recording client and the recording server is to:
-
Carry the communication session data that describes the call.
-
Send the metadata to the recording server. The recording server uses the metadata to associate communication sessions involving two or more participants with media streams.
The call leg that is created between the recording client and the recording server is known as the recording session.
Open Recording Architecture
The Open Recording Architecture (ORA) comprises of elements, such as application management server and SIP bridge, to support IP-based recording. The ORA IP enables recording by solving topology issues, which accelerates the adoption of Cisco unified communication solutions.
Following are the three layers of the ORA architecture:
Network Layer
The ORA network layer is comprises call control systems, media sources, and IP foundation components, such as routers and switches.
Capture and Media Processing Layer
The ORA capture and media processing layer includes core functions of ORA—terminating media streams, storage of media and metadata, and speech analytics that can provide real-time events for applications.
Application Layer
The ORA application layer supports in-call and post-call applications through open programming interfaces.
In-call applications include applications that make real-time business decisions (for example, whether to record a particular call or not), control pause and resume from Interactive Voice Response (IVR) or agent desktop systems, and perform metadata tagging and encryption key exchange at the call setup.
Post-call applications include the following:
-
Traditional compliance search, replay, and quality monitoring.
-
Advanced capabilities, such as speech analytics, transcription, and phonetic search.
-
Custom enterprise integration.
-
Enterprise-wide policy management.
Media Forking Topologies
The following topologies support media forking:
Media Forking with Cisco UCM
The figure below illustrates media forking with Cisco Unified CallManager (Cisco UCM) topology. This topology supports replication of media packets to allow recording by the caller agent. It also enables CUBE to establish full-duplex communication with the recording server. In this topology, SIP recording trunk is enhanced to have additional call metadata.
Media Forking without Cisco UCM
The topology below shows media forking without the Cisco UCM topology. This topology supports static configuration on CUBE and the replication of media packets to allow recording caller-agent and full-duplex interactions at an IP call recording server.
SIP Recorder Interface
SIP is used as a protocol between CUBE and the MediaSense SIP server. Extensions are made to SIP to carry the recording session information needed for the recording server. This information carried in SIP sessions between the recording client and the recording server is called metadata.
Metadata
Metadata is the information that is passed by the recording client to the recording server in a SIP session. Metadata describes the communication session and its media streams.
Metadata is used by the recording server to:
-
Identify participants of the call.
-
Associate media streams with the participant information. Each participant can have one or more media streams, such as audio and video.
-
Identify the participant change due to transfers during the call.
The recording server uses the metadata information along with other SIP message information, such as dialog ID and time and date header, to derive a unique key. The recording server uses this key to store media streams and associate the participant information with the media streams.