Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Meeting Server

  • Archive

    «   July 2021   »
    M T W T F S S
          1 2 3 4
    5 6 7 8 9 10 11
    12 13 14 15 16 17 18
    19 20 21 22 23 24 25
    26 27 28 29 30 31  

Cisco call recording, silent monitoring and whisper coaching over MRA

Work from home is the New Normal for workers around the world. Cisco IP phones are gathering dust in the half-empty offices. Cisco Jabber deployed on remote devices (home PC, personal mobiles etc) and registered with CUCM over MRA (Mobile and Remote Access) through Cisco Expressway - this is how the typical Cisco voice infra looks like these days.

But what about call recording and agent coaching features (silent monitoring and whispering)? In this article we'll let you know the software versions you need to get this working, various limitations of these features in the MRA mode and some best practices.

If you're going to support remote workers with your on-premise Cisco Collaboration platform OR you're planning a call recording deployment for your MRA/Expressway configuration, the following might be useful.

First, the good news is that everything is supported assuming that your UCM/Expressway/Jabber versions are up to date.

The minimum configuration you need for the Built-in Bridge (or "Active";) call recording over MRA is:
- Cisco Jabber 11.9 (for Windows, for Mac, for Adroid or for iPhone/iPad)
- Cisco UCM Enterprise 11.5 (1) SU3
- Cisco Expressway X8.11.1

This min configuration has several major limitations:
a) with UCM 11.5 a mobile Jabber is not CTI-controlled which doesn't allow CUCM call recording software to determine the direction (incoming/outgoing) of a call though it can be recorded.
b) Recording only works for direct person-to-person calls and not for conferences.
c) Recording is not currently supported for Silent Monitoring and Whisper Coaching features.

Though you can record Cisco Jabber calls and access call recordings within Cisco Jabber.

In Cisco Collaboration Systems Release 12.0 the mobile Jabber became a CTI-cotrolled endpoint and the limitaion "a" from the point 2 was lifted.

Now, as Cisco Expressway is the crucial component of the MRA deployment all the limitations depend on its version. And with every new version of Cisco Expressway things are getting better. Lets take a look.

1 Cisco Expressway X12.5
Still there are major limitations for recording over MRA:
- recording does NOT work for conferences
- Silent Monitoring and Whisper Coaching are NOT supported at all
- in the case of call recording for Cisco Jabber endpoints, Jabber does not support injecting recording tones into the media streams.

2 Cisco Expressway X12.6
- starting from X12.6.1 Silent Monitoring is supported
- Whisper Coaching and Whisper Announcements are supported from X12.6.2.
The recording tones do not work for Jabber clients.

3 Cisco Expressway X12.7
No improvements to call recording, monitoring and whispering over MRA.

4 Cisco Expressway X14.0
MRA supports recording tones for Cisco Jabber clients and Webex Unified CM registered applications.

So, now you know exactly what call recording features are supported with your Mobile and Remote Access deployment.

Active Call Recording Configuration for Cisco UCM (CUCM)

In this article we’re going to tell you about active call recording configuration for Cisco UCM (CUCM). In a few words, active recording is a more comfortable, flexible, scalable and efficient call recording tool for Cisco devices (with BiB support). “Comparing to what?” you may ask. The answer will be: comparing to passive recording. Passive recording is performed by the means of traffic mirroring (using SPAN/RSPAN/ERSPAN).

It works like this: the recorder server collects a call’s metadata through API (in CUCM, JTAPI is a part of CTI), and RTP stream comes from a phone through BiB (Built-In Bridge) directly.

Active recording is supported by such vendors as Nice, ZOOM, Verint, STC (Speech Technology Center) and others. Let us turn now to configuration.

Configuring CUCM Application User

Log in to IP PBX interface. Proceed to User Management → Application User.

Click Add New. The following form appears:

  • Fill in the User ID
  • Enter the user’s password in the Password field. Enter the same password in “Confirm Password”.

Select available devices to be added to Controlled Devices.

Click Add to User Group to add roles.

This application user should be able to control users in order to record their phones. Assign the following roles:

  • Standard CTI Allow Park Monitoring
  • Standard CTI Allow Call Recording Standard CTI Allow Control of Phones supporting Connected Xfer and conf
  • Standard CTI Allow Control of Phones supporting Rollover Mode
  • Standard CTI Enabled

Click Add Selected.

Click Save. The Application User configuration is over. Now let’s configure a SIP trunk.

Configuring a SIP trunk

Proceed to Device → Trunk.

Then click Add New.

Set the Trunk Type = SIP trunk, Device Protocol = SIP.

Enter the Device Name for the trunk, enter its Description, select a Device Pool (a set of common parameters), set SIP Trunk Security Profile to Non Secure SIP Trunk Profile, set the SIP Profile to Standard SIP Profile.

Now, you should configure a Route Pattern (a route to the trunk).

Configuring CUCM Route Pattern

Enter a number that is not occupied in the dial plan. E.g. 1111. In the Gateway/Route List, select the trunk you have created.

Recording Profile

Proceed to Device → Device Setting → Recording Profile. Click Add New.

  • Enter the name of the profile;
  • Enter the number you have used for the Route Pattern configuration (in our case, that’s 1111).

Now you only have to configure recording for a phone line (turning on BiB), assign a Recording Profile to the phone, turn on Allow Control of Device from CTI option and set the Recording Option to Automatic Call Recording Enabled.

Cisco Secure Remote Working Tools

With pandemic in the picture, the interest in remote working tools has noticeably increased. But, as it turned out, not all tools can provide the required level of security and confidentiality. These features are exactly what Cisco’s communication solutions are aiming at. The company has conducted a series of webinars on such systems.

A Kiev Cisco system engineer Igor Sukaylo has started his presentation with several examples of the perpetrators’ ways to mess with your communications. E.g., spoofing their number to call anyone from “your” phone. Voice recognition problem has also been solved. In December, 2019 there has been a not so loud announcement on AI being able to imitate a subscriber’s voice. A Ukrainian start-up has created a piece of software that was able to replace a subscriber’s voice with any other voice on the fly. Combining these two possibilities, you can give any order to anyone. Actually, no public means of communication can be trusted. So, many companies and departments have started using corporate unified communications (UC).

The speaker has considered several measures that can be taken in this situation. One of them was implementation of cloud services. Cisco can deploy an infrastructure on customer’s site, or even implement a hybrid system combining cloud and local infrastructures. In particular, WebEx Rich components belong to hybrid infrastructures, enabling integration of a cloud service not only with a calendar, directories and corporate Key Management System, but also with phone and video components, located on a company’s site.

As a pilot project, Cisco can implement a full spectrum of remote and collaborative working tools: Jabber, Expressway, conferences. There will be almost no limitation to the number of participants and conferences, held simultaneously or altogether, without any functional restrictions. Restrictions may only arise due to the computing resources, though the requirements are really modest.

Concerning Jabber and MRA (Mobile and Remote Access) development: since version 12.5, the voice traffic between devices has been being passed through a point-to-point protocol. So, there is no “ground - cloud” transition for two communication devices. No delays, zero packet loss, higher quality. Voice and signaling traffic is being encrypted with a 264-bit key, which is sufficiently break-proof for today.

Nowadays you can simply bring home any video phone, any video terminal, literally any device that has been connected to the corporate infrastructure. And the public Internet access will remain.

According to the speaker, Cisco flagship video conferencing tool Meeting Server is the cheapest as well as the most advanced solution. It is also compatible with any device, and it can be deployed on a virtual server. Licensing is implemented not by the number of participants, but by the number of concurrent conferences.

Since self-isolation is important for all organizations, the question of interdepartmental contacts raises. You can’t visit your colleagues, and simple phone calls are not as efficient as personal interactions. Cisco can build unified interdepartmental communications, and a regular DNS on the Internet may serve as a central node. The connection is encrypted, of course.

Banking has been chosen for practical examples. In banks, there are services that require visual identification. To avoid personal visits, you can deploy Cisco Meeting Server (CMS) in a bank. A manager sends a client a link with a password. The client follows this link, a browser prompts them to enter the password, and a video session with the manager starts.

Banking also requires some protection from spoofed calls. You can build your own channel for that using a WebEx Teams-based cloud service. It provides an open API, so customers can embed the required WebEx Teams components into their own mobile applications. Clients can call a corporate contact center, send a message, start a video call, and (which is unique for now) a bank can call the client’s mobile app.

Distant meetings are important, too. They can’t be implemented with plain video conferences. That’s not enough. One of Cisco partners has a Meeting system, and Cisco has integrated its video conference in it. So, remote participants are going to have projects, resolutions and other documents. The whole process will be recorded on video.

Going back to WebEx, the speaker has noted its main advantages. First of them was the ease of use; second, a possibility to be integrated with different office applications, e.g. CRM systems; third, being able to work with external participants as well as with internal ones. You can use any device to connect to WebEx. In fact, WebEx is a universal platform.

WebEx is not just a remote meeting tool. It also includes WebEx Meetings, WebEx Training Center, WebEx Event Center and WebEx Support Center. All these products are optimized for specific functions. Such specialization has appeared more than 10 years old, in order to meet the requirements of Cisco clients.

WebEx can be integrated with several business applications, including Slack, which is a relatively popular communication platform. However, you can’t use Slack for video conferencing. WebEx Meetings is integrated with Slack on the level of commands. You can also integrate Slack with Google Gmail. If a customer has G Suite, native integration with G Suite is possible. And integrating WebEx Meeting with Google Class creates a kind of a light version of Learning Management System, increasing the usability for the teachers and students.

WebEx (specifically, WebEx Meetings) can also be integrated with some Microsoft products. When you are planning a conference or a meeting via Outlook, you can simply enter “@WebEx” in the “Location” field. Cisco calendar connector, integrated with the corporate environment, will send this request to WebEx, and all participants will get a corresponding link. Essentially, WebEx can be integrated with Skype for business. WebEx Meetings and Microsoft Teams integration is also possible.

Many customers are interested in video device integration, since Microsoft has changed its video protocols (without backward compatibility, as usual). There are several options. First of all, Cisco has made an agreement with Microsoft about integrating Microsoft Teams and Cisco terminals via CVI (Cloud Video Interop). The second option, already mentioned above, is integrating Microsoft Teams and WebEx Meetings. The last option is integration through CVI, connecting two clouds (WebEx cloud and Microsoft Teams cloud) that have a connector with a transcoder between them. As you plan a meeting, the calendar sends a request to WebEx cloud. On each terminal you can see “One Button to Push”. Click it to join the video conference. The video terminal calls Microsoft Teams, and Microsoft Teams clients can participate in this conference. However, all calls pass through the WebEx cloud before being transferred to Microsoft Teams.

So, what’s the difference between CVI connection and WebRTC (Web Real Time Communications) connection? In the first case, you can only participate in meetings within your company. In the second case, customers can join any Microsoft web conference. However, CVI performs two-sided content transmission, and WebRTC will only pass the information from Microsoft to customers. All devices support CVI, and only modern devices support WebRTC. There are other differences, particularly, the registration procedure.

Concerning the corporate infrastructure integration, you can connect computers and mobile software, use any video terminal to call WebEx, perform a callback to any SIP and video terminal. And, as the speaker has emphasized, you can integrate with any corporate PBX for free. There are also paid services, such as callback and accepting calls from landline numbers.

Finally, new WebEx devices have been presented. The old system has been replaced with a new three-screen system. Two of the screens are for video. Such solution is intended for important negotiations. For the first time, a handy co-working tool for video conferences has been implemented. It was achieved by involving one more camera that is being set up against the video terminal. However, this product is for big meeting rooms. You can also use WebEx cloud service to share your notebook’s content on the board. According to Igor Sukaylo, the hit of 2020 will be the integration of WebEx Room Kit Mini with Samsung Flip TV, which has a special built-in software turning a TV into a full-blown video terminal for collaborative working.

Besides that, another new device has been released: WebEx Room Kit USB. It is basically a light version of Room Kit Mini with no touch pad, just a remote control device. It can be used as an advanced web camera. You can also upgrade it to Room Kit Mini, if need be.

A new Cisco device named WebEx Desk Pro is designed for personal work. Unlike DX80, it is for one or two persons only. It is not a replacement, DX80 is going to remain on sale. WebEx Desk Pro features include wireless access to content, getting and sharing content, and a 27-inch display with 4K resolution. It comes with a USB-C port, which makes it a dock station, and a main monitor with sensor routing options. There are also a command mode (in English only), sensor routing to Windows PCs, auto crop and background replacement.

This solution can be used as a web camera as well as a remote collaborative working tool, e.g., for telemedicine.

Cisco Finesse Basic Features: Operator / Supervisor Web App

In this article we’ll describe the most important features of Cisco Finesse agent & supervisor workspace. This software was designed to work with the “hearts” of UCCX and UCCE-based contact centers.

Connecting to Extension Mobility

To access Extension Mobility from a phone:

  • Click Services button;
  • Enter your User ID and PIN;
  • Confirm.

The phone will be restarted and will get a new profile and number. Similarly, you can log off.

Launching Finesse Agent App

  • Launch a compatible web browser;
  • Enter the URL of your Finesse application;
  • On the authorization page, enter:
    • ID – the agent’s ID;
    • Password;
    • Extension – the agent’s phone number;

  • Sign in.

That’s it. If you need to log off, you should change your status to “Not ready”, “End of shift” or similar status indicating the end of work. Then click “Sign Out” in the upper right corner.

Finesse Manager Interface

Finesse Agent Interface

The queue statistics shows the number of incoming calls waiting in the contact center’s queue. This section also shows the longest waiting time.

The Team summary report section shows other agents, their status and unavailability reason as a numeric code.

Agent Statuses

This is relatively simple. If an agent is not ready, the status looks like this (red indicator):

If an agent is ready to work, the indicator is greed .

Changing Agent’s Status

As you could have already noticed, the agent’s status has a dropdown list. You can select any of the ready/busy statuses:

Answering a Call

First of all, your status must be “ready”. After a call comes to your desktop, your status automatically changes to “reserved”. The Call Status area (see the Finesse Agent Interface screenshot above) widens and shows different call options. To answer a call, click the Answer button. It is green.

Call Processing in Finesse

During a conversation with a client, an agent can see the following:

Call Transfer

To transfer a call:

  • Click the Consult button (shown on the screenshot above);
  • Enter the extension number;
  • Talk to the addressee. If they are ready to accept the call, click Transfer.

Conference

To create a conference:

  • Click the Consult button;
  • Enter the number;
  • Click Call;
  • Talk to the contact. If they are ready, click Conference.

Outgoing Calls

To make an outgoing call from Cisco Finesse:/

  • Set your status to Not Ready to stop accepting incoming calls;
  • Click Make a New Call.

  • Select the addressee in your contact list or use the key pad to enter a number:

  • Click Call;
  • To end the call, click End.

Cisco Unified Intelligence Center

Reports are important, aren’t they? Especially, in a major contact center, with thousands of operators working and SLA control being a crucial business aspect.

In this article, we'll discuss the features, architecture and specific terms of Cisco Unified Intelligence Center (CUIC).

What for?

CUIC can work with historical data and real-time data. You can install it at a standalone server, or deploy it in a cluster using up to 8 servers.

In CUIC, you can add different reports, including customized ones, modify the repots’ presentation, create diagrams, charts, permalinks, dashboards and use many other features.

Architecture

In terms of high-level architecture, CUIC works like this:

1. A user (supervisor) requests report generation in CUIC via a web browser;
2. The request is being processed by a web server in Unified Intelligence Center cluster;
3. Data is parsed through a Data Source;
4. The data source presents real-time or historical reports from UCCE or CVP reporting server.

You can also connect CUIC to UCCX data.

When you configure the connection to UCCE (CUIC has a separate Data Sources configuration section), you enter AWDB (Administrative Workstation DB) server connection parameters. This is, basically, a SQL connection on port 1433 (unless you have changed it).

As we have already mentioned, CUIC is basically a data visualizer for DB sources. The initial setup includes configuring data sources.

Now let’s look at the interface.

What does it look like?

The authorization form is pretty standard:

We have already mentioned Data Source creation form. Here it is:

This is simply a DB connection.

Reporting. On the screenshot below, you can see the system dashboard. Please note that there are reports, notes (they can be used to pin important data), frames for important web resources:

CUIC, as of Version 12

In version 12, Cisco has improved the interfaces of its contact center products. Finesse agent desktop interface has also been modified. Please look at the previous screenshot once again. Now you can see the changes in CUIC user interface:

Cisco Packet Tracer Download and Installation Guide

Cisco Packet Tracer is a software tool for network simulation. You can use it to design both simple and relatively complex network topologies. You can also configure virtual machines, routers, commutators and other network devices to check network topologies in Packet Tracer.

Cisco Packet Tracer can also simulate wireless networks, VoIP networks and many others.

If you aim at Cisco certification (e.g. CCENT, CCNA, etc.), you can use Cisco Packet Tracer to configure Cisco network devices (such as commutators and routers) via Cisco IOS.

Cisco Packet Tracer is free to download. All you need is registration to Cisco Network Academy. You can create a Cisco Network Academy account for free.

In Packet Tracer 7, a user authentication feature has been introduced. A Network Academy user must log in at the first launch of Packet Tracer. Unregistered users can save their topologies three times only. However, they can use a guest access button to sign up for a free self-education course "Introduction to Packet Tracer" and get a netacad.com account with full access to Packet Tracer. "Introduction to Packet Tracer" course will help you to familiarize yourself with basic Packet Tracer features.

To create a Cisco Network Academy account, proceed to https://www.netacad.com/courses/packet-tracer/introduction-packet-tracer and see the following page. Click Sigh up today! to download Packet Tracer.

Select English in the dropdown menu. Fill in the form and click Submit.

After you sign up and confirm your account, proceed to https://www.netacad.com/ to the following page. Click Log In -> Login.

After you log in, click Resource -> Download Packet Tracer in the menu.

On this page, select and download the required version (for Windows, Linux, MacOS, Android or iOS).

Install and run. Use you netacad account to sign in upon the first launch. To sign in without an account, click Guest Login in the right bottom corner of the screen, wait for the countdown and click Confirm Guest button.

That’s it! Now you can begin.

Cisco Unified Communication Manager. From Unrestricted to Restricted.

Let me share the experience of moving from Unrestricted to Restricted CUCM version. The reasons for migrating were: a possibility to use Cisco Jabber to transfer files through MRA (Mobile and Remote Access), encryption and other security features, and also a solution for the double ringing signal problem during Cisco Jabber calls through MRA to PSTN. According to the compatibility matrix, this problem has arisen because Cisco Expressway were too new (12.6.1) for CUCM (11.0). By the way, CUCM was running in full-fledged production mode, so the migration was risky for business in terms of subsequent normal functioning. This was not an easy process, so having an experienced colleague nearby happened to be helpful.

Cisco doesn’t support rolling up backups from Unrestricted version to Restricted, and updating from Unrestricted to Restricted also isn’t an option, so you’ll have to perform a fresh installation from scratch.

The following entities should be created/deployed step-by-step:

Stage 1

1) DNS records:

A records: cucm01.example.com, cucm02.example.com, cups01.example.com, cups02.example.com
SRV records in internal DNS: _cisco-uds._tcp.example.com, _cuplogin._tcp.example.com

2) Deployment of the new virtual machines.

.

In our case, that have been 11.5 versions of the last CUCM and CUPS releases (2 nodes per cluster).

Note that if Alerting Names of your phone numbers are not in English, you have to install the required language locales, or the names won’t be shown during calls (within a cluster as well as between clusters).

Besides that, we have set the virtual disk to 120Gbytes instead of 80Gbytes to avoid potential problems with overfull partitions.

3) Sending certificate signing requests and uploading certificates to CUCMs and CUP servers.

Use two templates to issue certificates: Web Client and Web Server, or SIP trunks on port 5061 between the new cluster and other Cisco infrastructure won’t work.

4) Import the certificates from the old and new clusters to each other.

a. On each cluster, configure SFTP server to import/export certificates.

b. On each cluster, export all certificates.

c. On each cluster, import all certificates.

d. Click Consolidate.

e. Make sure both clusters’ certificates are in Trust List.

f. Restart Cisco Tomcat service on each cluster.

Stage 2

Export settings and configurations from old CUCM and CUPS servers.

1. Export all cluster settings except Advanced Features section and Enterprise Parameters, Server, Cisco Unified Communications Manager, Cisco Unified Communications Manager Group and Service Parameters.

Download the generated file.

We are migrating a production server, so, even if we copy those settings as well, we’ll get a conflict with ILS, since the same users will have a home cluster. We also don’t need some parameters to be set to the old cluster’s values.

We highly recommend checking the values of Ad Hoc and Meetme conference participant numbers.

2. Export Line Appearance.

Download the file we’ve generated.

Line appearance is responsible for user statuses (On call, on meeting, etc). All users well be “offline” in jabber unless you import these settings.

3. Export contact lists from CUPS.

Users’ own contact lists are stored on CUPS. They should be exported/imported separately, since users’ jabbers are being moved.

Chose "all assigned users in the cluster".

Note that the contact list file formats are slightly different, State field has been added in new CUCM.

Old format:

New format:

You should edit the downloaded file (for instance, in MS Excel). Add State column and fill it with “1” values, or this contact list won’t be imported.

4. On the new CUCM cluster, set a cluster name that’s different from the old one.

5. If needed, change localization parameters in Enterprise Parameters.

6. On the new IMP cluster, change domain and scheme (if they are different), make InterCluster settings same as the old ones.

7. Download jabber-config.xml from the old cluster and upload it to the new one. Restart Cisco TFTP service. (If you are migrating to version 12.5 or higher, this is not necessary, you can configure this file in UC service and link it to Service Profile).

Stage 3

The third stage is highly recommended to be performed outside office hours, so users won’t lose their connection to telephony services.

1. Import everything you’ve exported during the second stage.
2. Remove the old UCM and IMP nodes from Expressways.
3. Disconnect the old CUCM cluster (or change its mode to standalone if Disconnect doesn’t work for some reason) in ILS Configuration section.

4. Configure ILS on the new CUCM cluster.

5. Remove the old CUCM cluster from PLM, add the new CUCM cluster.

6. Change option 150 (or 66, depending on your configuration) on DHCP server to the new CUCM cluster IP address, then Reset and Restart all phones from old cluster. They must register with the new CUCM cluster.

7. On Expressway, add the new UCM and IMP clusters.

8. Edit trunks to other PBXs, replacing the cluster IP addresses.

That’s it!

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/524772/

How to enable video in Cisco UCCX/UCCE

Since Cisco Remote Expert Mobile/Cobrowse solution reached its end-of-sale there is no native app adding video channel to a Cisco-based contact center.

A great alternative is Aurus RichCall for Cisco UCCX/UCCE, which offers a best-in-class support for Cisco environment. There are 3 points of integration - Cisco UCM, Cisco UCCX and Cisco Finesse.

Here is the call flow explaining how we achieved that.

1. A customer initiates an online call

Customer uses a widget embedded into a website.

2. RichCall server makes a SIP call to CUCM

RichCall server uses the preconfigured SIP trunk to make a SIP call to the UCCX CTI port configured in Cisco UCM.

3. UCCX routes the call to an agent

UCCX places the call to one of UCCX queues and routes it to one of the available agents.

4. An agent answers the call

An agent answers the call using his Cisco endpoint. One of UCCX call variables indicates that the incoming call is a video call.

5. RichCall establishes interactive session

RichCall established an interactive video-enabled session. The agent uses RichCall Agent UI embedded in Cisco Finesse for video and web-collaboration with the client.

More about Aurus RichCall for Cisco contact center

Notes on Cisco Meeting Server Setup

In this article I’ll gather some notes and tricks on Cisco Meeting Server setup.

Cisco Meeting Server Web Client

Web Client makes it possible for persons without any client at all (except for web browser) to join a conference. In a room you can get an invitation link and a PIN to be transferred to a meeting participant. However, this feature won’t work immediately after the installation. You have to add callbridge certificate to webbridge’s trusted services. Use the following command:

webbridge trust <CallBridge certificate>

Then you’ll be able to pass links from CMS client to your partners, and they will be able to enter a conference room using just their names.

The clients will see the following form:

And then, the “contents” of the room.

The connections number restriction in Skype for Business

During a regular conference, we faced a restriction to the number of external Skype for Business participants. New participants ended up disconnected before entering the room. After we consulted specialists, we decided to increase the number of CMS registration at S4B servers.

To achieve that, we created 5 AD users for CMS and registered that accounts in Skype for Business. The pattern is username[1-9]. So, if we increase the number of connections up to 5, we have to add 5 users (username1, username2, username3, username4 and username5) and register the corresponding accounts in S4B.

After that, enter the required number of connections in CMS settings.

As you can see on the picture above, we have created 5 users: cms1, cms2 .. cms5. After this simple operation we have never faced restrictions to the number of connections in a room again. We have had up to 25 participants.

Cisco Meeting Server Setup

Cisco Meeting Server is an audio and video conferencing solution. You can join clients from different software products (SIP, Cisco UCM, Skype for Business (Lync), etc.) in a single conference. This article includes some notes based on the results of the work done, with no claim to comprehensiveness.

Cisco Meeting Server Usage Scenario

Our environment includes Skype for Business (S4B) and federations with several external partners. We often have to conduct meetings with many remote participants. S4B can only provide 5 simultaneous video streams in a conference, which is not enough. Cisco Meeting Server (CMS) can bypass that restriction, with additional possibility to adjust the layout of video streams in S4B interface for the clients. Like that, for example:

