The Anatomy of a Call Recording Service – Cisco Unified Communications Manager

Call recording is an interesting topic for me and it’s sometimes hard to understand, but It’s easy when you break it down to get what it is all about.

My experience varies from different vendors and most of it comes to the same place, at least when preparing CUCM for Recording services. This post is just to go over what is involved form CUCM’s preparation and a bit of an explanation when possible 🙂

Preparing CUCM for Call Recording Server

– Decide with your vendor how you will be recording the calls

SPAN Recording (All recording services I’ve used use this as one of their methods)

Switched Port Analyzer, is a technology based on sniffing the packets. So what happens here is that the Phones, Voice Gateways, and CUCM servers need to be able to send all sniffed packets to the recording server. At this point, the recording server gets all RTP or Voice packets and decodes them to be stored as Audio files to certain destination.


There are few requirements for this to work in case you are in a Virtual Environment like VMware, but I will not spoil the fun for you, so check those requirements here

Automatic Call Recording (Your CUCM server sends the call to be recorded to an IP destination)

In automatic call recording, after a call becomes active, two server calls get made to the built-in bridge (BIB) of the agent phone. The agent phone automatically answers. Two server calls then get redirected to the recorder.


Here is what needs to be done to get it ready on CUCM

Turn on IP phone BIB to allow monitoring or recording


Add user for monitoring or recording application


Add user to groups that allow monitoring and recording

Here are the groups you may need, depending on the vendor you are using they will recommend a different set of Permissions, Personally I’d like to create an Group

Standard CTI Allow Call
Standard CTI Allow Call
Standard CTI Allow Call
Standard CTI Allow Control of All Devices
Standard CTI Allow Control of Phones supporting Connected Xfer and conf
Standard CTI Allow Control of Phones supporting Rollover Mode
Standard CTI Enabled
Standard CTI Secure Connection

Add SEP or UDP Profiles

Add the phones/Devices that need recording to the Controlled Devices on the Application User you just created

Configure DN for a monitoring calling search space

Nothing new here, I would create a New CSS called Recording and a Partition called Recording

Enable recording for a line appearance

Create a recording profile


Create a SIP trunk that points to the recorder


Create a route pattern for the recorder


If you feel like going to the Official Documentation, click the link

And/Or the Illustrated Steps I just created, or the one created by Cisco here is the link

The rest of the configuration needs to take place at the Recording software, but the above referenced gives you a good idea of what needs to be configured at the CUCM interface to make sure Call Recording works.

What to look forward to?

If you got this far, thank you for hanging to the end of the post, this is a Blog post that I should have written long time ago 🙂

About the Author:

Andres Sarmiento, CCIE # 53520 (Collaboration)
With more than 13 years of experience, Andres is specialized in the Unified Communications and Collaboration technologies. Consulted for several companies in South Florida, also Financial Institutions on behalf of Cisco Systems. Andres has been involved in high-profile implementations including Cisco technologies; such as Data Center, UC & Collaboration, Contact Center Express, Routing & Switching, Security and Hosted IPT Service provider infrastructures.

You can follow Andres using Twitter, LinkedIn or Facebook

ccna collab

5 thoughts on “The Anatomy of a Call Recording Service – Cisco Unified Communications Manager”

  1. If it helps anyone…

    I’ve had some interop issues where 3rd-party recorders matched on the SIP “From” header instead of pairing up with JTAPI events.. When this happened, after normalization/de-normalization of DNs for external calls, the recording never happened as the recording didn’t pair the incoming SIP request to the call events in JTAPI. I wrote this Lua script to re-write the From header to the actual DN pattern using the “x-nearendaddr” tags:

    Caveats would be whether that the DN is obviously not partition-aware (watch for multi-tenancy or overlapping extension scenarios), and if this approach will continue to be used now that MediaSense is defunct.

    This is good for signalling analysis:

    And this:

    1. I would love to find out more in this one, as it is not widely used. SPAN recording is very intrusive, due to the sniffing nature of the procedure. I think the only possible encryption will happen at Rest and not in transit. SIP recording or Network Recording will allow Secure Recording.

  2. The monitoring css is only used for silent monitoring and is not part of the actual call recording configs. For just the recording, the recording profile contains the css which needs to reach the route pattern to reach the recording server. I wish Cisco would move that setting away from the recording section so it wouldn’t confuse people.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top