Aurus Blog

This blog is to share our expertise in Cisco UCM, UCCX/UCCE and Cisco Telepresence.

  • Archive

    «   April 2019   »
    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          

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

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.

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.

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.

Packet Sniffing in Cisco UCM

Hello! In this article, we’ll tell you how to capture packets on Cisco phones connected to Cisco Unified Communications Manager (CUCM).

Packet capture is useful for troubleshooting. This article will show you how to do this by connecting a phone to PC via the built-in PC port. In this case, the copy of the traffic coming to the phone’s SWITCH port will be forwarded to PC port (sometimes this is called mirroring). You can obtain these packets with any traffic-sniffing software.

Connecting and Configuring Cisco IP Phone

First of all, let’s connect up the Cisco IP phone. The phone’s back panel has several ports. Find the port named SWITCH and plug the switch cable here. Connect the port named PC to the network adapter on your PC.

Now proceed to your CUCM, select Device → Phone and find your phone. In the Product Specific Configuration Layout section, find PC Port parameter and select Enabled. Then find Span to PC Port and select Enabled. Some phones do not have Span to PC Port parameter, in this case all data is automatically forwarded to the PC port.

Now open your packet sniffer (WireShark, for instance), select the network interface the phone is connected to, and click Start.

That’s it! Now you can start analyzing packets.

Configuring Dialed Number Analyzer in CUCM

This article tells about the Dialed Number Analyzer in Cisco Unified Communications Manager (CUCM). Why do you need it? Suppose you are configuring a complicated dial plan on your server. There are CSS, Partitions, Route Groups, Route Lists, Route Patterns, etc. How should you test it to find mistakes? Here comes the Dialed Number Analyzer. It helps you to analyze a dial plan and gives the full call flow information for the dialed digits.

Configuration

First of all, proceed to the Cisco Unified Serviceability menu → Tools → Service Activation. Now check Cisco Dialed Number Analyzer and click Save.

Now proceed to Tools → Dialed Number Analyzer, or open the following URL: https://[cm-machine]/dna. In the window that appears, open Analysis → Analyzer.

Here you should fill out three fields:

  • Calling Party – the caller’s phone number for the test call;
  • Dialed Digits – the dialed digits;
  • CSS – Calling Search Space for the test phone.

After that, click Do Analysis. You will see what happens to a call under the specified conditions.

To analyze gateways, phones and trunks separately choose Gateway, Phone or Trunk in the Analysis menu.

Time of the Day Routing in CUCM

This article is about routing in Cisco Unified Communications Manager (CUCM). Today’s topic is Time of the Day routing. This feature helps you to distribute calls depending on the time of day and day of the week. For example, you can forbid international calls during nonworking hours and on weekends, and reroute intercity calls to a different trunk for this time period.

Time of Day Routing can be used together with CSS, Partitions and routing technologies like Route Pattern and Route List/Route Group.

If you are going to use it with Partitions, specify the required time period in Time Schedule and link it to a partition. This partition will only be active during the specified time period. For the rest of the time it will stay invisible.

To manage routing depending on the time, create several Partitions and set their priority using the CSS list (the first partition on the list has the highest priority). Then create several Route Patterns and put them into different partitions.

Configuration

First of all, configure time periods. Proceed to Call Routing → Class of Control → Time Period and click Add New. Enter the name for your time period, start and end time, time zone and repetition parameters. Click Save.

Now create a time schedule. Proceed to Call Routing → Class of Control → Time Schedule and click Add New. Fill out the Name field, click Save. Then the Time Period Information field will appear. Select the required time periods.

Now configure partitions. Proceed to Call Routing → Class of Control → Partition, select a partition to edit (or create a new one). Select the Time Schedule you have created.

Proceed to Call Routing → Class of Control → Class of Control and move your partitions to a CSS. A partition’s priority depends on its position on the list.

Then add partitions to Route Patterns that are located here: Call Routing → Route/Hunt → Route Pattern.

Now you can distribute calls in your system depending on the time.

Configuring Callback feature in CUCM

This article will show you the CallBack feature in Cisco Unified Communications Manager (CUCM). The CallBack feature is used to inform the caller when the called party line becomes available.

First, open Cisco Unified Serviceability menu → Tools → Service Activation. Then select your server and make sure that Cisco Extended Functions option is checked.

Now configure Softkey. Proceed to Cisco Unified CM Administration menu → Device → Device Settings → Softkey Template. Then click Add New, select the Standard User template and click Copy. Enter the name and description for the new template. Then select Configure Softkey Layout in a dropdown menu in the upper right corner and click Go. In the field that appears, move Call Back from Unselected Softkeys to Selected Softkeys using the right arrow button. Repeat for On Hook, Connected Transfer and Ring Out states (select a call state to configure in the corresponding field).

Then apply the softkey template to a phone. Proceed to the Phone tab and select the phone to apply the template to. Select your template in the Softkey Template field, then click Save and Apply Config.

The CallBack button will appear at the bottom of the screen.

Let’s see how it works.

Make a call from phone A to phone B while phone B is busy. Press CallBack on the phone A.

Then press OK. The message will change to CallBack is activated. Press Exit to quit this screen. To deactivate the function, click Cancel.

As soon as phone B becomes available, a window with an audio signal and a notification about phone B being available will appear on phone A. To call phone B, press Dial.

Updating CUCM 8.6 to 11.5 on UCS C220 M3S step by step

Based on the documentation:
https://www.cisco.com/c/en/us/td/docs/voice...

The prerequisites (hardware and software) are the following:

  • 2x UCSC-C220-M3SBE
  • VMWare ESXi 5.1
  • CUCM (two Subscriber nodes, Publisher, version 8.6.2.25900-8)
  • CUCM (up to 1000 users)
  • CUCM Guest: 2vCPU, 4096Mb vRAM, 80Gb virtual disk
  • UCCX: one node, version 8.5.1.11004-25

Upgrading the Publisher

The Subscriber should be alive.

1. Take a Backup (1) – shut down the VM and make a copy.
2. Install V3 RSA keys via SFTP: Software Upgrade > ciscocm.version3-keys.cop.sgn
3. Use the following command to shut down CUCM: utils system shutdown
4. In this example the hardware was 2vCPU, 4096Mb vRAM, one 80Gb virtual disk. The following Guest VM Settings changes were required in order to upgrade to CUCM 11.5 (with 1000 users): https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/uc_system/virtual...
a. Guest OS: switch to 64-bit Red Hat Enterprise Linux 6
b. vRAM settings: increase the RAM size to 6 Gb
c. Configure the Network Adapter:
- Take a screenshot of the MAC address

  • Browse the datastore. Locate the *.vmx file and download it
  • Edit it. Add the following string at the end: ethernet0.virtualDev = "vmxnet3"
  • Upload the modified vmx file to the VMWARE folder
  • Remove the machine from the inventory
  • Add it to the inventory again
  • The network adapter parameters will be updated:

5. Run the Virtual Machine with the new settings. Wait for about 20 minutes for the machine to start all the services, so the CPU stabilizes.
6. Upload the new ISO image and map it to the CUCM VM.
7. Make sure that now you have 6 Gb RAM:

8. Open the operating system administration panel. Proceed to Software Upgrades > Install / Upgrade.

  • Source: DVD
  • UCSInstall_UCOS_UNRST_11.5.1.12900-21.sgn.iso
  • Choose “"Do not switch to new version after upgrade"
  • A refresh upgrade takes about 3 hours (Publisher: Started at 11.47, Completed at 13.35; Subscriber Started at 15.15)