CMS virtual rooms allow not only to invite participants, but also to add clients that don’t have any compatible software at all, using a WebRTC client or a plain telephone call.

Cisco Meeting Server Installation

CMS can be deployed as a standalone piece of hardware as well as a VM. We used a template to deploy a VM on VMWare ESXi. There is also a Hyper-V template. The deployment process is trivial. The only trick, recommended in CMS documentation, is to set the required number of CPU cores (vCPU).

After the deployment is over, open the server console and log in. The default CMS login/password is admin/admin. The system will prompt you to change the password.

Now you should configure the network parameters. If you have DHCP, you can use ipv4 a command to check the issued address at once.

a” is the name of the first network interface. In CMS, they are named with letters. The next one will be “b”, etc.

You should also save the MAC address from this command’s output. You’ll need it to get a trial or permanent license for CMS.

If DHCP server is unavailable for CMS, you should set an IP address manually. Use the following command:

ipv4 a add x.x.x.x/y z.z.z.z

with x.x.x.x standing for the address, y — the net mask, z.z.z.z — the default gateway. For example:

ipv4 a add 192.168.1.250/24 192.168.1.1

The next step is to configure the DNS server. Use the following command:

dns add forwardzone . y.y.y.y

with y.y.y.y standing for the address of your DNS server with Active Directory zone. The dot means forwarding all requests to the specified server. Use dns command to view the DNS settings.

The network configuration is over. Now you can ping the specified address and log in to CMS via ssh.

CMS Webadmin Configuration

The next step is to configure CMS administration panel. First of all, get an SSL certificate. There are 2 options: to issue a self-signed certificate, or to sign a certificate in your domain certification service (local CA). (You can purchase a certificate as well).

To issue a self-signed certificate, execute the following command:

pki selfsigned webadmin

(webadmin is the name for your key and certificate, you will need it later).

Personally, we decided to issue a certificate signed by a local CA, using a single certificate for all CMS services.

When you are planning a deployment, you have to choose a domain for CMS and host. For example, if domain.com is your domain where S4B is deployed, then it would be better to deploy CMS in a subdomain (e.g. vc.domain.com), so you can configure call routing from S4B to CMS. You should keep this decision in mind while creating a certificate for all services.

The command is:

pki csr onecert CN:cms.vc.domain.com

with onecert standing for the certificate name, CN:cms.vc.domain.com – the CMS host address configured in DNS.

Now you should copy the CSR file to your computer via SSH and issue a certificate for this file. Then upload the resultant certificate with .cer extension to CMS.

Now you can configure webadmin:

webadmin cert onecert.key onecert.cer
webadmin listen a 445
webadmin restart
webadmin enable

We have chosen port 445 because the standard port 443 may be needed later for a webrtc client for guest access.

Now you can access the admin panel using a URL like this one: https://cms.vc.domain.com:445

Cisco Meeting Server License Installation

After you have entered CMS webadmin, you’ll see the following warning:

You have to get and install a license file. Send the previously obtained MAC address to Cisco and wait for an answer with a license file.

Save that file and rename it into cms.lic, then upload it to CMS via an ssh client (e.g. WinSCP).

Now you should configure and run callbridge. You will need a certificate again. We used a single certificate for all services, so the configuration commands looked like this:

callbridge certs onecert.key onecert.cer
callbridge listen a
callbridge restart

If you log in to webadmin now, you’ll see that the warning is gone.

The first part of configuration is done.

Cisco Meeting Server Cluster: Scalability and Resilience deployment with meeting recording - PART 3

In the previous part of this article we’ve described the configuration of database, Call Bridge and XMPP clusters, as well as Web Admin service. We have also connected Call Bridge to XMPP and performed the Web Bridge configuration.

In this part of the article, we’ll finish discussing the details of CMS clustered deployment and configuration.

Call Bridge Groups

By default, CMS may use the available conferencing resources inefficiently.

For example, in a meeting with three participants, all participants may end up being on three different Call Bridges. For these participants to be able to communicate, Call Bridges will automatically create connections between all servers and clients using a single Space, so it will look as though all clients are using the same server. Unfortunately, such conference of 3 participants will take 9 media ports. This is inefficient resource usage. Besides that, when Call Bridge is really overloaded, the default procedure is to go on accepting calls and provide lower-quality service to all Call Bridge subscribers.

These problems can be solved with Call Bridge Group feature. This feature was introduced in Cisco Meeting Server 2.1 and extended to support load balancing for incoming and outgoing calls, Cisco Meeting App (CMA), including WebRTC participants.

There are three load limits to be configured for each Call Bridge:

  • LoadLimit — maximum load value for a Call Bridge. Each platform has a recommended load limit, e.g. 96000 for CMS1000 and 1.25 GHz per virtual CPU for a virtual machine. Different calls require different amount of resources depending on the participant’s resolution and frame rate.
  • NewConferenceLoadLimitBasisPoints (by default, 50% of loadLimit) — maximum server load above which new conferences will be rejected.
  • ExistingConferenceLoadLimitBasisPoints (by default, 80% of loadLimit) — server load value above which new participants trying to join an existing conference will be rejected.

This feature was created for load balancing and call distribution. Other groups, such as TURN servers, Web Bridge servers and recording devices, can also be assigned to Call Bridge Groups, so they can also be grouped correctly for optimal usage. If any of these objects is not assigned to a call group, it is considered available to all servers without any priority.

These parameters can be configured here: cms.example.com:445/api/v1/system/configuration/cluster

For each Call Bridge, set the Call Bridge Group it belongs to.

The first Call Bridge:

The second Call Bridge:

The third Call Bridge:

So, you have configured a Call Bridge Group for better usage of Cisco Meeting Server cluster resources.

Importing Active Directory Users

Web Admin Service has LDAP configuration section, but it doesn’t provide complex configuration parameters, and the information won’t be saved in the clustered database, so you’ll either have to perform the configuration manually on each server via Web interface, or do it through API. Let’s do it through API to save the time.

Use the URL: cms01.example.com:445/api/v1/ldapServers

Create a LDAP Server object with the following parameters:

  • server IP address
  • port number
  • username
  • password
  • secure

Set Secure to true or false depending on the port number: 389 — not secure, 636 — secure.

Map LDAP source parameters to attributes in Cisco Meeting Server:

  • jidMapping
  • nameMapping
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Attribute description

JID is an identifier for CMS login. It will be mapped onto sAMAccountName in LDAP, which is user’s login identifier in Microsoft Active Directory. Note that you should take sAMAccountName and append the domain name conf.pod6.cms.lab. This is the login name for your CMS users.

nameMapping maps the contents of Active Directory displayName field onto CMS user’s name.

coSpaceNameMapping creates CMS Space name based on the displayName field. This attribute along with coSpaceUriMapping is required for each user’s Space creation.

coSpaceUriMapping defines the user’s part of URI, associated with user’s personal Space. Some domains can be configured for dialing into a space. If the user’s part matches this field for one of those domains, the call will be routed into this user’s Space.

coSpaceSecondaryUriMapping defines a second URI to reach the Space. You will use this to add a numeric alias to route calls into the imported user's Space as an alternative to the alphanumeric URI defined in the coSpaceUriMapping parameter.

LDAP server and mapping are configured. Now you should create a LDAP source to bind them together.

Use the URL: cms01.example.com:445/api/v1/ldapSource
Create a LDAP Source object with the following attributes:

  • server
  • mapping
  • baseDn
  • filter

Now the LDAP configuration is over, so you can perform manual synchronization. You can either do it in each server’s Web interface (Active Directory section > Sync now button) or through API using a POST command (URL: cms01.example.com:445/api/v1/ldapSyncs).

Ad Hoc Conferences

What’s that?

In traditional Unified CM telephony, ad-hoc conferencing is a call by which two participants are talking directly to one another when one party (using a device registered to the Unified CM) presses the Conference button, calls a different person, and after talking to that 3rd party, presses the Conference button again to join everyone into a 3-party conference.

What makes this feature different than a scheduled or permanent conference is that an adhoc conference is not simply a SIP call to the CMS. When the conference initiator presses the Conference button the second time to bring everyone into the same meeting, Unified CM must make an API call to CMS to create a conference on the fly, to which all the calls are then transferred. All this happens transparently to the participants.

This means that Unified CM needs to have the API credentials and Web Admin address/port configured, as well as a SIP trunk directly to the CMS server in order to extend the call.

When required, CUCM can then dynamically create a Space on CMS, so that each call can be extended directly to CMS and match an Incoming call rule that targets Spaces.

Integration with CUCM is similar to the described in an earlier article, but this time you must create three CMS trunks and three Conference Bridges, enter three Subject Names in SIP Security Profile, configure Route Group, Route List, Media Resource Group and Media Resource Group List correspondingly, and add some routing rules on Cisco Meeting Server.

SIP Security Profile:

Trunks:

Each trunk looks similarly:

Conference Bridge

Each Conference Bridge looks similarly:

Route Group

Route List

Media Resource Group

Media Resource Group List

Call Routing Rules

Unlike more advanced call management systems (Unified CM or Expressway), CMS only looks at the domain in the SIP Request-URI field. So if the SIP INVITE is destined to sip:user@domain.com, CMS only cares about the domain.com. CMS follows these rules for determining where to route a call:

  • 1. CMS tries to match the SIP domain to those configured on the Incoming call matching rules. Those calls can then be routed to any configured Spaces, logged-in users, internal IVRs, or to look up a conference on a Microsoft Lync / Skype for Business (S4B) integration.
  • 2. If there is no match on the Incoming call matching rules, CMS will try to match a domain configured in the Call forwarding table. If a match is made, the rule can explicitly reject a call or forward a call. At that time, CMS can re-write the domain, which is sometimes useful for calls to Lync domains. You can also choose to pass through the call, meaning that none of the fields will be further modified, or to use the internal CMS dial plan. If there is no match in the Call forwarding rules, the default behavior is to reject the call. Keep in mind that forwarding will still anchor the call at CMS, so you're essentially placing CMS in the middle of the call flow.
  • 3. Only forwarded calls are then subject to the Outbound call rules. These settings define the destinations where to send the calls, the trunk type (whether or not the new call will be Lync or standard SIP), and any transformations that may be performed, if pass-through is not selected in the call forwarding rule.

Here is a log of what’s happening during an Ad Hoc conference:

The Ad Hoc conference itself:

Incoming Call Rules

Configuring Incoming Call Settings is required to be able to receive a call on CMS. As you saw in the LDAP setup, all the users were imported with the domain conf.pod6.cms.lab. So at minimum, you want calls to that domain to target the Spaces. You will also need to set up rules for anything destined to the fully qualified domain name (and potentially even the IP address) of each of the CMS servers. Our external call control, Unified CM, will be configured with SIP trunks targeting each of the CMS servers individually. Depending on whether or not the destination of those SIP trunks is an IP address or the FQDN of the server will determine whether or not the CMS needs to be configured to accept calls destined to its IP address or FQDN.

The domain that has the highest priority Inbound rule is used as the domain for any user's Spaces. When users are synchronized via LDAP, CMS automatically creates Spaces, but only the user part of the URI (the coSpaceUriMapping), say user.space. The @domain part of the full URI is constructed based on this rule. In fact, if you were to log into Web Bridge at this point, you would see the Space URI has no domain. By setting this rule as the highest priority, you are setting the domain for the generated Spaces to conf.example.com.

Outbound Call Rules

To allow for users to make outbound calls to the Unified CM cluster you must configure an Outbound rule. The domain of your Unified CM-registered endpoints, such as Jabber, is example.com. Calls to this domain should be routed as standards-based SIP calls to the Unified CM's call processing nodes. These are cucm-01.example.com as the primary, and cucm-02.example.com as the secondary.

The first rule sets simple call routing between the cluster nodes.

The Local from domain field contains the domain part of a caller’s SIP-URI (the part after the “@” symbol) to be displayed at receiving side. If you leave it empty, then it will be substituted with an IP address of CUCM the call has passed through. This field is required to make callback possible, as it will be impossible to call the SIP-URI name@ip-address.

Calling with a Local from domain set:

Calling without a Local from domain:

Make sure to set the incoming calls to be Encrypted or Unencrypted, because it won’t work with Auto value.

Recording

The CMS Recorder provides the capability to record meetings. It appears to be just another Cisco Meeting Server. Recorder license is needed and must be applied on the CallBridge component, and not on the Recorder server.
The Recorder behaves like an Extensible Messaging and Presence Protocol (XMPP) client, so the XMPP server must be enabled on the server that hosts the Call Bridge.

We have a cluster, so a license must be distributed to all three clustered servers. In your personal area, proceed to licenses and associate (add) MAC addresses for A-interfaces of all CMS nodes.

It should look like this on each server in a cluster.

There are several scenarios of Recorder deployment. We’ll stick to the following:

