For years call recording software vendors all over the world utilized network-based recording to record CUCM phone calls. The “network-based” approach is also known as “active recording” or “SPAN-less recording” and is actually based on media-forking feature supported by the most of Cisco IP phones and also Cisco Unified Border Element (CUBE).
The media forking approach is loved by all call recording vendors:
- it is easy to configure – you just enable it in CUCM without the need to create a SPAN port on each router,
- it provides more context about the call,
- it provides high-availability – you can configure several receivers in CUCM and when the primary recorder is down CUCM automatically switches to the alternative.
But still, till now Cisco IP phones and CUBE only forked media to one destination. This is finally changed in Cisco CSR 12.5!
Cisco Collaboration Systems Release 12.5 (Callisto) supports media forking to multiple destinations.
Media forking to multiple recorders is a new CUBE feature supported by IOS XE 16.10.1 or later. What’s the idea?
The new CUBE feature is called “media-proxy” and allows CUBE to receive media forked by Cisco IP phones (equipped with built-in bridge) or voice gateway and stream the received media to several destinations simultaneously in real-time. You can configure up to 5 destinations which will receive the forked media.
- more options and flexibility to high-availability deployments – you can now record calls by 2 recorders simultaneously (will be supported in the next release of PhoneUP Call Recording),
- the ability to use several applications processing media in real time – for example, two different call recording systems AND real-time speech analytics software.
The requirements are:
- Cisco Unified Communications Manager 12.5
- Cisco IOS XE 16.10.1 available on:
- Cisco 4000 Series-Integrated Services Routers (ISR G3 - ISR4331, ISR4351, ISR4431, ISR4451)
- Cisco Aggregated Services Routers (ASR - ASR1001-X, ASR1002-X, ASR1004 with RP2, ASR1006 with RP2)
- Cisco Cloud Services Routers (CSR1000V series)
What is also important:
- CUBE media-proxy does not support colocation with CUBE,
- video recording is NOT supported also.
There are different reasons that can cause call getting hung on CUBE. It was noticed that the calls get hung more often in case of a sudden loss of connection. They have an "incomplete" state, having one or two call legs.
cube#show call active voice compact
A/O FAX T Codec type Peer Address IP R:
Total call-legs: 2
126523 ANS T74411 g711ulaw VOIP P79033956416 18.104.22.168:18724
126524 ORG T74411 g711ulaw VOIP P3500 172.16.127.50:21284
To go into the details:
show sip calls
Now delete the call:
clear call voice causecode 17 calling-number 79033956416
This article is about practical monitoring that helps answering such questions as call activity, the calls passing through a trunk, etc.
Call activity on CUBE
- Active calls:
show call active voice compact
- The active calls summary by the number of call legs:
show call active voice summary
- Recent calls:
show call history voice compact
Call activity on CUBE from the point of view of CUCM
You can view the CUBE load in CAR:
Proceed to: Device Reports -> Trunk -> Utilization
Find your trunk and specify the report.
This report can only give you the notion about the trunk load in general, without any details.
Monitoring CUBE activity through SNMP
This is a very useful feature that allows you to perform online monitoring without any commands and reports. You can monitor the calls and connections through SNMP and view this information in PRTG. The most useful MIB is:
We are interested in the following OIDs here:
- CISCO-VOICE-DIAL-CONTROL-MIB/cv call volume/cv call vol conn total active connections
- CISCO-VOICE-DIAL-CONTROL-MIB/cv call vol if: Loopback0/cv call vol media incoming calls
- CISCO-VOICE-DIAL-CONTROL-MIB/cv call vol if: Loopback0/cv call vol media outgoing calls
Loopback0 is an inside interface on which all internal dial peers are bound, for example, like this:
dial-peer voice 500124 voip
description internal to CUCM
session protocol sipv2
session target ipv4:10.190.65.12
voice-class codec 1
voice-class sip bind control source-interface Loopback0
voice-class sip bind media source-interface Loopback0
ip qos dscp cs3 signaling
Directory numbers in trunk calls
Suppose that after PRTG monitoring a call activity surge aroused our interest. There are two ways to know what subscribers took part in it:
Proceed to: Call Manager -> Call Process -> Session Trace
Here we can specify the time period and determine the gateway we are interested in using Called Named Device field.
Session Trace is useful for obtaining up-to-date information on all the calls in cluster nearly in real time.
And, of course, we always can get the information on the calls from a CDR file.
- Log in to Cisco Unified CallManager CAR interface: https://:8443/car/
- CDR > Export CDR/CMR
- Select the time period and click Export to file.
- On the next screen you can download the file.
- Then open the file in MS Excel to analyze it.
For your convenience you should do the following:
- Select the first line (legend), then in MS Excel menu click Data -> Filter -> AutoFilter, and then Format -> Column -> AutoFit.
The fields of interest are:
You can also find the trunk by its name.
You can find the field descriptions here: Cisco Call Detail Records Field Descriptions
Notice the date and time format in dateTimeOrigination field. This is the number of seconds beginning from the midnight (00:00:00) of January 1, 1970. To make this readable, you can insert a column, format it as Date and use the following formula: =((E2 + 14400) / 86400) + 25569.