9. Take a fresh Backup (2) – shut down the VM and make a copy.

Upgrading the Subscriber

The Publisher should be alive.
Perform the steps 1 to 8.

Configuring Self-Provisioning in CUCM

Self-Provisioning is another function that makes CUCM deployment and user management much easier.

It helps the user to automatically associate and configure the phone.

Let's look into the process of configuring this function.

The users already have been imported from Active Directory. Integrating CUCM with AD is described in the previous article.

First of all, configure device and line templates for auto-registration: Cisco Unified CM Administration > User Management > User/Phone Add > Universal Device Template and Cisco Unified CM Administration > User Management > User/Phone Add > Universal Line Template

Universal Device Template

Universal Line Template

Here you can configure the route partition for the lines to be placed in, CSS, alerting name, the user's locale and other parameters.

Now enable auto-registration.

Proceed to Cisco Unified CM Administration > System > Cisco Unified CM.

Select the server to enable auto-registration. Uncheck "Auto-registration Disabled on this Cisco Unified Communications Manager" and select the templates you have configured.

Now the first step is over. New phones will be automatically registered with DNs from the range specified in the Auto-registration Information section.

Now you should let the users configure the phones for themselves.

Create a CTI Route Point.

Cisco Unified CM Administration > Device > CTI Route Point

Add a DN for this CTI Route Point.

Create an Application User: Cisco Unified CM Administration > User Management > Application User

Add your CTI Route Point to the Controlled Devices. Add the user to Standard CTI Allow Control of All Devices and Standard CTI Enabled groups.

Configure the Self-Provisioning parameters in Cisco Unified CM Administration > User Management > Self Provisioning

Configure the User Profile in Cisco Unified CM Administration > User Management > User Settings

The configuration is complete.

Now a user can make a call from a phone to your CTI Route Point. The IVR will take up the call and prompt the user to enter the Self Service User ID and PIN. Then the phone will restart automatically and after the launch it will be configured for this user.

The phone will be bound to the user's DN, the owner will be specified and the phone will be added to the user's Controlled Devices.

The following DN parameters will also be configured: CSS, Alerting Name, Caller ID and Line Text Label.

So, after you've configured Self-Provisioning, you can completely exclude the administrator from the process of setting up new phones.

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.

Integrating ASTERISK and CUCM

Integrating Asterisk and CUCM via SIP makes it possible to combine several phone pools or, for instance, to use Asterisk as an IVR (interactive voice response system). This article gives instructions on connecting Asterisk and Cisco Unified Communications Manager through a SIP trunk.

Configuring CUCM

First of all, proceed to Cisco UCM configuration page. To create a new SIP trunk, select Device -> Trunk in the menu and click Add New. We are creating a SIP trunk, so fill out the Trunk Type and Device Protocol fields, as the screenshot shows:

After the parameters are specified, click Next. On the page that appears, fill out the following fields:

  • Device Name – enter the name of the SIP trunk to be created. This field is required.
  • Description – describe the connection to be created.
  • Device Pool – select a device pool for the SIP trunk. It should coincide with the devices routed through this trunk. This field is required.

Scroll down to the section titled Inbound Calls and fill out the following field:

  • Calling Search Space – CSS name for the SIP trunk. It should coincide with the devices routed through this trunk.

To finish the system configuration, proceed to the section titled SIP Information, sub-section Destination. Fill out the following fields:

  • Destination Address – enter the IP address of your Asterisk server. This field is required. Note that the default destination port is 5060. If your Asterisk server has a different SIP listen port, enter it in the Destination Port field.
  • SIP Trunk Security Profile – select Non Secure SIP Trunk Profile. This field is required.
  • Rerouting Calling Search Space – select the same CSS that you have selected in Inbound Calls section.
  • Out-Of-Dialog Refer Calling Search Space – similarly to the previous item, select the same CSS.
  • SUBSCRIBE Calling Search Space – select the same CSS.
  • SIP Profile – select Standard SIP Profile.

Click Save. You can use patterns (see Route Pattern settings) to configure routing to the SIP trunk.

Configuring Asterisk

You can carry out SIP trunk configuration process on the side of Asterisk through the FreePBX 13 graphical environment. To configure a trunk, proceed to Connectivity -> Trunks. Click Add Trunk to create a new SIP trunk.

On the General tab, enter the trunk name. Then proceed to the pjsip Settings tab. We don’t use username/password authentication to configure a SIP trunk between Asterisk and CUCM, so select the following options:

  • Authentication – select None. As mentioned before, we won’t need username/password authentication.
  • Registration – select None.
  • SIP Server – enter the Cisco UCM IP address.
  • Context – enter from-internal context

Proceed to the Advanced tab:

  • Qualify Frequency – enter 60. This is the delay (in seconds) between the keep-alive messages being sent to check the trunk’s state.
  • From Domain – enter your CUCM IP address.

Click Submit and then Apply Config.

As the final step, you should configure call routing for this trunk.

How to clean out the CUCM HDD common partition

As you go through RTMP logs on a Call Manager server, sometimes you can come across a critical warning of the following type: LogPartitionLowWaterMarkExceeded.

Despite the critical status, in most cases this problem doesn't affect the system's functioning, but the disk overfill may interfere with some installation or upgrade.

Common (log) partition is mostly filled with traces, CDRs and files from TFTP server. LogPartitionLowWaterMarkExceeded alarm is generated when the used disk space percentage in Log partition reaches the configured Low WaterMark value. This alarm should be taken as an early notification for an administrator to clean up the disk space. CUCM won't start an automated cleanup process until the High WaterMark value will be reached.

To free some space in the Common partition, you can try to:

  • Reduce the values of LogPartitionLowWaterMarkExceeded to 40% and LogPartitionHighWaterMarkExceeded to 45%, restart "Cisco Log Partition Monitoring Tool" service and after 2-3 hours check whether the used space decreased;
  • Use RTMT Trace/Log Central to collect logs/traces with "Delete Collected Log Files from Server" option (for active and inactive partitions);
  • Delete the old unused files from the TFTP server (old phone software);
  • Use ciscocm.free_common_space_v1.1.cop.sgn – this file runs a script that deletes all files from an inactive Common partition. After using it you won't be able to switch CUCM version to the previous one.

To reduce the partition usage, you can try to:

  • Deactivate Detail/Debug trace level;
  • Reduce the number of trace files to be stored;
  • For CDR: reduce the High Water Mark, reduce the occupied disk space, reduce the number of preservation days.

CUCM Traces Analysis: CUCM Architecture

This is another guest post that we find quite useful for our readers. The author discusses briefly the CUCM architecture in order to understand better the CUCM traces.

CUCM is a C++ application working on the Red Hat Linux OS.

There are SDL (Signal Distribution Layer) processes within the application interacting with each other. Some of these objects exist permanently while some of them are being created and destroyed as needed.

All SDL processes can be classified into several logical layers:

  • Feature Layer
  • Call Control Layer
  • Media Control Layer
  • Device Layer

As the figure shows, there also are Aggregator Layer and Link Layer. For the purpose of this article we'll consider the first one as a part of the Call Control Layer. The Link Layer is responsible for network interaction on TCP/UDP level, which isn't our concern here.

CUCM Process Classification

Let's explain the CUCM process classification by the example of the Feature Layer.

  • Parent Processes live in the system permanently. They are being created at the Call Manager application launch. These processes are: Transfer Manager, Forward Manager, Conference Manager, Recording Manager. They are responsible for ALL conferences and transfers in the system.
  • Child Processes are being created during a certain operation. For example, the Forward operation creates a Forwarding sub-process that lives until the transfer is over (then this process will be destroyed).