Before you set Recorder up, make sure you have enough space for the recordings. Here’s a link to a thorough guide to Recording configuration. I’ll make a few important notes for you:

  • It’s best to use the first cluster node’s certificate.
  • The “Recorder unavailable” error may occur if you have specified a wrong certificate in the recorder trust.
  • The recording may fail if the directory you have set for recordings is not a root directory.

Sometimes there’s a need to record a single user’s or Space’s conferences automatically. This requires two Call Profiles:

With disabled recording feature:

And with automatic recording:

Assign the Call Profile with automatic recording to the chosen Space:

If a call profile is explicitly assigned to some Space or Spaces, then this call profile will only be applied to these specific Spaces. However, if it is not assigned to any spaces, it will be applied to the spaces that do not have any call profiles assigned.

Sources:

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/434240/

Cisco Meeting Server Cluster: Scalability and Resilience deployment with meeting recording - PART 2

In the previous part of this article we’ve discussed the basic configuration and certificate installation process.

In this part we’ll continue getting into the details of CMS deployment in a failover cluster.

Database Cluster

You have uploaded all certificates to your CMS servers. Now you can set up and turn the database clustering on for 3 nodes. The first step is to choose one server as a master database node and set it up.

Master Database

The first step of database replication setup is to select the certificates that will be used for the database. Use the following command:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Now configure the interface that will be used for DB clustering:

database cluster localnode a

Now initialize the cluster’s database on the master server:

database cluster initialize

Client Database Nodes

Perform the same actions, but use the following command instead of database cluster initialize:

database cluster join <ip address existing master>

with <ip address existing master> standing for the IP address of CMS server where the cluster was initialized (master server).

Check the database cluster status on all servers:

database cluster status

The same for the third server.

The first server will be the master server; two others will be slave servers.

Web Admin Service

Turn on the Web Administrator service:

webadmin listen a 445

Port 445 has been chosen because port 443 is used for users' access to web client.

Configure the certificate files for Web Admin service:

webadmin certs <keyfile> <certificatefile> <ca bundle>

Enable Web Admin:

webadmin enable

If everything is right, you’ll get SUCCESS lines saying that Web Admin certificates and network have been configured correctly. Use your web browser to make sure that the service is working: enter the Web Admin address, e.g. cms.example.com:445

Call Bridge Cluster

Call Bridge is the only service that is included in every CMS deployment. Call Bridge is the main conferencing tool. It also provides SIP interface, so calls can be routed to or from it, by Cisco Unified CM, for example.

The following commands should be executed on each server with corresponding certificates.

Link certificates with Call Bridge service:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Bind Call Bridge services to the required interface:

callbridge listen a

And restart the service:

callbridge restart

Now, with Call Bridges configured, we can set up Call Bridge clustering. It is different from database or XMPP clustering. Call Bridge Cluster may support from 2 to 8 nodes without any restrictions. It provides redundancy as well as load balancing, so conferences can be actively distributed between Call Bridge servers. CMS has additional features, Call Bridge groups and associated features that can be useful for further management.

Bridge clustering is mostly set up through Web Admin interface.

The following procedure should be performed on each server in the cluster.

1. Proceed to Web Admin: Configuration > Cluster.

2. In Call Bridge identity: enter callbridge[01,02,03] (corresponding to the server name) as a Unique name. You can use any names that are unique for this cluster. They are descriptive, because they indicate the server identifiers (01,02,03).

3. In Clustered Call Bridges: enter your clustered servers’ Web Admin URLs in the Address field: cms[01,02,03].example.com:445. Make sure to specify the port number. You can leave Peer link SIP domain field empty.

4. Add the certificate bundle (file containing all your servers’ certificates) as a trusted certificate for each server’s Call Bridge:

callbridge trust cluster <trusted cluster certificate bundle>

And restart the service:

callbridge restart

So, for each server it should look like this:

XMPP Cluster

In CMS, XMPP service is used to process all registration and authentication for Cisco Meeting Apps (CMA), including CMA WebRTC web client. Call Bridge also functions as XMPP client for authentication purposes, so it should be configured the same way as the other clients. XMPP fault tolerance is a feature that is supported in enterprise environments starting from version 2.1.

The following commands should be executed on each server with corresponding certificates.

Link certificates with XMPP service:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Set the interface to listen:

xmpp listen a

XMPP service needs a unique domain name. It is used for users’ authentication. When users try to log in via CMS application (or a WebRTC client), they enter userID@logindomain. In our case, it is userid@conf.example.com. Why isn’t it just example.com? In this specific deployment we have chosen example.com as the Unified CM domain for Jabber users, so we need another domain for CMS users, so calls from and to CMS can be routed through SIP domains.

Set XMPP domain:

xmpp domain <domain>

Enable XMPP service:

xmpp enable

In XMPP service, you should create a user account for each Call Bridge. These accounts will be used for XMPP registration. You can use any names (they are not related to the unique names you have configured for Call Bridge clustering). You should add 3 call bridges on one XMPP server, and then enter the same authentication data on other clustered XMPP servers, because this configuration won’t be placed into the clustered database. Later we’ll configure each Call Bridge to use that name and secret for XMPP registration.

Now we should configure XMPP service on the first server. There are three Call Bridges: callbridge01, callbridge02 and callbridge03. Each account will get a random secret. Those secrets will be used later on other Call Bridge servers to log in to this XMPP server. Enter the following commands:

xmpp callbridge add callbridge01

xmpp callbridge add callbridge02

xmpp callbridge add callbridge03

Check the result:

xmpp callbridge list

You should get the same picture on other servers after you perform the following actions.

Create identical accounts on two other servers:

xmpp callbridge add-secret callbridge01

xmpp callbridge add-secret callbridge02

xmpp callbridge add-secret callbridge03

Be careful not to put unnecessary spaces in secrets.

So, you should get the following picture on all servers:

Add the certificate bundle (file containing all your servers’ certificates) as a trusted certificate on each clustered server:

xmpp cluster trust <trust bundle>

Enable XMPP cluster mode on each clustered server:

xmpp cluster enable

Initialize XMPP cluster on the first server in the cluster:

xmpp cluster initialize

Join XMPP clusters on other servers:

xmpp cluster join <ip address head xmpp server>

Check the XMPP cluster status on each server:

xmpp status

xmpp cluster status

The first server:

The second server:

The third server:

Connecting Call Bridge to XMPP

Now your XMPP cluster is online. The next step is to configure Call Bridge services to connect to the XMPP cluster. This configuration step should be performed via Web Admin.

On each server you should proceed to Configuration > General and fill the Unique Call Bridge name field with the corresponding names: callbridge[01,02,03]. The Domain is conf.example.com, and secrets can be listed on any server in the cluster:

xmpp callbridge list

Leave the Server address field empty. Call Bridge will search DNS SRV records for _xmpp-component._tcp.conf.example.com to find an available XMPP server. The IP addresses used to connect to XMPP may be different on each server, depending on the values that will be found for _xmpp-component._tcp.conf.example.com for each Call Bridge, which depends on the priority settings for this DNS record.

Now proceed to Status > General to make sure that Call Bridge service has successfully established a connection to XMPP service.

Web Bridge

Enable Web Bridge service on each clustered server:

webbridge listen a:443

Set up the certificates for Web Bridge service:

webbridge certs <keyfile> <certificatefile> <ca bundle>

Web Bridge supports HTTPS. It will redirect HTTP to HTTPS if http-redirect is enabled.

Use the following command to enable it:

webbridge http-redirect enable

Use the following command to make Web Bridge trust the connections from Call Bridge:

webbridge trust <certfile>

with <certfile> standing for the certificate bundle (file containing all your clustered servers’ certificates).

So, you should get the same picture on each server:

Now create a user with appadmin role. You need this user to configure your cluster with settings being applied to each server automatically instead of configuring each server separately.

