Configuration For Curri - ECC

Additional configuration when using ECC-CURRI

System Requirements for External Call Control - CURRI

• Cisco Unified Communications Manager 8.0(2) or higher
• Imagicle Application Suite Winter 2014 edition or later

Imagicle Application Suite Configuration

Go to the Imagicle Application Suite Web configuration portal, Phone Lock -> Global Settings

Choose Cisco External Call Control (also known as CURRI) as Block engine technology. You will need the Cisco External Call Control URI generated from web page for configuring External Call Control Profile URI later, in Cisco CallManager configuration. The URI will be similar to:

 http://<Imagicle_server_IP_address>:80/fw/ecc.ashx

Note: you must enter the URI generated form this page. If you enter a different URI (e.g. without the specified port) the configuration won't work.

Note: Phone Lock ECC-CURRI method does not allow to lock overlapping phone lines, even on different partitions. This feature is available starting from Imagicle 2020.Spring.1 release, only when using TAPI method.

Cisco CallManager ECC Configuration

Warning: Due to a Cisco CallManager known issue, every modification on a External Call Control Profile requires a Cisco CallManager service restart. This can drop all the calls in progress.

External Call Control Profile

The External Call Control Profile (ECCP) is how Imagicle Application Suite is linked with Unified CM. Configuring an ECCP adds your application's URL to the Unified CM database. The ECCP can then be added to Trigger Points in Unified CM. Available Trigger Points are:

• Translation Pattern (CM 8.0 (2) or higer)
• Route Pattern (CM 10.0 or higer)
• Directory Number (CM 10.0 or higer)

When one of this Trigger Points is involved in routing process (e.g. a phone makes an outgoing call and tries to pass through a Translattion Pattern) Unified CM sends a request to the ECCP configured link (Imagicle Application Suite) that elaborates the request and answers making a routing decision. The possibile decisions are:

• Continue: the call will be routed applying the involved triggering point
• Deny (i.e. block with optional message): the involved triggering point is not applied and unified CM stops call routing
• Divert call

Warning: The Directory Number ECC profile is triggered only for incoming calls (i.e. calls that ring on that DN). Besides, calls routed to the DN by an Hunt pilot do not trigger the ECC profile call.

Configuration in UCM

In Cisco Unified CM Administration, specify the following information in the Call Routing -> "External Call Control Profile Configuration" window:

• Name of the External Call Control Profile (ECCP)
• Primary Web Service: URI of the Imagicle Application Suite (the one generated during Application Suite configuration in Global Settings page)
  - permits configuration of two URIs, for redundancy (active & standby) and for load balancing (where Imagicle High Availability options is available)
  - supports HTTP
• Timeout value for call routing response (suggeste value is 5000 ms)
• Diversion rerouting calling search space: this CSS is applied in case of diversion to a number for a blocked call
• Call treatment on failures: choose the treatment if Imagicle Application Suite is unresponsive o response timeout has been reached (Allow Calls is suggested)

Trigger Points

A Trigger Point is the point in Unified CM's routing logic at which Unified CM issues a Route Request.

• Translation Pattern trigger points are available in Unified CM 8.0(1) and later
• Route Patterns and Directory Numbers are trigger points in Unified CM 10.0 and later

Enable ECCP in Translation Pattern Trigger point

Enable ECCP in Route Pattern Trigger Point (In Unified CM 10.0 and later)

Enable ECCP in Directory Number Trigger Point (In Unified CM 10.0 and later)

CM Configuration Guidelines

The most used trigger point is Translation Pattern (the only one available until Cisco CallManager version 10.0).

if you want the External Call Control (also known as CURRI) web service to be used in call routing you must be sure to involve the translation pattern in call flow. Following schemas represent a simple standard configuration in a Cisco CallManager environment:

In this example, we have a phone with a Directory Number contained in IP-PHONE partition and with ALL-PHONE Calling Search Space. ALL-PHONE includes IP-PHONE and OUTGOING partitions. In this simple case any Directory Number in partition IP-PHONE could call any phone in IP-PHONE partition or any External number starting with 0.

Call Flow examples:

Introducing translation pattern for triggering External Call Control schema should change:

The changes are:

• Create the translation pattern with External Call Control Profile and Calling Search Space ALL-PHONE
• Create a new partition, CURRI, that includes the just created translation pattern
• Create a new Calling search Space, CSS_CURRI, that includes CURRI partition, but no IP-PHONE partition
• Change the Directory Number Calling Search Space to CSS_CURRI

The call flows become:

Note: be careful with CSS and Partition configuration, a wrong configuration could lead to call loops that can give telephony inefficiency or deteriorate your PBX and Imagicle Application Suite performances

Blocking incoming calls with ECC - CURRI

To block the incoming calls, the guidelines are similar. Starting with a simple standard configuration, with an incoming route pattern that routes the calls to internal phones as shown below:

If there are Translation Patterns in the flow (E.g. for translation from E164 to internal number) the solutions is easy, just add an External Call Control Profile to the involved translations in order to have a ready to use system. 

In case no Translation Patterns are involved, it is necessary to insert a new level in Numbering Plan as we did for outgoing calls. You need to:

• Create the translation pattern with External Call Control Profile and Calling Search Space ALL_IP_PHONES
• Create a new partition, CURRI, that includes the just created translation pattern
• Create a new Calling search Space, CSS_CURRI, that includes CURRI partition, but no IP-PHONE partition
• Change the incoming Route Pattern Calling Search Space to CSS_CURRI

Play a message when a call is blocked

In order to play a message to the caller when a call is blocked, you must first enable "IP Voice Media Streaming" service:

• Access to CUCM "Cisco Unified Serviceability" web portal and select Tools → Service Activation
• Make sure that "Cisco IP Voice Media Streaming App" is Activated

Then you should upload a file from Cisco CallManager Administration web portal, in the Media Resources → Announcement web page:

Add a new Announcement, filling the required fields as shown below:

After the Announcement creation, you have to upload a sound file.

Note: Announcements are specific to the locale (language). If your installation is using more than one language locale, each custom announcement must be recorded in each language as a separate .wav file and uploaded with the correct locale assignment. This also requires that the correct locale package be installed on each server before uploading custom announcement wav files for languages other than United States English.

The recommended format for announcements includes the following specifications:

• 16-bit PCM wav file
• Stereo or mono
• Sample rates: 48 Khz, 44.1 Khz, 32 Khz, 16 Khz or 8 Khz

You can upload one different file for each Local installed in your Cisco CallManager

After file upload you have to insert the Announcement identifier in the Imagicle Application Suite Web interface, PhoneLock Settings page, as you created in Cisco CallManager (in the example "ecc-curri-block-message")

From now on every blocked, the caller will hear the uploaded message.

Warning: Diversion is not compatible with Message playback, so if you specify both a block message and a diversion number, the External Call Control (Curri) plugin will only redirect the call without playing any message.

Divert blocked calls

You can divert a blocked call to a number (E.g. voicemail), the number is system wide and you can configure it in Imagicle Application Suite Phone Lock Global Settings Page.

It is also necessary to specify a Diversion Rerouting Calling Search Space, used for call diversion of a blocked call

The Diversion Calling Search Space will be used as Calling Search Space for the diverted call, so be sure that the redirection number is contained in that Calling Search Space. In the following images we modified the two standard architectures described above with a Voicemail diversion.

In first image Voicemail number belongs to the same Calling Search Space of the Translation Pattern, so there is no need to specify a new Calling Search Space, it is possible to use the phones one as Diversion rerouting Calling Search Space.

Translation Pattern and External Call Control Profile must be configured this way:

In second image Voicemail number belongs to a different Calling Search Space, that includes only Voicemail numbers, so there will be the need of specify VOICE_MAIL as Diversion rerouting Calling Search Space.

Translation Pattern and External Call Control Profile must be configured this way:

NOTE: If you try to divert a blocked call to a number without specifying a Diversion rerouting Calling Search Space, Cisco CallManager will try to reroute the call with Calling Search Space=NONE, that will probably let the call run into a service unavailable pattern.

NOTE: Diversion is not compatible with Message playback, so if you specify both a block message and a diversion number, the External Call Control (Curri) plugin will only redirect the call without playing any message.

Notes on CuCM performance

Unified CM experiences some degree of performance degradation if it queries route servers for a majority of incoming calls.

The performance degradation depends on the following factors:

• Response time from route servers
• Network latency for call routing requests and responses

Slow response or network latency adds delay to the post-dial silence for a call. Testing shows that when the response time from the route server is below 50ms (RTT), there is a 15% degradation in the maximum call rate when all calls are subject to a Route Request/Response.

Call Block History & Basic Troubleshooting

A complete list of Calls processed by the Imagicle Application Suite External Call Control (CURRI) web service is accessible at the Phone Lock Calls History Web Page. This web page reports the full list of processed requests. It is possible to filter on a specific date, check the call resume (Time, calling, caller, decision and reason) and go deep in a single request opening the call detail. Here you can check the HttpRequest arrived at the web service, the HttpResponse given back to the Cisco CallManager and the specific Application Decisions taken by the Phone Lock Enterprise Service.
For a full list of call block reasons please refer the table at the end of this article. 

Basic functional test

Make a call from an unlocked phone, verify that:

• Call passes
• Call is visible in the Calls History, with decision Continue

Lock phone and make a call to an unlocked phone, verify that:

• Call is blocked
• Call is visible in the Calls History, with decision Deny

For more Phone Lock troubleshooting tips and information please refer to this section. 

Calls History Call Block Reasons Reference