Device Layer Processes

  • Edge Processes. are responsible for signaling protocols. These processes are Parent Processes and each of them exists in a single copy on each node. For example, if we have 50 SCCP phones, then all of them will interact with a single StationInit process.
    • StationInit (SCCP)
    • SIPHandler (SIP)
    • H225Handler (H323)
    • MgcpHandler (MGCP)
    • MgcpBhHandler (MGCP PRI)
  • Control Processes exist in several instances. For example, for each registered SCCP phone a separate StationD process will be created that controls this phone. So, there will be 50 StationD processes created for 50 phones.
    • SipStationD
    • SIPD
    • StationD

If there are 20 SIP phones, then one SipHandler process, an intermediate SipStationInit process and 20 SipStationD processes will be created on the node. SIPD processes are used for SIP Trunks (one for each trunk).

Now let's look into what happens when a user picks up the phone:

The phone transmits a message to CUCM, and then the following events occur: StationInit transmits a message to the phone StationD process. StationD creates StationCdpc process. StationCdpc process is responsible for a single call from a certain phone (CallDependent) and will be destroyed after the call is over.

Similarly, if the phone is turned off and its registration is lost, its StationD process will be destroyed.

Call Control Layer Processes

Call Control layer processes come into play to process the dialed phone number. These processes take part in establishing the call and handling it:

  • Call Control (CC) is responsible for all the calls passing through the CUCM node (1 process for a node).
  • Call Dependent Call Control (CdCc) is responsible for a single call. Every new call creates a new process.
  • DA - Digit Analysis: here all the translations are being performed, the corresponding CSS and Partitions applied, and the destination for a particular call to be routed to is being defined.
  • Device Manager (DM) – contains the tables with all the devices connected to a CUCM cluster (phones, trunks, gateways, route lists). DM makes it possible to define where the call should be physically routed.
  • Line Control process is responsible for all the DNs registered in the system.

Let's look into how a call is handled, step by step:

Call Control (CC) creates a separate Call Dependent Call Control (CdCc) process for the call. The dialed digits are passed to this process.

CdCc passes the numbers to DA for the necessary translations to be performed and the privileges to be defined for this call.

Then the call is passed to the Device Manager (DM) which determines the device the call should be transferred to.

The information from the DM is sent back to DA and then to CDCC.

Then the call establishment will begin (CcSetupReq) and the end device will be chosen through the RouteListControl > RoutelistCdrc chain.

Notice the Line Control process here – it is responsible for all the DNs registered.

So, the phone starts ringing, the user picks it up, and the next step is setting up a media or RTP stream. Now we're moving one layer lower and pass the call to the Media Layer.

Media Layer Processes

As we have already mentioned, this layer hosts the processes that are responsible RTP streams.

There are permanent processes: ConnectionManager and MediaCoordinator.

And there are MediaManager and MediaExchange processes are being created and destroyed along with the calls. They are responsible for all the call parameters - DTMF, codecs etc.

There are also Int processes - interfaces that interact with the devices directly. These processes are responsible for the interaction between the Media Layer and Device Layer: they pass the codecs, IP addresses, ports, etc., to the devices.

Codec mismatch

When the "codec mismatch" happens the MediaManager and MediaExchage processes define the transcoder to be used. Then the separate MediaExchange (MX) process is created to ensure the connection between the first phone and the transcoder and between the transcoder and the second phone.

After the call is over, all the processes will be destroyed, except for ConnectionManager and MediaCoordinator.

Process Identifier (PID)

Each process in SDI and SDL Traces is marked in a certain way:

Process Type is the process type identifier (37 for a StationD process)

Process Instance is the process ID. In this case "50" means there are at least 50 phones registered, and the current phone is the 50th. This value is always equal to 1 for Parent Processes.

CUCM Architecture Summarized

Suppose that the phone A is calling the phone B.

  • The Device Layer hosts the StationD and StationCdpc processes that are responsible for the interaction with the phone directly.
  • After the handset is picked up (the Device Layer process this), the call info is being passed to the Call Control Layer where the Digit Analysis is located. Here all the translations are being performed and the corresponding CSS and Partitions applied to identify the destination the call. At the same time a request to the Feature Layer will be sent to transfer the call to user B.
  • The Call Control Layer passes a message to the Device Layer - this time to the phone B process. Phone B rings.
  • Phone B is picked up and the Media set up begins. To define the codec the Connection Manager and the Media Coordinator create Media Manager and Media Exchange processes that will interact with the phones through Interfaces.
  • The conversation begins.

Configuring CUCM Single Number Reach feature

This article is about configuring Single Number Reach (aka Mobile Connect) feature in Cisco Unified Communications Manager (CUCM).

When you receive an incoming call on an extension number in a cluster, the Single Number Reach (SNR) enables rerouting the call not only to a DN, but also to a remote number. For example, that can be an employee's cell phone. If needed, you can configure rerouting to a group of remote numbers that belong to an employee.

This explains the name of this feature: Single Number Reach. After you dial the employee's extension number, you can reach this employee even if he or she is not in office. The SNR enables call routing to a specified group of numbers, so a subscriber can answer any of them.

Let's have a look at how SNR (Mobile Connect) actually works.

Let's assume that the subscriber with the number 479-555-15-55 dials the number 151-15-55-2001. The call is routed to a voice gateway and then to a CUCM cluster. Suppose that the last 4 digits of a public number correspond to an employee's extension number. After that the phone with the extension number 2001 will ring. Besides, if the number has the SNR feature configured, the call will be redirected to another number as well, for example, to the employee's cell phone number 408-555-10-01.

Basically, Mobile Connect provides functionality similar to Shared Line. The difference is that in this case a shared line is organized between an office phone and some remote device that isn't necessary in a cluster, not between the phones within a cluster.

The figure below illustrates this configuration:

On this figure you can see that Mobile Connect creates a shared line between an office phone and a Remote Destination Profile (RDP). RDP reflects remote numbers in CUCM configuration. You can bind several Remote Destination numbers to a single DN using RDP. Note that Remote Destination Profile and Remote Destination are essential parts of Mobile Connect. Apart from them we'll also use the following entities: User, IP phone, Softkeys, Access list.

The User entity defines an end user registered in CUCM with Mobile Connect features enabled. Generally, the most important thing in CUCM is a user, not a device, because the services are provided to people, not to devices. That's why in the system a user is associated with an office phone and RDP.

Next, IP phone and Softkeys. A phone has to be associated with a certain user. The Mobile softkey provides an employee with an opportunity to redirect an active call to an office phone, if this call is coming to a cell phone. To add the Mobile button to the phone interface in on-hook mode, you'll need a Softkey Template.

Access list enables filtering incoming calls by the caller's phone number. This feature isn't necessary, but it can be handy. At first an Access list is created in the configuration parameters and then it is bound to a certain RDP.

Configuring Mobile Connect is relatively easy. First of all, you should create an End User that will be the center of all the system logic. There are several ways to create a user, but in any case the Enable Mobility option should be checked, as the figures show.

Here you can also define a limit for the quantity of remote phone numbers associated with this user. After that you should associate the user with the office phone number that he or she uses. For that purpose you can use Owner User ID in the phone parameters.

Now you can configure the entities that are essential for Mobile Connect. At first, you should create a Remote Destination Profile. To do this, proceed to Device -> Device Settings -> Remote Destination Profile.