Use Postman (https://www.postman.com/downloads/) for further configuration.

Choose Basic Auth in the Authorization section.

Set the correct encoding for the commands sent to CMS.

Configure a POST command for Web Bridges with url parameter set to cms.example.com:

Set the required parameters for each WebBridge: guest access, secure entry mode, etc.

So, we have configured database, Call Bridge and XMPP clusters, as well as Web Admin service. We have also connected Call Bridge to XMPP and performed the Web Bridge configuration.

In the last part of the article, we’ll finish discussing the details of CMS clustered deployment and configuration.

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/434240/

Cisco Meeting Server Cluster: Scalability and Resilience deployment with meeting recording - PART 1

In this article, we’ll go into the details of CMS deployment in a failover cluster.

Theoretics

Basically, there are 3 types of CMS deployment:

  • Single Combined with all services running on a single server. In most cases, this deployment type is only applicable for systems with internal clients, or for small environments with scalability and redundancy restrictions not being crucial, or for the situation when CMS only carries out certain functions, such as CUCM special conferences.
    Approximate working scheme:
  • Single Split extends the previous deployment type with a separate server for external access. In outdated deployments this meant having CMS server deployed in DMZ (demilitarized zone) where external clients can access it, and another CMS server in core layer for the local clients. This specific deployment model is being replaced with so-called Single Edge type with Cisco Expressway servers that have (or will have) most firewall bypassing techniques, so clients won’t have to add a separate CMS edge server.
    Approximate working scheme:
  • Scalable and Resilient type includes redundancy for each component, so the system can grow along with your needs up to the maximum capacity, providing redundancy in case of a failure. It also uses Single Edge conception to provide safe external access. This is the type we are going to discuss here. If we know how to deploy this type of cluster, not only will we understand other deployment types, but we also will be able to understand how to create CMS server clusters taking into account the potential requirement increases.

Before we discuss the deployment, we should clarify some basic ideas.

Basic CMS Program Components

  • Database: helps to combine some configurations, such as subscriber groups, user spaces and users. Supports high availability clustering only (one master).
  • Call Bridge: audio and video conferencing service that implements full control and processing of calls and multimedia processes. Supports high availability and scalable clustering.
  • XMPP server: controls registration and authentication for the clients that use Cisco Meeting Application and/or WebRTC (real-time communication, used in browser), and intercomponent signaling. Supports high availability clustering only.
  • Web Bridge: provides WebRTC access for the clients.
  • Load balancer: provides a unified connection point for Cisco Meeting Applications in Single Split mode. It listens on an external interface and port for incoming connections. The load balancer also accepts incoming TLS connections from an XMPP server and transfers incoming TCP connections from external clients. It won’t be used in our scenario.
  • TURN server: provides firewall bypassing technique that allows launching our CMS behind a Firewall or NAT with external clients using Cisco Meeting App or SIP devices. It won’t be used in our scenario.
  • Web Admin: administration interface and API access (for Unified CM special conferences as well).

Configuration Approaches

Unlike most Cisco products, Cisco Meeting Server supports 3 configuration approaches, allowing you to perform any deployment type:

  • Command line interface (CLI), also known as MMP, can be used for initial configuration and certificate management.
  • Web admin: mostly for Call Bridge-related configuration tasks, especially for the configuration of a single non-clustered server.
  • REST API: for the most complicated configuration tasks and for clustered database-related tasks.

Besides that, you can use SFTP protocol for transferring files, including licenses, certificates and logs, to/from your CMS server.

Practice

Cisco deployment guides say in cold print that in the context of databases, a cluster must consist of 3 nodes at least, since the new database Master selection mechanism can only work with an odd number of nodes:

Note: It's recommended to have an odd number of DB cluster nodes as it is important for the master selection and the active failover mechanism. Another reason for this is that the master DB node would be the node that has connections to the most of the DB in the cluster. You can have a maximum of 5 nodes in a DB cluster.

Indeed, as practice shows, 2 cluster nodes are not enough. The master selection snaps into action at the Master reset, and a Slave server becomes Master only after a rebooted server launches. However, if a Master server goes down in a cluster of two servers, then the Slave won’t become a Master. And if the Slave goes down, then the remaining Master will become a Slave, too.

Speaking of XMPP, a cluster should consist of 3 servers, indeed. If you stop XMPP service on the server that has XMPP in Leader status, then XMPP will stay in Follower status on the remaining server, and Call Bridges will be disconnected, because a Call Bridge can only connect to XMPP with Leader status. And this is critical, because no calls will go through.

These deployment guides also show a cluster with a single XMPP server.

In view of the aforementioned, it’s clear: it works in failover mode.

In our case, XMPP server will be running on all three nodes.

Suppose that all three servers are up.

DNS Records

Before we proceed to the servers’ configuration, the following A and SRV DNS records must be created:

Record typeRecordDescription

A

servername-01.example.com
servername-02.example.com
servername-03.example.com
Resolving the name of each server in our cluster into its IP address.
A join.example.com
join.example.com
join.example.com
Three identical records resolved into the corresponding servers’ IP addresses. Users can enter this DNS name in a browser to access a conference from web.

SRV

_xmpp-client._tcp.conf.example.com
_xmpp-client._tcp.conf.example.com
_xmpp-client._tcp.conf.example.com
Three identical records referring to A records: servername-0x.example.com, allowing the servers’ port 5222. Cisco Meeting App clients use these records to find XMPP server.

SRV

_xmpp-component._tcp.conf.example.com
_xmpp-component._tcp.conf.example.com
_xmpp-component._tcp.conf.example.com
Three identical records referring to A records: servername-0x.example.com, allowing the servers’ 5223 port. Call Bridges use these records to detect XMPP server, if it is not defined explicitly.

Note that our DNS records have 2 domains: example.com and conf.example.com. Example.com can be used in URIs by all subscribers of Cisco Unified Communication Manager (which most likely is or will be used in your infrastructure). Or: example.com is the same domain that is used for email addresses. Or: Jabber client on your notebook can have the following URI: user@example.com.

Conf.example.com is the domain to be configured for all Cisco Meeting Server users. The Cisco Meeting Server domain will be conf.example.com, and Jabber users should use user@conf.example.com URI to log it to Cisco Meeting Server.

Basic Configuration

The configuration process will be described for a single server, but it should be performed for each server in a cluster.

QoS

Since CMS produces real-time traffic that is sensitive to delays and packet loss, in most cases it’s recommended to set up quality of service (QoS). CMS supports marking packets with DSCP (differentiated services code points). DSCP-based traffic prioritizing depends on the way the traffic is processed by the network components in your infrastructure. We are going to configure our CMS with typical DSCP prioritizing that is based on best QoS practices.

Enter the following commands on each server:

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

So, all video traffic will be marked with AF41 (DSCP 0x22), all voice traffic will be marked with EF (DSCP 0x2E), other low-latency traffic types, such as SIP and XMPP, will be marked with AF31 (DSCP 0x1A).

Let’s check:

NTP

Not only is network time protocol (NTP) important for providing precise timestamps for the calls, but also for certificate verification.

Use the following command to add your NTP servers:

ntp server add <server>

In our case, there are two of them, so the command will be executed twice.

Let’s check:

Set the time zone for your server.

DNS

Use the following command on CMS to add DNS servers:

dns add forwardzone <domain-name> <server ip>

In our case, there are two of them, so the command will be executed twice.

Let’s check:

Network Interface Configuration

Use the following command to create a network interface:

ipv4 <interface> add <address>/<prefix length> <gateway>

Let’s check:

Hostname

Use the following command to set the hostname:

hostname <name>

Then reboot the system.

The basic configuration is over.

Certificates

Theoretics

Cisco Meeting Server uses an encrypted connection between different components, therefore X.509 certificates are required for all CMS deployments, so servers and services know if they can trust each other.

Each service needs a certificate, but creating a separate certificate for each service may lead to confusion and excessive complexity. Fortunately, we can generate a public and private certificate key pair and then use it for several services. In our case, one and the same certificate will be used for Call Bridge, XMPP server, Web Bridge and Web Admin. So, we only have to create a public/private key pair for each server in a cluster.

Database clustering, however, has special requirements to the certificates, so it needs separate certificates that are different from the other services’ certificates. CMS utilizes a server certificate that is similar to other servers’ certificates, but there also is a client certificate to be used for database connections. Database certificates are used for authentication and encryption both. Instead of providing a username and password to connect a client to the database, it provides a client certificate that is trusted by the server. Each server in a database cluster uses one and the same public/private key pair. So, any server in a cluster can create encrypted data that can be decrypted by any other server that uses the same key pair.

In order for reservation to work properly, a database cluster should consist of three servers at least and five at most, with maximum signal transmission time of 200 ms between any two nodes. This limit is more restrictive than Call Bridge limits, so it usually becomes the limiting factor in geographically distributed deployments.

CMS database role has several specific requirements. Unlike other roles, it requires client and server certificates, with client certificate having the CN field specified to be presented to the server.

CMS uses postgres database with one main server and several identical replications. Every single moment there is only one main database (“database server”). Other nodes are replications or “database clients”.

A database cluster requires a dedicated server certificate and a client certificate. They must be signed, usually by an internal private CA. Since any node in a database cluster can become the main one, the certificates for database server and client (public/private key pairs) must be copied on each server, so it can become a database client or server. Besides that, the root CA certificate must be uploaded, so the client and server certificates can be verified.

Certificate Requests

So, use the following command to create a certificate request for all server services except database (it will require a separate request):

pki csr hostname CN:cms.example.com
subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

CN should contain the common name of our servers. For example, if the hostnames are: server01, server02, server03, the CN should be server.example.com.

Do the same for both other servers with the corresponding hostnames used in commands.

Create two request for the certificates that will be used by the database service:

pki csr dbclusterserver CN:hostname1.example.com
subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

where dbclusterserver and dbclusterclient are the names of our request and future certificates, and hostname1(2)(3) are the corresponding server names.

Perform this procedure on one server only, and upload the certificates and corresponding .key files to the other servers.

Enable AD CS to Issue “Client and Server” Certificates

Merge Certificates

Merge all servers’ certificates into one file:

In *NIX:

cat server01.cer server02.cer server03.cer > server.cer

In Windows/DOS:

copy server01.cer + server02.cer + server03.cer server.cer

And upload the following files to each server:

  • The server's certificate.
  • Root certificate (with intermediate ones if they exist).
  • Database certificates (“server” and “client” ones) and .key files that have been created upon the request for “server” and “client” database certificates. These are the same files for all servers.
  • All servers’ certificates.

You should get a similar set of files on each server:

In the next part of this article we’ll continue discussing the details of CMS clustered deployment.

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/434240/

CUCM Backup and Recovery via Command Line

Cisco Unified Communications Manager (CUCM) graphic interface has a Disaster Recovery System (DRS) for backup creation and system restore. But sometimes GUI is unavailable, for example, because of network problems. In this case, backup and restore can be performed via CLI. In this article, we’ll tell you how to do that.

Backup Creation

Before this procedure you have to configure a SFTP server to store the CUCM backup there.

First of all, add a server to store the backup. Execute the following command:

utils disaster_recovery device add network [backup_device_name path] [server_name/ip_address] [username] [number_of_backups]

  • backup_device_name – name of the device to store the backup;
  • path – path to the backup on this device;
  • server_name/ip_address – hostname or IP address of the device;
  • username – username to be used to access the server;
  • number of backups – number of backups to be created.

After this command, you’ll be prompted to enter the password for the accessing user (in our case the user is ccmadmin):

admin: utils disaster_recovery device add network backupdevice ./ 10.20.30.123 ccmadmin
Please enter password to connect to network server 10.20.30.123:****
drfCliMsg: Backup Device has been saved successfully.

Use the following command to make sure the backup device has been successfully added:

utils disaster_recovery device list

You should see the device you have added:

admin:utils disaster_recovery device list
Device Name    Device Type    Device Path
--------------------------------------------------------------
backupdevice    NETWORK    ./

Wonderful! Now you can perform the backup. Use the following command:

utils disaster_recovery backup network [featurelist] [path] [backup_device_name] [username]

  • backup_device_name – the hostname or IP address of the device where the backup will be stored;
  • username – username to be used to access the server;
  • featurelist – the list of features for the copy;
  • path – path to the archive.

To show the list of features available for backup, use the following command:

utils disaster_recovery show_registration [servername],

where servername specifies the server for which you want to display the information.

admin:utils disaster_recovery backup network UCM,CDR_CAR,PLM backupdevice
drfCliMsg: Backup initiated successfully. Please run 'utils disaster_recovery status backup' command to see the status

Done! To check the backup status, enter:

utils disaster_recovery status backup

admin:utils disaster_recovery status backup

Status: SUCCESS :Backup Completed...
Tar Filename: 2019-10-12-04-21-37.tar
Storage Location: NETWORK
Operation: backup
Percentage Complete: 100
PLM CCM01 ELM-AGENT SUCCESS Sat Oct 12 04:17:25 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_plm_elm-agent.log
PLM CCM01 ELM-SERVER SUCCESS Sat Oct 12 04:17:26 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_plm_elm-server.log
CDR_CAR CCM01 CAR SUCCESS Sat Oct 12 04:17:27 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_cdr_car_car.log
UCM CCM01 BAT SUCCESS Sat Oct 12 04:19:23 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_bat.log
UCM CCM01 CCMPREFS SUCCESS Sat Oct 12 04:19:25 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_ccmprefs.log
UCM CCM01 PLATFORM SUCCESS Sat Oct 12 04:19:30 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_platform.log
UCM CCM01 TCT SUCCESS Sat Oct 12 04:19:34 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_tct.log
UCM CCM01 SYSLOGAGT SUCCESS Sat Oct 12 04:19:35 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_syslogagt.log
UCM CCM01 CDPAGT SUCCESS Sat Oct 12 04:19:36 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_CCM01_ucm_cdpagt.log
UCM CCM01 CLM SUCCESS Sat Oct 12 04:19:37 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_clm.log
UCM CCM01 CCMDB SUCCESS Sat Oct 12 04:19:37 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_ccmdb.log
UCM CCM01 TFTP SUCCESS Sat Oct 12 04:21:37 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_tftp.log
UCM CCM01 ANN SUCCESS Sat Oct 12 04:21:33 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ ccm01_ucm_ann.log
UCM CCM01 MOH SUCCESS Sat Oct 12 04:21:34 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_b_ccm01_ucm_moh.log

That's it, the backup is ready!

Recovery Procedure

To recover CUCM configuration from a backup, first of all, check the backup files available of the remote server:

admin:utils disaster_recovery show_backupfiles backupdevice
2019-10-12-04-21-37
2018-12-25-21-52-19

Select the required backup and enter the following command:

admin:utils disaster_recovery restore network 10.20.30.123 2019-10-12-04-21-37 backupdevice
drfCliMsg: WARNING! There are nodes in current production cluster but NOT present in the backup. These nodes will be removed if you restore the Publisher. If you want to keep these nodes, you will need to manually re-add them after the restore.
Do you want DRS to perform a SHA-1 File Integrity Check of your backup archives y/n ?(n) : y
Please enter the comma seperated features you wish to restore. Valid features for server CCM01 are PLM,CDR_CAR,UCM:PLM,CDR_CAR,UCM
Do you want to restore database from the subscriber y/n ?(n) : n
drfCliMsg: Restore initiated successfully. Please run 'utils disaster_recovery status restore' command to see the status
ALERT: Please restart the server(s) before performing the next restore for changes to take effect. In case of a cluster, restart the entire cluster.

Now check the recovery status:

admin:utils disaster_recovery status restore

Status: SUCCESS :Restore Completed...
Tar Filename: 2019-10-12-04-21-37.tar
Storage Location: NETWORK
Operation: restore
Percentage Complete: 100
CDR_CAR CCM01 CAR SUCCESS Sun Oct 13 11:20:15 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_cdr_car_car.log
PLM CCM01 ELM-AGENT SUCCESS Sun Oct 13 11:24:34 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_plm_elm-agent.log
PLM CCM01 ELM-SERVER SUCCESS Sun Oct 13 11:24:34 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_plm_elm-server.log
UCM CCM01 BAT SUCCESS Sun Oct 13 11:25:06 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_ucm_bat.log
UCM CCM01 CCMPREFS SUCCESS Sun Oct 13 11:37:06 CEST 2019 activelog/platform/drf/log/2019-10-12-15-20-01_r_ccm01_ucm_ccmprefs.log
UCM CCM01 PLATFORM SUCCESS Sun Oct 13 11:37:13 CEST 2019 activelog/platform/drf/log/2019-10-12-15-20-01_r_ccm01_ucm_platform.log
UCM CCM01 TCT SUCCESS Sun Oct 13 12:11:10 CEST 2019 activelog/platform/drf/log/2019-10-12-15-20-01_r_ccm01_ucm_tct.log
UCM CCM01 SYSLOGAGT SUCCESS Sun Oct 13 12:14:19 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_ucm_syslogagt.log
UCM CCM01 CDPAGT SUCCESS Sun Oct 13 12:14:39 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_ucm_cdpagt.log
UCM CCM01 CLM SUCCESS Sun Oct 13 12:17:03 CEST 2019 activelog/platform/drf/log/2019-10-12-04-21-37_r_ccm01_ucm_clm.log
UCM CCM01 CCMDB SUCCESS Sun Oct 13 12:17:05 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ccmdb.log
UCM CCM01 TFTP SUCCESS Sun Oct 13 12:25:12 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_tftp.log
UCM CCM01 ANN SUCCESS Sun Oct 13 12:26:38 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ann.log
UCM CCM01 MOH SUCCESS Sun Oct 13 12:26:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_moh.log

What are you missing in Cisco Meeting Server?

This post is to list some of the gaps of Cisco Meeting Server highlighted by our customers migrating from Cisco TelePresence Server to Meeting Server and partners who deploy Cisco videoconferencing solutions. 


1) UI to configure users and spaces
As you know most of the configuration options are only available via CMS API 

