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.
This provides:
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.
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 188.234.136.49: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: https://cucm_ip:8443/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: CISCO-VOICE-DIAL-CONTROL-MIB 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 preference 3 destination-pattern [1-4]... 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 dtmf-relay rtp-nte ip qos dscp cs3 signaling no vad
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:
RTMT 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.
CDR 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: origDeviceName destDeviceName You can also find the trunk by its name.
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.
In this case, login is 48879800, and it is contained in INVITE field only.
"Record"
"Directory"
"Lock"