You must specify the same End User (User ID field). Note the Rerouting Calling Search Space field. Here you can specify CSS that will be used for outgoing calls to Remote Destination numbers while processing an incoming call to an office phone. This CSS will ensure Route Pattern availability while routing an outgoing call to a Remote Destination.

Please save the RDP information. After that you'll be able to create lines. Specify the number used on the office phone that should have the calls redirected via Mobile Connect as one of the lines.

Follow the "Add a New Remote Destination" link. The Remote Destination Configuration form will appear.

Let's have a look at the parameters we can specify. "Answer Too Soon Timer" defines the minimal time for a call to be transmitted to a Remote Destination before the user answers. This parameter helps to prevent the call from being sent to voice mail when the user's cell phone is switched off or out of coverage area. "Answer Too Late Timer" defines the maximum response timeout for a call to a Remote Destination. "Delay Before Ringing Timer" defines the delay before the CUCM redirects an incoming call to a Remote Destination. All these parameters are specified in milliseconds. It is necessary to set the Line Association mark for the number that will be associated with a remote number. It is also necessary to switch the Enable Mobile Connect option on. The Mobile Connect option enables redirecting an active incoming call from a mobile phone to a landline office phone by clicking the Mobility button on the office phone.

If needed, use the Access List Configuration to configure the filtering for the calls to a Remote Destination. To do this, proceed to the menu: Call Routing -> Class of Control -> Access List. Select the access list type: blacklist or whitelist (Blocked or Allowed). Then use the Add Member button to fill the list with the corresponding numbers.

Now you should bind the Access List on the Remote Destination Configuration page. You can select one of the following options: transmit the call to a remote device if the subscriber is on the list, or the opposite. You can also specify the Ring Schedule, which can permit redirecting calls to a remote number during the working hours only, for example.

You should remember that if you configure both the schedule and call filtering, then the schedule will be checked first. So if the time is inappropriate, the access list won't be even checked.

As you can see, configuring Single Number Reach presents no great difficulty. After you configure this feature, your employees will be able to accept incoming calls on the office phone numbers not only in the office, but on their mobile and home phones as well, no matter where the call is coming from.

Useful CUCM CLI SQL Queries for DN and CSS

Recently I needed to collect the detailed information on Cisco IP phones, extension numbers, CSS and other parameters. The communication network was really huge but no inventory had been performed for years.

Lots of phones and extension numbers with no common attributes. Actually, I was given the list of extensions for which I had to return the detailed info.

This is where the CLI SQL Queries can hardly be underestimated. With CLI you can query the CUCM database directly. A query can be executed from the command line if you access the CUCM server via SSH.

To execute the SQL query, run the following command:
run sql <query body>

For example:
run sql select dnorpattern from numplan where dnorpattern like '1%'

The result will contain all the directory numbers, route patterns and translation patterns beginning with "1".

More examples:

Show the DNs assigned to the phones on the list:
run sql select n.dnorpattern as DN from device as d, numplan as n, devicenumplanmap as dnpm where dnpm.fkdevice =d.pkid and dnpm.fknumplan = n.pkid and d.tkclass = 1 and (d.name in ('SEP7C96F3C9ACDC' , 'SEPB8BEBA229A9E';))

Show the CSS configured for the DNs on the list:
run sql select css.name from numplan as np join callingsearchspace as css on np.fkcallingsearchspace_sharedlineappear=css.pkid where np.dnorpattern in ('6229' , '3118';)

Check if the DNs on the list are members of any Line Groups:
run sql select lg.name as LineGroup,n.dnorpattern,dhd.hlog from linegroup as lg inner join linegroupnumplanmap as lgmap on lgmap.fklinegroup=lg.pkid inner join numplan as n on lgmap.fknumplan = n.pkid inner join devicenumplanmap as dmap on dmap.fknumplan = n.pkid inner join device as d on dmap.fkdevice=d.pkid inner join devicehlogdynamic as dhd on dhd.fkdevice=d.pkid where n.dnorpattern in ('2480' , '1601';)

Check if the DNs are members of any Call PickUp Groups and show that groups:
run sql select np.dnorpattern, pg.name from pickupgrouplinemap as pgl join numplan as np on pgl.fknumplan_line=np.pkid join pickupgroup as pg on pg.pkid=pgl.fkpickupgroup where np.dnorpattern in ('' , '3118' , '5109';)

Find out if there is a line assigned to a phone and if the line has an External Phone Number Mask configured:
run sql select dnpm.e164mask as EPNM from devicenumplanmap as dnpm join device as d on dnpm.fkdevice=d.pkid where d.name in ( 'SEP1CAA07E2060D' , 'SEPF07F06B8D6B2';)

You can obtain the information as well as modify the data in the database. For example, you can modify the device description:
run sql update device set description = 'MARK_PHONE' where name in ('SEPD8CB8A379237', 'SEP80E86F23F5E7';)

This list of examples can go on endlessly. Actually, the direct access to the database is a tool of almost unlimited flexibility, suitable for obtaining information and making massive data changes.

Configuring Cisco Jabber 11 for iOS and Android Mobile Devices

If we have Cisco IM and Presence server and Cisco UCM in our corporate environment, as well as unhandy wi-fi Cisco 7925 telephones, which are heavy and consume the battery as fast as a Formula One car, then sooner or later we’ll think about switching to Cisco Jabber on a mobile phone.

This article tells what you need for that.

Before all experiments, make sure you have the following things:

  • Cisco Unified Communications Manager 8.6.2 or higher (preferably the latest version)
  • Cisco IM and Presence (integrated with CUCM, of course)
  • Wi-Fi Wireless Access Point, already set up by an administrator to distribute wireless internet (don’t mix it up with Wi-Fi Router, since if you have Router, your phones will be hidden behind NAT and RTP streams and it will be complicated to route correctly)
  • CUCM и IM&Presence Administrator kind enough to make us a CUCM and Presence user
  • Android 4.x or higher, better and faster (iPhone will do as well)

You can discard Cisco IM and Presence and configure Cisco Jabber for CUCM phone services only. It will be a dull and sad client (as an alternative to Jabber: what can possibly prevent you from registering an Android phone as a SIP third-party device on CUCM?), but you’ll be able to call anyway.

Proceed to Google market (or Apple Store for iPhone)

https://play.google.com/store/apps/details?id=com.cisco.im

And install the app.

But we won’t be able to run it until we perform the configuration steps in our Unified Communication infrastructure. So, led by the craving for launching Cisco Jabber on our phone, we go to the CUCM web interface and add our device.

Use the menu: Device - Phone - Add new – select "Cisco Dual Mode for Android"

Now we configure our precious, paying attention to the following aspects:

Device Name – in case of Android device it should start with BOT prefix (TCT in case of iPhone) and include name in upper case (BOT <NAME>). Allowed characters: a–z, A–Z, 0–9, (.), (_), (-). Total name length is limited to 12 characters. My device name is BOT-ATYRIN.

Description – specify or shyly conceal the phone model (or write any kind of nonsense)

Media Resource Group List – either specified explicitly or assigned through the Device Pool

Optionally specify User Hold MOH Audio Source и Network Hold MOH Audio Source

Owner – select User

Owner User ID – select yourself from the list of CUCM users

Device Security ProfileCisco Dual Mode for Android – Standard SIP Non-Security Profile

SIP ProfileStandard SIP Profile for Mobile Device

If necessary, in Product Specific Configuration Layout section you can turn video support on, and specify a list of SSID Wi-Fi access point names, separated with ( /), if you wish to connect to the specified access points only.

After that we can add a line (DN) to our device.


Associate yourself with this line.

Take notice that since Cisco Jabber 11.0.1 and CUCM 10.5(2)su2 versions you can use conversation recording and listening features!

Quoting the documentation: Silent Monitoring and Call Recording (Built-in Bridge) — In 11.0.1 Cisco Jabber for Android supports silent monitoring and call recording using Cisco Unified Communications Manager 10.5(2) su2 and later releases.

After that proceed to User Management – End User and give yourself the rights to use this device (Device Association)

Don’t forget to ensure that you are an IM and Presence user:

And have the necessary rights:

Last but not least, a bit of Cisco magic without which you may not be able to run anything:

Jabber on Android doesn’t support HOSTNAME in Android kernel before version 4.4.4, and it’s possible that the integration with Call Manager phone services won’t happen. So, you’ll only see chat and presence features.

To solve this problem, first of all it’s necessary to specify FQDN or IP address everywhere in Jabber settings.

Secondly, in System – Enterprise Parameters menu in CUCM you should fill the initially empty Organization Top Level Domain field (initially empty) with the enterprise domain value.

Now cross your fingers and pray to Cisco gods as we proceed to the most exciting part: the first launch and configuration of Cisco Jabber on your phone.

It launches, which is good enough. Let’s open “Advanced settings” and presume that we are clever enough to explore them. Fill out IM and Presence server address and press OK:

Fill out your username and password (End User credentials in CUCM, IM and Presence). If you haven’t made any mistakes, you may rejoice and shed tears of happiness:

Now you can use mobile Jabber:

All Possible Ways to Set Up PIN for CUCM Meet-Me Conference

  • "How to configure Meet-Me video conference with PIN?"
  • "We need to configure Meet-Me conference with PIN…"
  • "CUCM 10.x Meet-Me with Name announcement and Pin number…"

- try to search the Cisco Support Forum and you'll get dozens of similar tickets.

Yes, the built-in Meet-Me conferencing feature doesn't support PIN authentication, so here goes the list of all possible ways to set it up.

Before we start, let's agree that we only consider Cisco Unified Communications Manager Enterprise or Cisco BE 6000/7000. If you've got CUCM/CallManager Express (CME) you can play with TCL IVR scripts, but that’s definitely another story.

So you're enjoying Cisco UCM Meet-Me conferencing, but you want attendees to hear the voice prompt asking for a PIN needed to join the meeting. You’ve got 4 options:

1. Cisco Unity Express/Connection

If you have Cisco Unity deployed you can use it to achieve the Meet-Me authentication. The attendees call should be transferred via CUC and the User System Transfer Conversation should be used to authenticate the caller (a user is created on CUC). The conversation prompts the caller to sign in to CUC with his CUC ID and PIN and then transfers the call to Meet-Me conference number.

Looks like a kludge? Still it gets the job done.

2. Cisco Unified Contact Center Express (UCCX)

You can use UCCX as an audio front end to Meet-Me conferences. You may find several UCCX scripts around the web which prompt the caller for meeting ID and password and then transfer the call to the MeetMe bridge. Meeting IDs and PINs are set up by UCCX admin.

This works, but since UCCX is used for something that it’s not initially designed for, this workaround isn’t as feature-rich as you users may require and hard to maintain.

3. The "Conference Now" feature of CUCM 11

The "Conference Now" feature is introduced in Cisco UCM v.11 released in the summer of 2015. It's not the replacement for Meet-Me feature, but allows users to create their personal conference rooms protected (optionally) by the access code. The attendee has to call your conference room number, enter the access code and listen to the music until you start the meeting by joining it.

Quite promising feature but the access code stays the same until you change it, so if I participated in your meeting once, I can use it to join the next time even if I wasn’t invited. Also, no scheduler and conference control tool are available.

4. The “Conference” module of “Aurus PhoneUP” suite

The CUCM Meet-Me conferencing solution from Aurus is designed specifically for CUCM conferencing and allows you to:

  • schedule Meet-Me conferences with a web-interface;
  • use the MS Outlook plugin to schedule the meetings from the Outlook calendar;
  • use the same phone number for meetings (the PIN entered is used to define which meeting you're joining);
  • protect meetings with a randomly generated PIN (the PIN is automatically added to the meeting invitation sent to invitees);
  • control the conference with the web-interface – the meeting host can see the list of participants, join a new attendee and disconnect anyone;
  • start the meeting from any phone - without the necessity to use a Cisco IP phone to initiate the meetme bridge;
  • control the resources of the conference bridge.

So, these are 4 options to secure your Meet-Me conferences. Which one works better for you, depends on your business requirements and Cisco products used. Hopefully, this article will help you to evaluate the pros and cons of each option in relation to your environment.

Querying CUCM Database from the Command Line

Why?

Some operations on CUCM objects could be made much easier and faster through CUCM database, for example - to get a list of devices, to add several devices to the list of devices controlled by some axl-user, etc.

How?

1. Download CURL for Windows - http://curl.haxx.se/download.html
2. Then any AXL-request can be executed from the command line:
curl.exe -k -u axluser:axlpass -H "Content-type: text/xml;" -H "SOAPAction: CUCM:DB ver=8.5" -d @axlreauest.xml https://ccm9.bcs-it.loc:8443/axl/

where:

a) axluser:axlpass - login and password of the CUCM Application User
b) https://ccm9.somedomain.loc:8443/axl/ - CUCM AXL Service address
c) axlreauest.xml - the file with the request, for example:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/8.5">
    <soapenv:Header/>
    <soapenv:Body>
  <ns:executeSQLUpdate sequence="?">
<sql>
insert into applicationuserdevicemap (description, fkdevice, fkapplicationuser, tkuserassociation)
values ('', 'f37738df-222b-473c-813f-7872709ab221', '1abf2126-3339-5946-e755-6d59f368a7a5', 1)
</sql>
  </ns:executeSQLUpdate>
    </soapenv:Body>
</soapenv:Envelope>

Queries to CUCM tables are performed with the executeSQLQuery. Modification of data (insert / delete / update) – with executeSQLUpdate.

What is CUCM DB?

It is actually Informix.

To find out the exact version of the database server you can perform this query:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/8.5">
    <soapenv:Header/>
    <soapenv:Body>
  <ns:executeSQLQuery sequence="?">
<sql>
select DBINFO('version', 'full') from systables where tabid=1
</sql>
  </ns:executeSQLQuery>
    </soapenv:Body>
</soapenv:Envelope>

Read more about Informix here: http://publib.boulder.ibm.com/infocenter/idshelp/v111/index.jsp

The structure of the database

1. CUCM 6: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucm/datadict/6_0_1/dd601.pdf
2. CUCM 7: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucm/datadict/7_0_1/DD_701.pdf
3. CUCM 8: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucm/datadict/8_0_1/datadictionary_801.pdf
4. CUCM 9: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucm/datadict/9_1_1/datadictionary_911.pdf
5. CUCM 10: http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cucm/datadict/10_0_1/datadictionary_1001.pdf

Ask Cisco about the structure of the other databases: http://tools.cisco.com/search/results/en/us/get#q=Communications+Manager+Data+Dictionary

Reference

Here's our friend having fun on CUCM SQL quieries: http://www.ucguerrilla.com/2012/03/cucm-sql-queries-series.html

Examples of requests

Get the list of All CUCM devices
select * from device

Get the list of devices controlled by the user (returns identifiers)
select * from applicationuserdevicemap
where fkapplicationuser = 'a59e7a1c-3527-c5e4-89d8-edb3e0c10dab'

Remove a bunch of devices from the “controlled devices” list
delete from applicationuserdevicemap where fkapplicationuser = 'a59e7a1c-3527-c5e4-89d8-edb3e0c10dab'
and fkdevice in (select pkid from device where name like 'zCTIPort%' and name[9,15] > 5565400)

Add a bunch of device to the “controlled devices” list
into applicationuserdevicemap (description, fkdevice, fkapplicationuser, tkuserassociation)
select '', pkid, 'a59e7a1c-3527-c5e4-89d8-edb3e0c10dab', 1 from device where name like 'zCTIPort%' and name[9,15] > 5565402

RIS Service

To test the RIS the "/ realtimeservice / services / RisPort" path should be used in the URL instead of "/ axl".

The example of the RIS-query:

<soapenv:Envelope
     xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>

<ns1:SelectCmDevice soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:ns1="http://schemas.cisco.com/ast/soap/">
  <StateInfo xsi:type="xsd:string"/>
  <CmSelectionCriteria href="#id0"/>
</ns1:SelectCmDevice>

<multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xsi:type="ns2:CmSelectionCriteria"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:ns2="http://schemas.cisco.com/ast/soap/">

  <MaxReturnedDevices xsi:type="xsd:unsignedInt">200</MaxReturnedDevices>
  <Class xsi:type="xsd:string">>Phone</Class>
  <Model xsi:type="xsd:unsignedInt">255</Model>
  <NodeName xsi:type="xsd:string" xsi:nil="true"/>
  <SelectBy xsi:type="xsd:string">Name</SelectBy>

  <SelectItems soapenc:arrayType="ns2:SelectItem[1]" xsi:type="soapenc:Array">
<item href="#id1"/>
  </SelectItems>

</multiRef>

<multiRef id="id1" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xsi:type="ns3:SelectItem"
  xmlns:ns3="http://schemas.cisco.com/ast/soap/"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">

  <Item xsi:type="xsd:string">test</Item>
</multiRef>

    </soapenv:Body>
</soapenv:Envelope>

How to Extend CUCM (CallManager) Features

Cisco Unified Communications Manager (CallManager) is the leading IP PBX in the worldwide market. Only certified professionals can deal with its rich functionality. Nevertheless, dozens of software vendors develop products that empower CUCM (Cisco Unified Communications Manager) functionality with new features.

Aurus, the official Cisco Solution Partner, invites you to learn what new features the Aurus PhoneUP product brings to Cisco IP PBX (Cisco Unified Communications Manager or Cisco BE 6000/7000).

Enterprise Phone Directory for Cisco CallManager

The "Directory" module of the PhoneUP application bundle provides the enterprise phone directory service for employees, and is an alternative to built-in CUCM phone directory. The main differences between the "Directory" module and the out-of-the-box Cisco CallManager directory are:

CUCM"Directory" module
Number of directoriesOneUnlimited number with access control for groups of employees
Integration with external systemsADAD, LDAP, IBM Lotus Notes, CSV, XML, CUCM, SQL database
External contacts supportNoYes
Caller IDInternal numbers onlyAny phone number
Incoming call detailsName / Last Name / CompanyFlexible data that may contain an employee photo
Notification of missed calls via e-mailOnly with UnityYes
DTMF support NoYes
Personal directoriesOne (edited manually or imported from Outlook)Unlimited number of directories synchronized with external sources
Auto-redial featureNoYes


The "Directory" module is integrated with Cisco Jabber. Using the standard contact search field of Cisco Jabber not only you can find an employee, but also search for client, partner and any other contact imported from external datasource. Also, when you get a call from the contact (client for example) stored in the directory Cisco Jabber will show the client's name, status and any other information from the CRM system.

Phone Call Recording (CUCM)

Cisco offers its own solution, Cisco MediaSense for call recording that captures and stores audio, forked by Cisco IP phone bridge or CUBE (Cisco Unified Border Element). But MediaSense is a recording platform that only provides basic features to manage call recordings. Cisco officially recommends using 3rd party solutions developed by technology partners that provide additional functionality.

For example, the "Record" module of PhoneUP can be integrated with Cisco Mediasense to bring you extra-features not implemented in Mediasense:

  • flexible management of user access to call recordings;
  • rich search and filter tools;
  • call recording rules (for example, recording only external calls);
  • IP phone user interface to search and play the call recording;
  • playing the recording into the current phone call;
  • and much more.

Attendant Console

Cisco actively promotes Cisco Jabber, the enterprise collaboration tool. At the same time, some business units need a wider range of call control features including specific ones, for example:

  • top manager assistants need to monitor chief's phone lines and intercept calls during his absence;
  • reception staff and contact center need a visual control of the call queues not to miss client calls or VIP calls that should not be left unanswered;
  • top managers need an intuitive, time-saving interface allowing to perform basic call control actions with easy to use UI supporting drag-n-drop.

In these cases you should pay attention to the "Console" module.

Group paging via Cisco IP phones

Features of Cisco Unified Communications Manager (CUCM) and Cisco IP-phones, as well as API Cisco provides its technology partners, allow to use the IP telephony network for text and audio notifications to employee groups.

Cisco's collaboration product line doesn't include such a solution, and clients need to turn to 3rd party vendors. The "Paging" module of PhoneUP bundle supports both text and audio paging to Cisco IP phones as well as live broadcasting through speakerphones.

Features that improve the security of IP telephony network built on Cisco Unified Communications Manager (CUCM)

Cisco CallManager (CUCM) provides users with the Meet-Me conferencing feature – each conference has its phone number that needs to be dialed to join the meeting. But the "built-in" Meet-Me conferences do not provide the necessary security. Anyone who knows the number of conference room can dial it and join. To avoid this you can use the "Conference" module that works on top of CUCM conferencing feature and protects meetings with PIN.

The "Lock" module is used to lock Cisco IP phone while its owner is away to prevent abuses and frauds. In some ways this is similar to the "Extension Mobility" feature implemented in Cisco Unified Communications Manager, but is designed to improve the security. Unlike Extension Mobility a phone locked with PhoneUP:

  • stays registered to CUCM;
  • can receive incoming calls;
  • is allowed to make outgoing calls to a limited set of directions;
  • denies the access to the personal address book, call history, call recording, etc .;
  • gets locked and unlocked automatically when you log in/out the PC.

XML-services for Cisco IP phones

Cisco Systems provides technology partners with rich capabilities for development of custom XML-applications for Cisco IP phones - with which users can interact via the IP phone keypad and display. The "Inform" and "Hotel" modules of the PhoneUP bundle may be considered as examples of such applications.

Phone Auto Registration on CUCM

So, phone auto registration on CUCM. The topic is easy and most likely well-known.

A small prehistory. My colleague received a request to connect the phone for the new employee yesterday. The task is easy and repeated several times every day.

In our company auto registration on CUCM is always enabled. Yes, I know that Cisco does not recommend to keep it constantly enabled for security reasons, but so we have decided, because all the sockets in which you can plug the phone are in the closed area and outsiders do not have access to them.

My colleague, taking a new phone out of the box and turning it on to the network, instead of the expected signs 'Your current options' and numbers from the pool for auto registration, saw the following:
Registration Rejected: Security Error.

Then I began to research CUCM logs. And I saw the line in the SDL traces:

AddDevice returns "There are no free autoreg DN in the system free DN between 1010 and 1099".

It means that the auto registration process of CUCM unable to create a new DN within a predetermined range and a predetermined Partition. Why it could not do? Because these DN-s are already in the system! They can be viewed in the section Call Routing -> Directory Number.

The solution of the problem is elementary – to change the range in auto registration settings or remove unnecessary DN-s. Because the auto registration is usually used in order to do not enter the MAC address manually. After auto registration the phone is configured manually.

And now a few words about how to configure the auto registration.

  • Go System -> Enterprise Parameters. Specify which protocol will be used for auto registration in the Enterprise Parameters Configuration section in the Auto Registration Phone Protocol parameter. SCCP is used by default.
  • Create a Partition for auto registration. Theoretically, you don't have to do it, but it would be more correct to create it. Generally Partitions and Calling Search Space is a very powerful tool in CUCM.
  • Configure Device pool (if it’s not configured).
  • Go Device -> Device Settings -> Device Defaults and then specify the default device pool for all used types of phones, for example, the one that is configured previously.
  • Select the server in System -> Cisco Unified CM, on which we enable auto registration. Specify the range of numbers, Partition, and External Phone Number Mask in Auto-registration Information section. The main thing is to disable Auto-registration Disabled on this Cisco Unified Communications Manager checkbox. So it is possible to set up multiple servers for auto registration. It is preferable to specify for them the different ranges of DN.
  • Check CM groups in System -> Cisco Unified CM Groups. Auto registration can be enabled on the one group only! If you want to enable it on the other group, then go to the group settings and select the Auto-registration Cisco Unified Communications Manager Group item.

All appropriate services should be enabled in Cisco Unified Serviceability for auto registration process; i.e. Cisco CallManager at least, on those nodes, on which auto registration is configured.

Now a little bit more information:

  • Do not try to create a DN for auto registration manually in advance! CUCM creates them itself! Otherwise, you will get the same mistake on the phone screen that my colleague got.
  • Auto registration can be configured on multiple servers, but! Only one group of servers may be available for auto registration. If the group consists of several servers with enabled auto registration, then keep in mind that an automatic transition to a different server will not be set if there's no range of DN-s. For example, there are two servers - cucm1 with DN server for auto registration from 1000 to 1049 and cucm2 with DN from 1050 to 1099. If cucm1 will be listed as the primary cucm server, then phones will be registered on it. Once the phone with DN 1049 will be registered, then next phone will receive Reject. To register phones on cucm2, they need to specify it as the primary cucm. Therefore it is better to configure the auto registration on the one server only.
  • If SIP is specified in Enterprise Parameters, as the default protocol for auto registration, when you try to automatically register SCCP-phone, it will start to update firmware on SIP! And it also works backwards - if the SCCP is specified as the default protocol, the SIP phone will update firmware on SCCP. If the phone knows the one protocol only (for example, CP-9951 or DX650 knows SIP only), it will be registered on SIP, even if the default protocol is Skinny.
  • If CUCM cluster is in the mixed mode (a mode that allows to include the encryption of voice traffic), then the auto registration will not work for security reasons.
  • And finally, Cisco Systems recommends using the auto registration only if you need to add less than 100 phones; if you need to add more, then use Bulk Administration Tool. For security reasons it is also not recommended to keep auto registration always enabled, you should enable it only as needed, so Cisco says.

That's all. I hope this article will be useful. If you have any questions, please, write them in the comments.

Working with Cisco Unified RTMT

Cisco Unified RTMT (Real-Time Monitoring Tool) is used to monitor various CUCM parameters, Performance Counters, and to collect Traces.

Performance Counters contain simple information on the system and devices on the system, such as number of registered phones, number of active calls, number of available conference bridge resources etc.

RTMT requires a PC running Windows or Linux and uses HTTPS and TCP to monitor the Device Status, System Perfomance, Device discovery, CTI Applications in the CUCM cluster.

Not only the CUCM admin can work with RTMT: it’s enough to include any user in the standard Standard CCM Server Monitoring group.

RTMT offers a wide range of features but we won’t review all of them here. In everyday life we need a much smaller number of counters which we will list in the next section.

Useful Performance Counters

CountersPathDescription

General information on the system:

  • Memory Usage
  • CPU Usage
  • HDD Usage

System > System summaryThese parameters give an overview of the system status
The processes running on the serverSystem > Server > ProcessTo understand which process causes the high CP load

General information on CUCM:

  • Registered Phones
  • Call InProgress
  • Active MGCP Ports

Call Manager > Call Manager SummaryThe abrupt changes of these parameters may be a sign of some problem

Call processing activity:

  • Call Activity
  • Gateway Activity
  • Trunk Activity
  • Sip Activity

Call manager > Call ProcessThese graphs give an idea about the total number of calls and the gateway activity

Device information:

  • Phone
  • Gateway Devices
  • H.323 Devices
  • Media Resources
  • SIP Trunk

Call Manager > Device

The very useful information that provides and the detailed parameters of each device.


For example – device models, firmware versions, IP addresses, user association etc.
Conference Bridge resources

Stand Alone Cluster -> node name -> Cisco HW Conference Bridge Device

Stand Alone Cluster -> node name -> Cisco SW Conference Bridge Device

  • HWConferenceActive – the number of active conferences
  • ResourceActive – the number conference participants
  • ResourceAvailable - the number of available resources

Gives an idea about the Conference Bridge activity, but not for each conference

Alerts

RTMT supports Alerts, which are triggered under certain conditions.

RTMT includes the set of pre-installed Alerts (System > Tools > Alert > Alert Central) which provide a great benefit in terms of a quick inspection of the system.

If you see "alarm" in this list it certainly makes sense to check what caused them.

In addition to pre-installed ones, you can create your own Custom Alerts.

Let's create the Alert, which is triggered when the resources of the Hardware Conference Bridge are over. This one is useful to monitor the availability of CUCM conferencing features Meet-Me, Ad-Hoc and Conference Now (implemented in CUCM 11).

We will use the ResourceAvailable Counter mentioned in the table above.

So, to create Alert:

1. Open the appropriate counter, select it, then right-click on it and choose Set Alert / Properties
2. Select the alarm level and enter its description
3. Set the triggering condition - "Under 1".
4. The next screen allows to set up the Alert frequency. In order to keep e-mail box from being hammered we will choose no more than once per hour.
5. Next step is to configure the e-mail address for notification
6. Do not forget to configure e-mail server properties:
System > Tools > Alert > Config Email Server

That’s it.

Syslog Viewer

Syslog Viewer is the analogue of Windows Event Viewer. If something is wrong with the system it’s one of the first interface to look at.

System > Tools > Syslog Viewer

Syslog Viewer allows you to view the messages from the following logs:

  • System Logs - everything that concerns hardware and OS.
  • Application Logs – CUCM logs
  • Security Logs - user login attempts.

Trace & Log Central

Trace & Log Central collects and displays various traces and log files:

  • CUCM SDL and SDI traces
  • SDI (System Diagnostic Interface) are used for log analysis
  • SDL (Signal Distribution Layer) are mainly used when opening cases in the Cisco Technical Assistance Center (TAC).
  • CUCM application logs (for example, BAT logs)
  • System logs

Trace & Log Central works in the following modes:

  • Remote Browse - displays files directly from remote servers.
  • Collect Files – collects traces and downloads them to the PC with RTMT installed.
  • Query wizard – work with trace files containing the query string.
  • Schedule Collection - scheduled trace collection
  • Local Browse - view traces collected on the local drive
  • Collect Erash Dump
  • Real time Trace - trace view in the real-time

