CUCM - External Call Control Feature

Table of Contents

Use case scenario

Consider CUCM deployment in hotel/motel. In this deployment let’s look at two possible scenarios:

Scenario 1

In this scenario end devices (phones, Jabbers) are typically available to people who don’t belong to your organization. As usual people can make outbound calls with the default dialing policy (emergency, local, national). Sometimes people can buy premium services that will allow them to make international calls or premium calls. At the end the question is – how to dynamically adjust those settings.

From the engineering point of view – answer is very simple. Configure different Calling Search Spaces and the sign them to the phone line once customer buys premium service. From the business point of view – people will ask what Call Manager is and how I need to set those policies.

Of course, you can build a system which will simplify the process – for example integrates via AXL and changes line configuration. But remember every upgrade requires validation of the provided service.

We think that this approach is complex therefore we looked at External Call Control Feature.

Scenario 2

In this scenario we assume the hotel gest dials emergency number. Typical dial plan will allow to use this number and gest will be connected to Emergency Center to get the help. But in general, before service arrive it may be too late. So, the question is how we can improve the functionality of the system?

Again, we can look at the CUCM External Call Control Feature which will notify hotel room service that can react quicker that Emergency services.

In the next chapter you will find description of the solution that may well fit in both described above scenarios. At the end we decided to focus on the second scenario as it allows to save people’s lives.

Proposed solution

Below is a diagram that illustrates how the integration will take place:

To build this integration External Call Control (ECC) system will be used. Configuration for ECC is kept on External Call Control Profile. – which allows to set:

  • Primary/Backup server for external call control
  • Load balancing policy
  • What to do if external call control is not responding policy

ECC Profile can be assigned to multiple CUCM configuration objects. In case of the Emergency calls the best idea is to assign it to Route Patterns that route calls for Emergency Numbers. To ensure that every emergency call goes out from CUCM, allow all policy will be used in case when external call control is not responding.

ECC communication protocol is based upon XML. The full documentation of the protocol specs can be found here: Link.

If an emergency route pattern is triggered, ECC makes a HTTP/HTTPS call to external call control server. In the request the following parameters are provided:

External Call Control Server gathers the data and creates a new notification task. Meantime it responds back to CUCM to allow call.

Created notification task is put in the notification queue maintained by Notifier service. Because task message doesn’t contain too much information – only the calling number – if needed Notifier Service can pull additional information (Description, Phone SEP number) can be gathered via AXL API call to CUCM.

Based on the configuration notifier service will send notification using following communication channels:

  1. Email
  2. SMS (managed on Twilio)
  3. Call – messaged played by IVR once call is connected (managed on Twilio)

Each notification task and notification status will be written to internal system database for audit purposes.

CUCM External Call Control Feature

To enable External Call Control Feature on CUCM side user needs to add:

  1. External Call Control Profile (ECCP) that contains information about external call control server
  2. Assign ECCP to route patterns, translation patterns, etc. to trigger ECC feature.

Here is a picture taken from sample ECCP configuration:


The Primary Web Service and (optional) Secondary Web Service must be configured in the following format:

<protocol>://<ip address/host name>:<port>/<directory>

During the test we missed the and that caused failure. Here is a log snippet:

00354692.002 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath
00354692.003 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath token http
00354692.004 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath token http
00354692.005 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath token
00354692.006 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath token ecc
00354692.007 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath token Ecc.aspx
00354692.008 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath hScheme http, and hHost , and value size 4
00354692.009 |02:52:34.481 |AppInfo |HttpHandler(1,39,4): -setHostPortPath PORT IS MISSING
00354692.010 |02:52:34.481 |AppInfo |ConnectionFailureToPDP - A connection request from Unified CM to the policy decision point failed Policy Decision Point: The cause of the connection failure:Invalid URI is specified in the External Call Control profile App ID:Cisco CallManager Cluster ID:StandAloneCluster Node ID:cucm1
00354692.011 |02:52:34.481 |AlarmErr |AlarmClass: CallManager, AlarmName: ConnectionFailureToPDP, AlarmSeverity: Error, AlarmMessage: , AlarmDescription: A connection request from Unified CM to the policy decision point failed, AlarmParameters: PolicyDecisionPoint:, FailedToConnectReason:Invalid URI is specified in the External Call Control profile, AppID:Cisco CallManager, ClusterID:StandAloneCluster, NodeID:cucm1,

Here is a picture of a sample Route Pattern configuration. In red rectangle, place where to configure the ECCP profile:

The route pattern is 123 and it transforms called party number to 7700.

ECC Requests & Responses

Based on the above configuration CUCM sends the following message to external call control server:

<?xml version="1.0" encoding="UTF-8"?>
<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os">
  <Subject SubjectCategory="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:role-id" DataType="" Issuer="requestor">
    <Attribute AttributeId="urn:Cisco:uc:1.0:callingnumber" DataType="">
    <Attribute AttributeId="urn:Cisco:uc:1.0:callednumber" DataType="">
    <Attribute AttributeId="urn:Cisco:uc:1.0:transformedcgpn" DataType="">
    <Attribute AttributeId="urn:Cisco:uc:1.0:transformedcdpn" DataType="">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="">
    <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="">
    <Attribute AttributeId="urn:Cisco:uc:1.0:triggerpointtype" DataType="">

To allow call routing external call control server must respond in the following format:

<?xml encoding="UTF-8" version="1.0"?>
      <Obligation FulfillOn="Permit" obligationId="continue.simple">
        <AttributeAssignment AttributeId="Policy:continue.simple">
          <AttributeValue DataType="">
            <cixml version="1.0>


Cisco documentation link: