PostgreSQL Database as a Caller ID CRM for Cisco Callmanager

Feature Overview

Call Telemetry's policy engine processes CURRI API call events from Cisco Callmanager for caller id modification. External Call Control Policies then trigger Call Apps like this CRM Connector to lookup caller ID name from any database. This example queries a student database for the caller's name from PostgreSQL Database.

If you have another database you would like to integrate with, please let us know.

For additional reference, you can review our Cisco Callmanager SQL as CRM Video walkthrough (opens new window) here.

Feature Requirements

• Call Telemetry Appliance 0.7.0 or later
• Call Telemetry Premium (opens new window) License
• Cisco Callmanager 8.5 with CURRI API Integration to Call Telemetry
• Configured External Call Control Profile Inspection - A route pattern, translation pattern, or phone extension must be enabled for Call Telemetry Policy inspection. If Call Telemetry is not inspecting the call, it will not be able to see the ip phone call history.

Configuration Steps to integrate with PostgreSQL

At a high level, the steps to integrate with PostgreSQL are:

• Add a Call Rule with a trigger pattern
• Create a PostgreSQL App for your CRM
• Associate the CRM App to Rule
• In the Call Rule, set the Calling Party name field to reference data from your App
• Test the call

Step 1: Creating a Call Policy and Rule Trigger

Follow the setup guides to create a Policy and Rule, and integrate to your CUCM. Policies and Rules are generic for any App.

In this example below, our rule will match all calling and called numbers, and trigger on all calls with the .* pattern. You could use any pattern you like, such as a specific DID, or a range of DIDs.

As we close Step 1, should have a Policy and Rule setup, and a trigger pattern configured. Your policy should be "Registered", and you should be seeing hits on the Policy. You can verify this by reviewing your Call Policy History also.

If you're new to setting up Policies and Rules, you can follow these guides:

• Call Policy and Extended Call Control Profile Configuration
• Call Policy Rule Trigger Setup

Step 2: Create a PostgreSQL Call App

With the Policy and Rule in place, we can now add a PostgreSQL App. Call Apps are added globally, and can be used in any Rule.

To create a PostgreSQL App:

• Click the Realtime Policies menu then click the Apps link.
• Choose Add to create an new App.
• Choose the PostgreSQL under Realtime tab to open a new Add Dialog.
• Enter a name for your App, and a description.
• Enter the connection string to your PostgreSQL database. This is the connection string that your PostgreSQL client uses to connect to the database. It should look something like this: host=yourhost dbname=yourdb user=youruser password=yourpassword
• Enter a valid PostgreSQL query that returns one value. Our query below is designed to return a single value - the caller's name.
• Save the App.

Below is a screenshot of the PostgreSQL App query we used in this example.

Step 3: Add the PostgreSQL App to your Rule

Now that you have a PostgreSQL App, you can add it to your Rule. This will allow you to reference the data returned from the PostgreSQL query in the Rule Modifier.

Use the + button to add the PostgreSQL App to the Rule. You can add multiple Apps to a Rule, and reference the data from each App in the Rule Modifier fields in the next step.

Below is a screenshot of the process of adding our PostgreSQL App to a Rule.

Step 4: Run Call Test to ensure we get results from the CRM

You can see the results from the API under the JSON Key app_data.lookup.data.results This is the key you can use to reference the data in the Rule Modifier.

Step 5: Reference the data from the PostgreSQL App in the Rule Modifier

You can reference this inside the Rule Modifier as a vaiable, and it will substitute the returned value into the modifier field - changing the caller ID name.

Step 6: Verification

Run a call test to verify the caller ID name is replaced with the value from the PostgreSQL query.

You can see in the raw CURRI API output on the right side of the screen. Here we can see the caller ID name was replaced with the value from the PostgreSQL query.