2) Camera snapshots in conference control
The Cisco Meeting Manager tool does not provide camera snapshots. See CMM 2.6 user guide for video operators for more.

3) Monitoring and reporting tool
CMS servers provide API and CDR records but no native reporting tool is available.

4) Lecture mode with hand raising
There used to be a native lecture more for Telepresence Server conferences. Though there are guides about how to configure it with API (see https://kb.acano.com/content/9/68/en/how-do-i-set-up-%E2%80%9Clecture-mode%E2%80%9D.html) the hand raising feature is missing.

5) UI to access meeting recordings
CMS can record meetings (special license is required) but it only stores recording on a NFS. No interface to play recordings, manage access rights etc.

6) Ad-hoc meetings with automatic dial-out
Lots of clients want to start a meeting with a push of a button and have a predefined list of participants to be dialed and joined automatically.

7) Streaming Server
CMS meetings can be streamed to a predefined IP, but you have to deploy some 3rd party media streaming engine to capture it and broadcast to users.

If you feel something major is missing in this list, please give us a shout.

Integration of Cisco Meeting Server with CUCM 11 – PART 3


The last part is about SIP trunking, сonference bridge, route patterns and users.

SIP trunk security profile

Now create a SIP trunk security profile.

If the calls won’t be encrypted, select the values specified below. Enter Call Bridge certificate CN (your CMS server FQDN).

Check Accept Replaces Header if you are going to use conference call bridges.

Conference Bridge

Create a Conference Bridge as described below. Enter username and password of the user with appadmin role (we have created this user in the very beginning).

Create a Media Resource Group and add your Conference Bridge there.

Create Media Resource Group List and add your Media Resource Group there.

Proceed to Standard SIP Profile For TelePresence Conferencing and make sure that Allow iX Application Media, Use Fully Qualified Domain Name in SIP Requests, and Allow Presentation Sharing use BFCP options are checked.

SIP Trunk

Now create a SIP Trunk to CMS server.

You should set the correct Calling Search Space, so calls will be successful. Otherwise, CMS won’t be able to find the required phone number. Both the device and the phone number have to be added to the Calling Search Space.

Media Resource Group List — select the one you have created.

SRTP Allowed flag allows encrypted calls. You can disable it.

SIP Information > Destination address — enter your CMS FQDN or IP address.
SIP Information > Destination Port — standard SIP port is 5060, 5061 is for encrypted calls.
SIP Trunk Security Profile — select the one you have created.
SIP Profile — select Standard SIP Profile For TelePresence Conferencing
Normalization Script — don’t set. It is only needed for encrypted calls. Set cisco-telepresence-conductor-interop if you are using encryption.

Pay attention to the green marked parameters. You should gain an understanding of Calling Search Spaces to fill them correctly.

Leave other fields with default values.

SIP Route Pattern

Create a SIP Route Pattern for calls to SIP addresses like smith.j@example.com

Check CMS and CUCM:

The trunk is up.

However, the Conference Bridge is down due to the difference in TLS versions on CUCM and CMS. This issue can be solved by TLS 1.0 installation on CMS:

tls webadmin min-tls-version 1.0
webadmin restart

Check the Conference Bridge:

Our configuration is being performed on trunks without Media Termination Point (MTP).
Disable MTP if it won’t affect your services.

Disbling MTP can affect your services if your phones use SCCP protocol and you have to send DTMS to CMS.

If this is true for your services, you may have to increase MTP capacity on CUCM depending on the number of simultaneous calls.

Importing Active Directory Users

Now import the users from Active Directory.

Proceed to Configuration -> Active Directory, fill out the fields (see the figure below).

Filter is a very important field. You can enter your own filter or use the filter shown on the picture.

Look through the logs.

Everything is right.

Proceed to Status -> Users to make sure that all users have been imported.

Availability check

We got to the best part.

To perform a call, access the web interface: cms.example.com
Enter an Active Directory user login and password to log in.

Now let’s check a video call from an IP Phone (we are using Cisco E20) to our user account.

I have web and desktop Cisco Meeting clients running, and both are calling.

You can also test the video call from your user account to IP Phone. In our case, the video call was successful in both directions.

Encrypted calls can bring in some complications, but that’s a story for another day.

See also:

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/433528/

Integration of Cisco Meeting Server with CUCM 11 – PART 2


Part 2 explains call settings, Incoming and Outbound calls configuration, spaces and CUCM certificates

Basic Call Settings Configuration

Proceed to Configuration > Call settings and set the values as given below:

Incoming Call Handling Configuration

Proceed to Configuration > Incoming calls and set the values as specified below:

This configuration determines the way of incoming SIP calls handling on CMS. Any call routed to CMS will have a verified alias. The rules in call matching table determine where CMS will look for potential matches. Each rule can be set to match any combination of users, IVR or MicrosoftSkype / Lync. To handle incoming calls, Cisco Meeting Server tries to match the value after "@" sign with the values in “domain name” column.

Outbound Call Handling Configuration

Proceed to Configuration > Outbound calls.
Domain name: leave empty (to match all domains)
SIP Proxy to use: enter your CUCM FQDN (IP address is admissible, but FQDN is recommended)
Local contact domain: leave empty, it is only needed for Skype for Business SIP Trunk configuration.
Local from domain: enter Cisco Meeting Server SIP domain (e.g. cms.example.com)
Trunk type: Standard SIP
Behavior: Continue
Priority: 1
Encryption: Auto or Unencrypted
Click Add New to save the changes.

Space Creation

Create a space where the users will be stored.

Proceed to Configuration > Spaces

The Secondary URI should be a E.164 value compatible with your dial plan that will be routed to CMS. The CallID can be any number that is not used yet. In this example we use the same value as for Secondary URI.

Configure Web Bridge for Call Bridge

To allow guest access to Web Bridge, configure Call Bridge to set Web Bridge address.

Proceed to Configuration > General

Configure a HTTPS CMS URL address for a guest account. For example:
meetingserver.example.com

Fill External Access field if you want to add Cisco Expressway web proxy. This address will be used in invites for external users.

CUCM Certificates

Perform the requests for Tomcat (CUCM web server) and CallManager services.
Proceed to Cisco Unified OS Administration > Security-Certificate Management and click Generate CSR.

First, select Tomcat in the Certificate Purpose field, so you won’t get errors in your browser.

Click Generate.

Then select CallManager, so CMS and CUCM will check each other’s certificates for Conference Bridge registration.

Click Generate.

Now download the certificate signing request files for CA.


Upload root and intermediate certificates for Tomcat-trust and CallManager-trust, either one by one (root certificate first) or as a single file (as described above).

Click Upload.

Upload the CA certificate files formed upon your request.

Now restart Cisco Tomcat, Cisco CallManager and Cisco TFTP services.

Restart Cisco Tomcat from the command line.

The other ones can be restarted from web interface.


Click Restart and wait for the services to be restarted.

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/433528/

Integration of Cisco Meeting Server with CUCM 11 – PART 1


The first part covers network settings, CMS License and Certificates, Call Bridge, Web admin, XMPP, Web Bridge.

This article is about CMS (Cisco Meeting Server) and its integration with CUCM (Cisco Unified Communications Manager).

Suppose that CMS and CUCM have already been deployed on virtual machines.

Before the configuration, make the following preparations:

  • Create a DNS record for CMS IP address with an alias to be used by end users. For example:
    meetingserver.example.com
  • XMPP Domain Name: the name that will be used to log in to Cisco Meeting App. In our case, it will be the user’s sAMAccountName, imported from Active Directory.
  • To support Cisco Meeting App users, add a DNS SRV record for XMPP domain name. SRV record for _xmpp-client._tcp.<xmpp domain> needs TCP port 5222.
  • Note: you don’t need this if you use the desktop application only.
    SIP domain for the meeting server.

Suppose you are using a sub-domen, for example, meet.example.com.

IP address, mask, gateway, DNS, NTP, new user

First of all, enter the valid IP address of your service (CMS has several interfaces, select the first one: "a";).

Add DNS addresses for your zone (if needed). Use "dns" command to check the configuration.

Set CMS hostname and reboot.

It’s recommended to create separate administrator accounts for safety purposes. «Admin» account is not safe enough. Besides that, it’s recommended to have 2 administrator accounts in case you lose one of the administrator passwords. In this situation, you’ll still be able to log in as the second administrator and reset the lost password.

Username: «root», role: «admin».

Getting ahead of it, create another user with role "appadmin", so CUCM will be able to configure CMS on application level via Web Admin interface (i.e. for Conference Bridge registration).

Now set your NTP server and timezone and reboot.

CMS License and Certificates

Now you have to form a request for CMS certificates.

Cisco Meeting Server services use x.509 certificates for TLS connections and for some authentication purposes. In our case, the certificate is needed for Call Bridge, XMPP, Web Bridge and Web Admin services. Certificates can be self-signed or signed by internal or external CA.

Self-signed certificate is admissible, but not recommended, as it causes errors on web pages and prevents registering CMS Conference Bridge on CUCM.

Generate a request:

pki csr Cert CN:example.com subjectAltName:callbridge.example.com,xmpp.example.com,webbridge.example.com

Since we are using one certificate for all services, AltName should contain this services’ names.

Download, install and run WinSCP to get your request file and to put the license file on your CMS server.

To get the license (a 90-days demo version), apply to some Cisco partner and piteously ask for a demo license for education or demonstration purposes, or buy a full license and add your interface MAC address to your piteous letter.

Get the MAC address with the following command: "iface a"

Suppose you get lucky and obtain the license file with .lic extension. Rename it to "cms.lic"

Now run WinSCP. Create a connection to CMS.

Connect:

Save cms.lic and Cert.csr to CMS.

To create a full chain certificate file (because our CMS won’t use .p7b file), do the following:

In a command line:

a. In UNIX OS: cat “intermediate certificate 1” “intermediate certificate 2” “intermediate certificate 3” “root certificate” > ca-bundle

b. In Windows/DOS: copy “intermediate certificate 1” + “intermediate certificate 2” + “intermediate certificate 3” + “root certificate” ca-bundle

Use WinSCP to load the resultant file and the CMS certificate file to CMS.

Reboot, check the license:

Call Bridge, Web admin, XMPP, Web Bridge

Call Bridge

Configure Call Bridge to listen on a interface:

callbridge listen a

Configure Call Bridge to use the certificate, key and CA bundle files:

callbridge certs <keyfile> <certificatefile> <ca bundle>

Restart callbridge:

callbridge restart

Web Admin

Setup Web Admin service:

webadmin listen a 445

Port 445 has been chosen because 443 is already used for web access.
Configure the certificate files for Web Admin service:

webadmin certs <keyfile> <certificatefile> <ca bundle>

And turn it on:

webadmin enable

If everything is right, you'll get SUCCESS messages telling about Web Admin certificate and network parameters being correctly configured. To check if the service is available, enter the web administrator address in your web browser, for example: cms.example.com:445

XMPP

Setup XMPP service:

xmpp listen a

Configure the certificate files for XMPP service:

xmpp certs <keyfile> <certificatefile> <ca bundle>

Set XMPP deployment domain:

xmpp domain <domain name>

Turn the service on:

xmpp enable

Check CMS and CUCM:

Add Call Bridge to XMPP server:

xmpp callbridge add

Copy the Secret and paste it to XMPP server settings, configure the other parameters (see the figure below)

Web Bridge

Setup Web Bridge service:

webbridge listen a:443

Configure the certificate files for Web Bridge service:

webbridge certs <keyfile> <certificatefile> <ca bundle>>

Web Bridge supports HTTPS. If it is configured to use httpredirect, then HTTP will be redirected to HTTPS. To enable HTTP redirection, use the following command:

webbridge http-redirect enable

Use the following command to make Web Bridge trust Call Bridge connections with the certificate previously issued by a certification center:

webbridge trust <certfile>

Read also:

This article is a translation of a guide originally created by S. Dubinin, Telecommunications Specialist - https://habr.com/ru/post/433528/

Is Cisco going to discontinue all its software communication tools except Webex Teams?

1. Cisco Jabber transforms to Teams.

With Cisco Jabber 12.7 release Cisco announced the "Modern Design view" which mirrors the look and feel of Webex Teams user interface.

They say the strategy is to unify its collaboration portfolio to simplify the experience for users and IT administrators.

Ok, but at the same time...

2. Webex Teams App is now available for on-prem deployments with Cisco UCM

The new "Calling in Webex Teams" solution lets you register Webex Teams to the on-prem Cisco UCM (Enterprise, BE 6000/7000, or HCS partner solution).

Here are the details - https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cloudCollaboration/wbxt/ucmcalling/unified-cm-wbx-teams-deployment-guide/unified-cm-wbx-teams-deployment-guide_chapter_01.html

Will it just replace Cisco Jabber in couple of years?

3. Webex Teams and Webex Meetings are getting merged

Until recently Webex Teams and Webex Meetings were separate products relying on different cloud platforms.

Now Cisco brings them closer together - https://searchunifiedcommunications.techtarget.com/news/252465007/Cisco-unifies-Webex-calling-messaging-and-meetings

4. Cisco IP communicator, my love, reaches its end of life

And even more... The end-of-sale and end-of-life dates are announced for Cisco IP Communicator.

5. Is Cisco Meeting App next?

Now rumors are that Cisco Meeting App which is the software endpoint for Cisco Meeting Server is also going away soon.

If this is really going to happen, guess what will the replacement be?

CUCM SIP CUBE: Manipulations with INVITE Field

Some SIP providers prefer to work with INVITE field, while CISCO CUBE traditionally works with From: and To: fields.

Let’s take MSN provider as an example.

An incoming call header looks like this:

In this case, login is 48879800, and it is contained in INVITE field only.

Cisco translation-profile and translation-rule can only operate with numbers, and the complex header in To: field complicates the situation.

You can use sip-profiles to copy the number from INVITE field to To: field.

The structure should be the following:

voice service voip
  sip
    sip-profiles inbound
!
voice class sip-profiles 10
    request INVITE sip-header SIP-Req-URI copy "sip:(.*)@" u01
    request INVITE sip-header To modify ".*@(.*)" "To: voice translation-rule 10
  rule 1 /^48879800$/ /1401/
!
voice translation-rule 20
  rule 1 /^8\(..........$\)/ /+7\1/
!
!
voice translation-profile ITSP_Incoming
  translate calling 20
  translate called 10
!
dial-peer voice 1 voip
  description incoming from MCN-1
  translation-profile incoming ITSP_Incoming
  session protocol sipv2
  session target sip-server
  incoming called-number 48879800
  voice-class codec 1
  voice-class sip profiles 10 inbound
  voice-class sip bind control source-interface GigabitEthernet0/0/0.300
  voice-class sip bind media source-interface GigabitEthernet0/0/0.300
  dtmf-relay rtp-nte digit-drop
  no vad
!
dial-peer voice 500115 voip
  description To CUCM
  preference 5
  destination-pattern 48879800
  session protocol sipv2
  session target ipv4:10.7.20.251
  voice-class codec 1
  voice-class sip bind control source-interface GigabitEthernet0/0/1.200
  voice-class sip bind media source-interface GigabitEthernet0/0/1.200
  dtmf-relay rtp-nte digit-drop
  ip qos dscp cs3 signaling
  no vad
!

Then the number 48879800 can be sent to CUCM.

In the end, the call will look like this:

CUCM DRS Management Using Command Line

Command Line Recovery

Hello! In a recent article we have shown you how to create a backup for Cisco Unified Communications Manager (CUCM) using Disaster Recovery System (DRS). Today we'll discuss backup and recovery in command line interface (CLI) that can be used when it’s impossible to use graphical interface.

Backup Creation

First of all, select the device to store the backup (SFTP server). Execute the following command:

utils disaster_recovery device add network [devicename path] [server_name/ip_address] [username] [number_of_backups]

  • devicename – name of the device to store the backup;
  • path – path to the backup;
  • server_name/ip_address – hostname or IP address of the device where the backup will be stored;
  • username – username to be used to access the server;
  • number_of_backups – number of backups to be created (optional). The default value is 2;

Example:

admin: utils disaster_recovery device add network networkDevice /root 192.168.1.1 root 3

The following command shows the list of devices:

utils disaster_recovery device list

Now create a backup copy:

utils disaster_recovery backup network [featurelist] [path] [servername] [username]

  • featurelist – the list of features for the copy, separated by comma;
  • path – path to the archive;
  • servername – the hostname or IP address of the device where the archive will be stored;
  • username – username to be used to access the server;

The following command shows the feature list:

utils disaster_recovery show_registration

Check the backup status:

utils disaster_recovery status backup

Recovery

First of all, check whether there are backup files on SFTP server:

utils disaster_recovery show_backupfiles [name]

  • name – the name of backup device;

Select a backup file from the list:

utils disaster_recovery restore network [restore_server] [tarfilename] [devicename]

  • restore_server – the hostname or IP address of the device where the archive will be stored;
  • tarfilename – backup file name;
  • devicename – the name of backup device;

Example:

utils disaster_recovery restore network 192.168.1.1 2019-05-15-15-35-28 networkDevice

When asked if you really want to restore the system, say “y”.

Now check the system recovery status:

utils disaster_recovery status restore

Integrating Cisco UCCX with a Database Using a Script

If you have UCCX (Cisco Unified Contact Center Express) premium license, one of the best features is possible integration and requests to database. These requests can use any information provided by the caller, or the caller’s number, etc.

It’s very important to create a reasonable initial script design and to take the server load into account. Big and heavy scripts with many database handles increase the load greatly. If the DB is on a remote server and there is a net lag, it may influence your business and the calling client's loyalty.

CISCO UNIFIED CCX SCRIPT EDITOR Review

There is a special tool in UCCX to create and manage IVR scripts: Cisco Unified CCX Editor. Here you can manage visual blocks responsible for this or that action. It looks like this:

Let’s look at the Database section. It has 4 items:

  • DB Get – map the data from DB to the script variables;
  • DB Read – connect to the server and send a request;
  • DB Release – close the connection with DB;
  • DB Write – use Write method if changes in DB are required;

On the screenshot above, you can see that each script begins with Start event and ends with End event. As the script is being executed during a call, we can perform as many DB requests as we need. Each request has its own sequence of steps that are listed above.

We recommend you to test all SQL requests, access to the system and other factors before releasing to the enterprise environment.

As an example, let's look into DB Read block:

These fields are available for configuration:

  • DB Resource Name – marker of the request;
  • Data Source Name – data source specified in UCCX console (Cisco Unified CCX Administration Database);
  • Timeout (in sec) – request execution timeout. This timeout protects your system from database disconnection. If you set it to 0, the request won’t have any time limitations;

Now proceed from General tab to Field Selection:

  • Write the SQL request you want to execute. For example: SELECT fld1, fld2 from tbl where fld1 = $variable – select two fields from the table, where the first field’s value is equal to a variable that we have initialized earlier in our script.
  • Test (button) – click this button to check the request syntax and the database connection;
  • Number of rows returned – number or rows returned by the request after the Test button was clicked;
  • Show all fields (select table/view) – show all fields of the used tables;

Now let’s look into DB Get block:

  • DB Resource Name – label or name of this request;
  • Data Source Name – database name (configured in Cisco Unified CCX Administration panel);
  • Refresh Database Schema (button) – click this button to load database data and tables to CCX Editor;

Proceed to Field Selection tab:

  • Table/View – name of the DB table that was selected on General tab (see above);
  • Table fields:
  • Field Name – field name in the selected table;
  • Data Type – data type (string/number, etc.);
  • Local Variable – script variable that will store the corresponding field value;
  • Add/Modify (buttons) – buttons responsible for field modification (except for data type, which is read-only);

The obtained data can be used in the script, for example, to vocalize (using TTS) the client’s phone number or the entered digits (e.g. order number).

Deprecated Cisco IP Phones in CUCM 14

Remember this mess with several tens of Cisco IP phones available on the market (not counting video endpoints)?
There were:

  • old-school 7900 series,
  • intermediate 6900, 8900 and 9900 models,
  • newly introduced 7800 and 8800 IP phones,
  • finally some experiments like 3905, Android-based DX650 etc

So these times are over.

For the past couple of year Cisco step by step cleaned up the IP phones portfolio: In Cisco Unified Communications Manager 11.5 they deprecated 7902, 7905, 7910, 7912, 7920, Conference Station 7935.
The following models were deprecated in Cisco UCM 12 - wireless IP Phone 7921, 7970 and 7971.

And now the MAJOR CLEANUP is coming with Cisco Unified Communications Manager, Release 14 affecting CUCM 14, Cisco BE 6000 / 7000.

Just take a look. The phone models to be deprecated in Release 14 are:
- Cisco Unified SIP Phone 3911
- Cisco Unified SIP Phone 3951
- Cisco Unified IP Phone 6911
- Cisco Unified IP Phone 6921
- Cisco Unified IP Phone 6941
- Cisco Unified IP Phone 6945
- Cisco Unified IP Phone 6961
- Cisco Unified IP Phone 7906G
- Cisco Unified IP Phone 7911G
- Cisco Unified Wireless IP Phone 7925
- Cisco Unified Wireless IP Phone 7925G-EX
- Cisco Unified Wireless IP Phone 7926
- Cisco Unified IP Phone 7931
- Cisco Unified IP Conference Station 7936
- Cisco Unified IP Conference Station 7937G
- Cisco Unified IP Phone 7940
- Cisco Unified IP Phone 7941
- Cisco Unified IP Phone 7960
- Cisco Unified IP Phone 7961
- Cisco Unified IP Phone 7985
- Cisco Unified IP Phone 8941

If you are using any of these phone models and you upgrade to Release 14, you will not be able to use these phones after the upgrade.

After you switch over to CUCM 14, registration of these phone models will be blocked.

So, better check the phones you use and plan the migration to 7800 and 8800 series in advance.

Field notice from Cisco - https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/14_0_1/fieldNotices/cucm_b_deprecated-phones-14.html

Enabling Cisco UCM CDR Collection

Yes, CUCM can collect CDR (Call Detail Record). This article will show you how to enable this feature (disabled by default).

Enabling CDR

Open Cisco Unified CM Administration interface:

Proceed to System → Service Parameters and select the following parameters:

  • Server — select the node to be manipulated,
  • Service — select Cisco CallManager (Active).

In the Parameters section that appears, find System and select:

  • CDR Enabled Flag * — True. This parameter indicates the call manager to create and store CDR records for each call passing through this UCM;
  • CDR Log Calls with Zero Duration Flag * — True. Enabling this parameter makes the server save the unsuccessful calls and calls that were shorter than 1 second (helpful for troubleshooting).

Don’t forget to apply the changes. Repeat this actions for each node in a cluster (if you have more than one server in System → Service Parameters → Server menu).

Additional configuration

Now let’s explore advanced parameters. On the configuration toolbar, click Advanced:

Select the following options:

  • Call Diagnostics Enabled – Enabled Only When CDR Enabled Flag is True. This parameter switches on so-called Call Management Records (CMR), which are very helpful for troubleshooting;
  • Display FAC in CDR – True. This parameter indicates whether Forced Authorization Code (FAC) should be displayed in CDR. Generally, this parameter depends on your security policies. We chose to display it;
  • Show Line Group Member DN in finalCalledPartyNumber CDR Field – True. Briefly, this parameter shows DN (directory number) of the group member that answered a call, instead of the group’s number;
  • Show Line Group Member Non Masked DN in finalCalledPartyNumber CDR Field – basically, the same as the previous one.

Open Cisco Unified Serviceability page, proceed to Tools → CDR Analysis and Reporting section. Now you can select CDR tab to use Search or export the data. Enjoy!

CUCM 12.5 and CUBE - media forking to multiple recorders simultaneously

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.

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.

Cisco Meeting Server (CMS) and Skype for Business (Lync) Integration – Basics and Hints

On S4B front-end server, configure a trusted application and routing. Execute the following commands in PowerShell:

  • New-CsTrustedApplicationPool -Identity cms.vc.domain.com -ComputerFqdn cms.vc.domain.com -Registrar S4BFE.domain.com -Site 2 -RequiresReplication $false -ThrottleAsServer $true -TreatAsAuthenticated $true
  • New-CsTrustedApplication -Applicationid cms -TrustedApplicationPoolFqdn cms.vc.domain.com -Port 5061
  • New-CsStaticRoutingConfiguration -Identity "Service:Registrar:S4BFE.domain.com"
  • $route = New-CsStaticRoute -TLSRoute -Destination "cms.vc.domain.com" -Port 5061 -MatchUri "vc.domain.com" -UseDefaultCertificate $true
  • Set-CsStaticRoutingConfiguration -Identity "Service:Registrar:S4BFE.domain.com" -Route @{Add=$route}
  • Set-CsMediaConfiguration -MaxVideoRateAllowed Hd720p15M
  • Enable-CsTopology

On CMS proceed to Configuration\General and enter the S4B front-end server address and the username to be used to register.

In General Incoming Calls section, enter the CMS local domain name.

In General\Outbound Calls, enter the domain names to be called from Cisco Meeting. To allow calls to any domains, leave the Domain field empty. It will be set to ⟨match all domains⟩.

The Local From Domain field contains different domain names to be used to call domain.com and other domains. Calls from CMS will be transferred to the domains federated with yours in Skype for Business. However, it can be possibly configured differently. The last step is to configure encryption in General\Call Settings section.

That’s it. Now your Cisco Meting App clients and Skype for Business (Lync) clients should be able to call each other.

HINT: Limitation of the number of registrations in Skype for Business

