• Part 1
• Part 2
• 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:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-3/Cisco-Meeting-Server-Single-Server-Simplified-Setup-Guide.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-4-and-later-Deployments-with-CUCM.pdf
• cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-4/Cisco-Meeting-Server-MMP-Command-Reference-2-4.pdf

Read also:

• Part 1 - Integration of Cisco Meeting Server with CUCM 11
• Part 2 - Integration of Cisco Meeting Server with CUCM 11
• Part 3 - Integration of Cisco Meeting Server with CUCM 11

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

• Part 1
• Part 2
• Part 3

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:

• Part 1 - Integration of Cisco Meeting Server with CUCM 11
• Part 2 - Integration of Cisco Meeting Server with CUCM 11
• Part 3 - Integration of Cisco Meeting Server with CUCM 11

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

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:

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

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

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.

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.

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.

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.

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.

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.

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.

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 Profile – Cisco Dual Mode for Android – Standard SIP Non-Security Profile

SIP Profile – Standard 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:

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>

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.

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.