The Trace & Log Central can collect tons of data. You can use the following tools to simplify the SDI files analysis.

Performance Monitor and Data Logging

As already mentioned, Performance monitor contains a lot of different counters.

We have already learned to configure Alert to be triggered on the certain Counter by the right-clicking on the counter.

In addition, we can setup the counter logging – right click on the counter and select

  • Start Counter Logging

Once the logging is configured you’ll be able to view logs with Performance Log Viewer.


How We Improved Our CUCM (CallManager) Phone Directory

Hi, I’m Kirill Basikhin, international key account manager from Aurus. Here, at Aurus, we develop a bundle of applications for Cisco Unified Communications Manager. And, yes, we do use our products, because they help us work faster, smarter and easily.

This post is not going to be a promotional one, I’ll just describe the way we setup the enterprise CUCM directory with our product. Each paragraph below is a real-life daily use-case.

The important feature used in all cases below is that our phone directory is integrated with CRM, so every contact I create in CRM automatically appears in the enterprise CUCM directory with phone numbers, manager (me or one of my colleagues) name, city, products purchased (or interested in).

Incoming Calls from my Clients Get Routed Directly to Me

We’ve got UCCX installed that receives any incoming call. A simple UCCX script sends the caller’s phone number to the CUCM directory software (PhoneUP Directory). The phone directory searches its database for the client number provided and sends the response to UCCX containing the phone number of manager (me), responsible for this client. UCCX then just forwards the call to me.

So, every time my client calls Aurus he reaches me automatically. Cool? Yep!

What if the Caller is Unknown?

If UCCX does not receive the phone number to transfer the call to, it routes it to the reception (actually one of the marketing managers, we’re not a huge company). The girl receiving the incoming call gets a CAD (yeh, we still use the old-school Cisco Agent Desktop) popup with the list of employees to whom calls from the calling party were transferred most often (PhoneUP Operator).

So when my aunt from Germany calls Aurus again (she doesn’t call my mobile, its expensive) the girl receiving the call gets a list with my name only (cause my aunt called previously and asked for me). Then she just clicks my name to forward the call.

How do I Handle Calls from my Clients

When the call reaches me, my Cisco IP phone shows the client name, the city and the product(s) purchased (remember, the CUCM phone directory is synchronized with our CRM).

So I can greet the client, saying “Hi John, Kirill speaking. I can’t believe you finally tested PhoneUP!”.

After all I’m a sales man and every smile on my client’s face will finally turn to another penny in my pocket.

How do I Call my Client

Our Cisco UCM phone directory provides the search interface on Cisco IP phone, but typing the client name using the IP phone keypad makes me wanna die (though several my clients do use it!). I usually make calls in 2 ways:

  • when I work with client card in CRM, I just click the client’s phone number to call him; this is the simple click2call feature but what is REALLY useful is that our click2call supports DTMF – even if the phone number is stored unformatted (like “+1 (408) 526-7209 ext.. 4576”) the CUCM directory software calls the PSTN number, waits for the answer and then dials the DTMF;
  • when I just want to call some person, I push “Ctrl-Q” to activate the “PhoneUP Agent” and use it to search the contact and make a call, the DTMF also works.

My colleagues use Cisco Jabber and its phonebook is also integrated with CRM, but I’m old and I use the old-fashioned IM client.

How do I Lunch


When I’m quitting for the lunch, I just lock my PC. What happens then is that my Cisco IP phone automatically locks its keypad (PhoneUP Lock feature) and activates the “Forward All” mode.

So, all calls from my clients are forwarded to my mobile.

When back to my workplace I unlock my PC and my Cisco IP phone goes to the normal mode.

How do I Manage Missed Calls

At the end of working day I do not setup the Forward All, cause most of my clients do not bother themselves about the time shift.

When I’m back to the office the next day, my Cisco IP phone shows the list of missed calls (XML-service provided by PhoneUP Directory).

What is important, this list contains names of clients called. So I know who called me and I can check the CRM before calling back.

CUCM Troubleshooting: Availability Issues

In this article we discuss some issues of the CUCM environment troubleshooting.

This time we will consider the aspects of CUCM availability.

So, your CUCM responds slowly or doesn’t respond at all. Why?

CUCM does not respond to endpoint requests

When the Primary CUCM slows down or even dies IP phones and/or gateways lose the registration. When taking the receiver off the hook the tone appears with delay or does not appear at all.

The most likely reasons for this are:

  • The CUCM server hung on the OS level and requires a reboot.
  • The Cisco Call Manager service hung. Also, there may be problems with the Cisco TFTP Server service responsible for the phone configuration loading. Check the status of both services (Serviceability > Tools > Control Center> Feature Services). Causes of the problems can be found in System logs .
  • High CPU load of the CUCM server. Check the CPU Usage to understand what process should be blamed.
  • A memory leak - you need to check the memory usage.

CUCM System logs

CUCM is an appliance based on Linux, and it does not provide a regular access to a full Linux console, therefore System log can only be viewed through RTMT.

We need a Syslog Viewer - the analogue of Windows Event Viewer. If something is wrong with the system it’s one of the first interfaces to look at.

System > Tools > Syslog Viewer

Syslog Viewer allows you to view the messages from the following logs:

  • System Logs – everything that concerns hardware and OS
  • Application Logs – CUCM logs
  • Security Logs – user login attempts etc.

Read more about working with RTMT here: Working with Cisco Unified RTMT

If you have problems with the Cisco Call Manager service, then the following messages can appear.

When the connection with the service is lost:

The Cisco CallManager service terminated unexpectedly. It has done this one time. The following corrective action will be taken in 60000 ms. Restart the service.

Timeout 3000 milliseconds waiting for Cisco CallManager service to connect.

If you have problems with the launch:

The service did not respond to the start or control request in a timely fashion.

High CPU

Cisco Call Manager service may stop responding because of a system resources (processor or memory) overloading.

Most often it occurs at a high CPU load.

We can monitor the CPU load in two ways:

  • CPU monitoring in CLI.
    The average CPU load can be seen by executing:
    show stats io
    show perf query class Processor

    CPU load by processes:
    show perf query counter Process "% CPU Time"
    show process load
  • CPU monitoring in RTMT
    This can be checked in the general information on the system:
    System > System summary

CUCM Administration page is not displayed

If the CUCM admin page (https:///ccmadmin) does not open:

  • First try to clear the browser’s cache
  • Check the network settings, try to ping the CUCM IP
  • If the CUCM is accessed by name, check the DNS, and whether the name resolves correctly
  • Make sure the Cisco Tomcat service is running
  • Check Firewall and Access Lists settings
  • Check the CPU load on the CUCM node

Checking Cisco Tomcat service

Use CLI to check the status of the service:

utils service list

Launch it if necessary:

utils service start Cisco Tomcat

Slow Server response

The slow server response may cause: the delay to receive the dial tone, delays in opening the admin/user web-interfaces, delays in dialing.

The possible reasons are:

  • The CUCM server and the switch have different Speed / Duplex.
    Check the settings on the server and the switch. Try to set Auto for both.
  • High CPU load or Memory leak. Check the CPU usage.
  • Also, the wrong Dial plan may cause delays in dialing.

Network Settings

The CUCM network settings may be checked with the CLI command:

show network eth0

You can change the value of the duplex or speed in CUCM by executing:

set network nic eth0

To view the switch network settings execute:

show interface fa 1/0