Configuring Cisco Unified Border Element (CUBE) based recording

Owned by Kiss, Mate
May 24, 2022
4 min read

Overview

CUBE supports SIP/SIPREC based recording for voice and video calls passing the CUBE. CUBE supports standard SIPREC based integration and SIP based with customer CUBE specific headers. Both integrations are supported by the Verba platform.

You can learn more from official Cisco documents about CUBE based recording:

Prerequisites for CUBE recording

Please visit the related Cisco documentation, linked above for up to date information on supported Cisco routers and IOS versions.

Restrictions for CUBE recording

  • SIP-SIP call flows are only supported, For TDM, H.323 please check our /wiki/spaces/docs/pages/6818267 solution. TDM and H.323 recording can be also achieved with a trick: TDM calls should be forced to pass through CUBE
  • Any media service parameter change via Re-INVITE or UPDATE from recording server is not supported. For example, hold-resume or any codec changes

  • IPv6-to-IPv6 call recording

  • IPv6-to-IPv4 call recording if the recording server is configured on the IPv6 call leg

  • Calls that do not use Session Initiation Protocol (SIP). Must be a SIP-to-SIP call flow

  • Flow-around calls

  • Session Description Protocol (SDP) pass-through calls

  • Real-time Transport Protocol (RTP) loopback calls

  • High-density transcoder calls

  • Secure Real-time Transport Protocol (SRTP) passthrough calls

  • SRTP-RTP calls with forking for SRTP leg (forking is supported for the RTP leg)

  • Multicast music on hold (MOH)

  • Mid-call renegotiation and supplementary services like Hold/Resume, control pause, and so on are not supported on the recorder call leg

  • Recording is not supported if CUBE is running a TCL IVR application with the exception of survivability.tcl, which is supported with SIPREC based recording

  • Media mixing on forked streams is not supported

  • Digital Signal Processing (DSP) resources are not supported on forked legs

  • If the main call has multiple video streams (m-lines), the video streams other than the first video m-line are not forked

  • Application media streams of the primary call are not forked to the recording server

  • Forking is not supported if the anchor leg or recording server is on IPv6

  • Server Groups in outbound dial-peers towards recorders is not supported.

Configuration

The recording method and configuration steps are very similar to UCM phone forking based recording solution. Recorder servers are invited into the to be recorded calls via SIP, RTP forking is done by the recorded endpoint. Configuration steps are also similar, UCM phone forking based recording analogous steps are highlighted to make it easier to understand the concept for users who has been using phone-based recording as well.

  • Create dial-peer(s) pointing to recorder server(s) (similar to UCM recorder trunk configuration)
  • Create a media profile dedicated to the recording, enumerate dial-peers pointing to the recorder servers. This is a logical link between recorders - to be recorded calls (similar to UCM central recording recorder profile configuration)
  • If you want to record video calls then create a video profile, specify the reference frame requesting method
  • Assign the media profile and optional video profile to a media class
  • Assign the media class to the to be recorded incoming dial-peer(s) (similar to UCM central recording extension-specific recording options)

High Availability

You can configure failover and load-balancing for recorder servers:

  • Failover: media-recording command should enumerate the destination number of recorders. If the active recorder becomes unavailable the CUBE will assign the next recorded call to the next available recorder in the list.
  • Load-balancing: Load-balancing of recorder servers can also be achieved. In this case, the recorder dial-peers should be configured for the same destination number and with the same priority. In this case, CUBE will randomly distribute the calls between recorders with the same destination number
  • Failover + Load-balancing: You can also combine the two methods and so have an active and backup recorder pools

Configuring CUBE for SIP based recording

The following steps with example values will enable voice and video recording of all 4-digit called numbers on recorder 192.168.1.200. Commands should be issued in terminal configuration mode.

Step 1 - Allow voice connections to recorder servers. Add all of your recorder servers IP or IP subnets so the CUBE will trust and allow communication over SIP with them.

voice service voip
ip address trusted list
ipv4 192.168.1.0 255.255.255.0

Step 2 - Create a codec class enumerating supported codecs and codec preferences by the recorder. You can skip this step and assign a specific codec to the recorder dial-peer but with codec class enumerating multiple codecs you can save transcoding resources since we support most of the codecs natively.

voice class codec 1
codec preference 1 g722-64
codec preference 2 g711alaw
codec preference 3 g711ulaw
codec preference 4 g729r8
codec preference 5 g729br8
video codec h264

Step 3 - Create a dial-peer pointing to the recorder

dial-peer voice 9999 voip
description Verba CUBE Forking Recorder 0
destination-pattern 9999
session protocol sipv2
session target ipv4:192.168.1.206:5060 (specify the address on which Verba Unified Call Recorder is listening)
session transport tcp
voice-class codec 1 (specify the codec list supported by the recorder natively)
dtmf-relay rtp-nte (RFC 4733/2833 based DTMF is supported by the recorder)

Step 4 - Create a recorder profile

media profile recorder 100
media-recording 9999 (here you can enumerate the destination number of recorder servers)

Step 5 - Create video profile (optional, only if you want to record video calls)

media profile video 101
monitor-ref-frames
ref-frame-req sip-info

Since video compression algorithms are recursive and contain referencing to previous frames (inter-frame, motion-compensated prediction) it is crucial to start the recording at a key/reference frame. CUBE is able to request keyframe automatically after the recorder establish a connection with the call session from participating endpoints

To control keyframe request two generally used method is available and configurable:

  • SIP INFO request with Fast Picture Update encoder request: can be set by ref-frame-req sip-info command
  • RTCP FIR: can be set by ref-frame-req rtcp retransmit-count 4 command

Step 6 - Create media class and assign media and video profile

media class 100
recorder profile 100
video profile 101 (optional, only if video calls are to be recorded)

Step 7 - Assign recorder media class to the to be recorded incoming dial-peers. It is important to assign it to incoming and not to outgoing peer.

dial-peer voice 9999 voip
description Inbound dial-peer for recorded calls
session protocol sipv2
incoming called-number ....
voice-class codec 1
media-class 100