CRM Integration for Caller ID with HTTP Webhooks

Feature Overview

Call Telemetry's policy engine processes CURRI API call events from Cisco Callmanager for caller id modification. External Call Control Profile Policies then trigger Apps to lookup caller ID name from any JSON API.

You can use Call Telemetry to integrate your Cisco Callmanager with nearly any CRM platform, and get a caller's name to replace on your Cisco IP Phones. This example uses the Star Wars API (opens new window) as our CRM platform. They don't have phone numbers, but the concepts work exactly the same for any CRM API.

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

Steps to complete your CRM Integration

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

Step 1 - Create Policy and Rule

Follow the Extended Call Control Profile Policy Guide to create a Policy and Rule, and integrate to your Cisco Callmanager. This integration will be using the CURRI API to inspect calls and modify the caller ID name.

Once our policy has registered, it means that our Cisco Callmanager CURRI API is online. As covered in the guide above, go ahead and assign it to a Cisco IP Phone extension to keep this example simple.

Next we want to build a rule to trigger on all calls and run our Webhook Caller ID Lookup App. Matching Rules use Regular Expressions, and below is an example of a rule that will trigger on all calls.

Your rule should look like this:

Step 2 - Add a HTTP Webhook App

We can now add a Webhook App. Apps are added globally, and can be used in any Rule. Webhooks can be triggered as a realtime App, or a post call action app. Post Call Apps cannot change the Caller ID, so we will use a Realtime App.

To create a Realtime HTTP Webhook App:

• From the sidebar, click the Realtime Policies menu, then click on Apps.
• Click Add to create an new App.
• Choose the Webhook under Realtime tab.

Enter your Webhook API Details for your CRM

Fill out the form with the following details:

• Enter a name for your App, and a description.
• Enter the URL of your API. In this example, we are using the Star Wars API. You can use even variables to lookup against the API. In this case, we tell Webhook to use the event.calling_number within the URL parameter.
• Enter the HTTP Method, in this case we are using GET.

Associate the new Webhook to your Rule

Now that we have our Webhook App, we can associate it to our Rule. This will allow the Rule to use the Webhook to lookup the caller's name.

Navigate to Policies, your CRM Rule, and Open the rule we created. Associate the Webhook to the Rule as shown below.

Step 3 - Review and Test your CRM API

Let's review what we have done so far:

• We created a Policy that is registered with our Cisco Callmanager.
• We assigned the Policy to a Cisco IP Phone.
• We created a Rule that will match all calls.
• We have associated the Webhook to the Rule.
• We created Webhook App that will lookup the caller's name from the Star Wars API.

We are finally ready to test our call, and see the results from the Webhook CRM API, and use that data to change the caller ID name.

Run Call Test to discover the API Results

Now, we can run a Call Test to see how Call Telemetry would process this call. This test will also include the Webhook API call, and show the results from the API. We need this to verify that our Webhook is working as expected, and to map out the exact fields we want to use in our Call ID Rule.

You can see the results from the API under app_data.webhooks.data. We can reference any of those values, but the one we are interested in is the name field. This is the key you can use to reference the data in the Rule Modifier.

TIP

To be successful with the Star Wars API, we need to remember that people are numbers starting with 1 (Luke Skywalker). So make sure your call test is setup with the calling number of 1 as shown below.

Reference the data from the Webhook App in our CRM Rule

We can now assign that value to the Calling Name by it's workflow variable path - app_data.webhook.data.name. This will substitute the returned value into the modifier field - changing the caller ID name.

CRM Verification

If we run the Call Test again (calling: 1, called: anything), we can see that the raw Cisco CURRI API response contains the name to be used - Luke Skywalker, and this will show on on your Cisco IP Phones.