During one of our conferences, we faced a limitation of the number of external Skype for Business participants. New participants would just disconnect, never visiting the room.

After talking to specialists, we decided to increase the number of CMS registrations on S4B servers.

First of all, we created 5 AD users for CMS and registered these accounts in Skype for Business. The accounts meet the following template: username[1-9]. So, to increase the number of participants up to 5, you should create 5 users: username1, username2, username3, username4 and username5, and add corresponding accounts to S4B.

Then you should enter the required number of registrations in CMS configuration:

After this simple manipulation you shouldn't face this kind of limitation anymore.

Disaster Recovery System in Cisco UCM

Evading disasters

In this article we study the Cisco Unified Communications Manager (CUCM) failure recovery system that is called Disaster Recovery System (DRS). You can use it to create system backups stored on SFTP server to be used for system recovery, if needed.

DRS includes the following components:

  • Cisco Unified Communications Manager database (CCMDB), including Cisco Unified Communications Manager/CDR Analysis and Reporting/Call Detail Records);
  • Platform;
  • Music On Hold (MOH);
  • BAT Bulk Provisioning Service (BPS);
  • CCM Preference Files (CCMPREFS);
  • TFTP Phone device files (TFTP);
  • SNMP Syslog Component (SYSLOGAGT SNMP);
  • SNMP CDP Subagent (CDPAGT SNMP);
  • Trace Collection Tool (TCT);
  • Cluster Manager (CLM);
  • Cisco Extended Functions (CEF);

Configuration

First of all, you have to deploy an SFTP server to create a backup. Cisco recommends using such clients as Cygwin, Titan FTP, GlobalSCAPE EFT, but you can use other clients as well. Download a client of your choice, install it on the workstation that will use an SFTP server, configure the connection parameters, select the root directory and run the service.

Now open the CUCM configuration page. Select Disaster Recovery System in a dropdown menu in the upper right corner.

Then proceed to Backup → Backup Device and click Add New. In the form that appears, enter the backup name in Backup device name field. Select Network Directory in Select Destination section and enter the SFTP server IP address in Host name/IP address field. Enter the user credentials in User name and Password fields. Enter the path to store the data in Path name field (type ’’\’’ if the data should be stored in the root directory). Then click Save. If the SFTP server is available, you’ll see the message: Update Successful.

Now you can create a backup. Open Backup → Manual Backup, select the previously chosen backup parameters and click Start Backup.

To create a backup schedule, proceed to Backup → Scheduler and click Add New. Select a backup, enter the time of archiving and click Save. Then click Enable Schedule at the top of the screen.

Let’s look into system recovery, which is called Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild). To restore the system from a previously created backup, proceed to Disaster Recovery System → Restore → Restore Wizard. Select Backup Device, then click Next and choose one of the available files.

Select the features to be restored.

Then select the servers and click Restore.

The system recovery will begin. You can see the current recovery status here: Disaster Recovery System → Restore → Status. After the system is restored, you’ll have to reboot the server. You can check the replication status using either CUCM Unified RTMT (Call Manager → Database Summary → Replication Status, the status should be same for all the nodes) or CUCM Unified Reporting (Unified Reporting → System Reports → Unified CM Database Status, look for “All servers have a good replication status” line), or through CLI (execute the following command: utils dbreplication status to get “No Errors or Mismatches found. Replication status is good on all available servers” as the result).

Connecting THIRD PARTY SIP to CUCM

Hello! In this article, we’ll tell you how to connect Third Party SIP Phones (i.e. other vendors’ phones and softphones that support RFC3261) to Cisco Unified Communications Manager (CUCM). As an example, we’ll use a popular free softphone named X-Lite.

CUCM Configuration

First of all, create a user in CUCM.

Proceed to User Management → End User. Provide the following information:

  • User ID
  • Password (not used in X-Lite, but should be specified)
  • PIN (not used in X-Lite)
  • Last Name
  • Digest Credentials (this field is used as a password in X-Lite)

Now add a SIP Phone. To do this, proceed to Device → Phone and click Add. Select Third-party SIP Device in the Phone Type field. Basic option only supports a single line, Advanced supports up to 8 lines.

Now fill out the following fields:

  • MAC Address – enter a unique address (if you are using X-Lite, enter any address, because it won’t be used for authorization);
  • Device Pool – Default;
  • Phone Button Template – Third-party SIP Device;
  • Security Device Profile – standard Third-party SIP Device Profile;
  • SIP Profile – standard SIP Profile;
  • Owner User ID and Digest User – the End User we have created;

Then click Save and proceed to the phone configuration screen. Click Line [1] – Add a new DN and fill the Directory Number field with the number to be used. Go back to User Management → End User, find the created user and check whether the SIP Phone is listed in the Controlled Devices field. If it's not listed, click Device Association and select the SIP Phone we have created. It should appear in the Controlled Devices list.

Softphone Configuration

Open X-Lite and proceed to Account Settings menu.

Fill out the following fields:

  • Display Name – the name to be displayed in X-Lite;
  • User Name – Directory Number (DN) in CUCM;
  • Password – Digest Credentials in CUCM;
  • Authorization user name – User ID in CUCM;
  • Domain – CUCM server address;

Now click OK. The softphone should be registered.

How to Record CUCM (CallManager) Calls

CUCM call recording is one of the most popular topics in the world of Cisco Unified Communications. For companies that deployed Cisco Unified Communications Manager there are several approaches to phone call recording offered by a dozen of Cisco Solution Partners.

Which one to choose and why? Let’s consider briefly.

Call Recording Methods

  • SPAN-based recording (“passive recording”) – is one of the oldest methods of CUCM voice recording. This type of recording software connects to the SPAN (Switched Port Analyzer) port to monitor all network (or VLAN only) traffic and pick out the VoIP packets to store them as audio files.
  • Built-in Bridge recording (“BIB recording”) – is the approach that uses the conference bridge embedded in almost each Cisco IP phone (and Cisco Jabber for Windows as well). With the proper CUCM configuration a Cisco IP phone forks the phone call audio streams to the CUCM recording software that mixes these streams and saves to the audio file.

In the beginning of 2011 Cisco introduced its own recording platform Cisco MediaSense. This solution records audio streams forked by Cisco IP Phones (BIB-recording) or (this is important!) Cisco ISR routers.

Why is it important? Along with Cisco MediaSense Cisco released the new IOS ( Cisco ISR router firmware) that supports the media forking capability. Supplied with this feature, the Cisco gateway can fork the media of conversations to the recording server.

Which leads us to the 3rd method:

  • CUBE recording – the same as BIB-recording, but the media is forked by Cisco CUBE (the software that runs on Cisco ISR router). If Cisco MediaSense can receive and store forked audio streams, why 3rd party recorders cannot?

So, what method to use and which solution to choose for Cisco CallManager recording?

Choosing the Call Recording Approach

Improve the MediaSense user experience with free PhoneUP promo-license which includes MediaSense Gateway module for unlimited number of seats.

Use BIB recording for all endpoints with built-In bridge on board. Without doubts this is the most reliable approach which also provides the more detailed info about a call.

Use CUBE recording for recording the other media (3rd party SIP devices, analogue phones connected with the voice gateway, CTI-ports, etc.) if your Cisco router supports media forking.

Use SPAN in all other cases, for example – when you don’t have a forking CUBE or you need to record internal calls of endpoints without BIB (the voice traffic is not going through the Cisco gateway).

Choosing the Recording Server

If you have to use the SPAN-recording method you are forced to choose a CUCM recording 3rd party solution.

If IP phone built-in bridges and CUBE can fork everything you need to record, then Cisco MediaSense looks like quite a tempting choice. But from the users’ perspective it only provides a very simple “Search and Play” web-interface - a password-protected web page with call recordings list and basic search capabilities. It is enough for small installations, but most of deployments need a 3rd party call recording solution that integrates with Cisco MediaSense and provides the more convenient user interface with additional features like access rights management, advanced search capabilities and so on.

Some of call recording software vendors added the Cisco MediaSense connector to their solutions. This allows using a 3rd party call recording app to manage Cisco MediaSense recordings and provide users with the rich-featured interface.

CUCM 12: What’s New?

Recently Cisco has released the 12th version of Cisco Unified Communications Manager. In this article, we’ll tell you about 5 main features included in the 12th release.

Mixed (Hybrid) Installation Support

It’s 2018, and cloud solutions are getting more and more integrated into business, becoming a part of infrastructure race. Cisco keeps up, with its unified communication solutions being based on a cloud platform named Cisco Hosted Collaboration Solution (HCS).

It’s important to notice that the 12th CUCM release supports mixed architecture, so a CUCM instance deployed on a company’s own servers and a CUCM instance in a cloud can communicate with each other without any complications.

This architecture helps to perform internal calls in the corporate environment where the CUCM instance is deployed.

Unsupported phones

Planning to upgrade to CUCM 12? Note that the following phones won’t be supported since 12.0:

  • 7905
  • 7970G
  • 7921G
  • 7935
  • 7902
  • 7910
  • 30 VIP
  • 12 SP+
  • 7912
  • 7920
  • 7971G-GE
  • 7910SW

New Licensing Technologies

CUCM 12 doesn’t support the traditional Product-Activation Key (PAK) licensing technology. Instead, Cisco runs Smart Software Licensing, with licenses being associated with a Cisco account, not with a specific device.

IPV6 Support

The 12th version makes it possible to have IPv6-only PBX installation.

TLS Version Definition

What TLS should be used? Which version is safer? This topic tends to be arguable. Cisco engineers decided to end this holy war. With CUCM 12, you can choose which TLS version to use for selected UC devices to communicate: TLS 1.0, 1.1 or 1.2.

SCCP (Skinny Client Control Protocol)

Today we’ll tell you about Cisco Systems’ proprietary protocol named SCCP – Skinny Client Control Protocol. It was created for corporate phone networks based on Cisco products, such as:

  • IP Phone series 7900
  • Cisco IP Communicator softphones
  • Cisco Unified Communications Manager
  • Cisco Unity

Notice that there’s another protocol with the same abbreviation: Signaling Connection and Control Protocol (SCCP). However, this protocol belongs to Signaling System №7 (CCSS7), while SCCP (Skinny Client Control Protocol) works in TCP/IP stack.

In VoIP, SCCP occupies the same place as SIP, H.323 and MGCP and performs the same functions. However, unlike all the listed protocols, SCCP has much easier syntax and requires less processing power.

Like most VoIP protocols, SCCP was designed for exchange of signaling messages between client and server during call establishment and call termination.

SCCP doesn’t take part in audio data transfer, there’s another protocol for this purpose: RTP (Real-Time Transport Protocol). It’s also important to note that SCCP doesn’t use RTCP (Real-Time Transport Control Protocol) that transfers diagnostic information about the current connection. SCCP has its own mechanism for this purpose.

As mentioned above, SCCP has very simple syntax. You can easily define the exact status of the current connection by any message header. This makes SCCP very convenient for trouble shooting. The well-known TCP (Transmission Control Protocol) port 2000 is used for SCCP messages transmission.

A connection via SCCP can’t be discussed without a server (usually CUCM). SCCP has a great number of messages to be sent to server for every single reason in order to get a guide to action. It looks like this:

  • IP Phone: StationInit: Someone picked up the receiver
  • Server: StationD: Turn on the buzzer
  • Server: StationD: Show “Enter the phone number” message on the screen
  • IP Phone: StationInit: Beginning to call the subscriber, the first digit of the number is “4”
  • IP Phone: StationInit: The second digit is “7”

Each event is being registered until the server receives a message saying the receiver has been hung up.

Notice that SCCP messages are being sent to client and server both, so there are identifiers that define the message source: StationInit if client is the source; StationIniD if server is the source. So, any call performed inside a corporate network can be traced in detail.

Here’s an example of some SCCP messages:

  • 0x0000 - Keep Alive Message – a message sent from server to client immediately after the registration
  • 0x0001 - Station Register Message – a request for registration on server
  • 0x0002 - Station IP Port Message – UDP port number for an RTP session (sent by a client)
  • 0x0006 - Station Off Hook Message – a phone picked up (sent by a client)
  • 0x0099 - Station Display Text Message – shows “Enter the number” message on the screen
  • 0x0082 - Station Start Tone Message – turns the buzzer on
  • 0x27 - Station Soft Key Event Message (new call/end call) – if it's the start of a call, this message contains the first digit of the subscriber’s number. It can also contain middle digits and a request to drop the connection (call end)
  • 0x107 - Station Connection Statistics Request Message – a request for diagnostic information (delays, media packet loss, jitter buffer, accepted and sent packets, etc.) sent by a client. This mechanism makes up for the RTCP absence

You can see that each MessageID describes the corresponding event, so reading SCCP traces is usually a straightforward process.

It’s also important to note that some voice solutions developing companies, such as Digium, SocketIP and Symbol Technologies, have added SCCP support in their products.

Pages: 1 | 2 | 3 | Next