CRM & Contact Resolution
Call Telemetry resolves caller identity in real-time using your existing directories and databases. When a call arrives, the system looks up the caller's name, company, and department — and displays it on your Cisco IP phones before anyone picks up. Contact resolution runs through the same CURRI policy engine as call blocking, routing, and alerting, so you configure everything in one place.
How Contact Resolution Works
Call Telemetry checks multiple sources in order of speed, returning the first match:
| Priority | Source | Typical Speed | Best For |
|---|---|---|---|
| 1 | Cache | Typically under 1 ms | Repeat callers — most lookups hit cache after the first call |
| 2 | Local Database | Typically under 5 ms | Manually entered, CSV-imported, or API-synced contacts |
| 3 | External Provider | Typically under 200 ms | LDAP, REST API, PostgreSQL, or webhook lookups (depends on your network and provider) |
When a match is found at any tier, Call Telemetry changes the caller ID in real-time — replacing the raw phone number with the contact name before the call reaches the phone.
If no provider returns a match, the call proceeds normally with the original caller ID — resolution never blocks or delays a call.
Data Sources
Call Telemetry supports multiple contact data sources. You can use one or combine several — the resolution engine checks them in priority order and returns the first match.
| Source | How It Works | Best For | Guide |
|---|---|---|---|
| Local Contacts | Add contacts through the UI or bulk-import from CSV. Stored on the appliance. | Customer lists, phone directories, CRM exports | Local Contacts |
| LDAP / Active Directory | Queries your directory live during each call — no sync or data duplication needed. | Enterprise employee directories | LDAP Contact Resolution |
| REST API | Sends the caller's number to any HTTP endpoint and maps the JSON response to caller ID. | Salesforce, ServiceNow, custom CRMs | REST API, Webhook Walkthrough |
| PostgreSQL | Runs a SQL query against your database during the call and returns the result as caller ID. | ERP systems, student information systems, legacy databases | PostgreSQL Integration |
Compatible Services and Connectors
Call Telemetry connects to your existing systems using standard protocols — LDAP, REST API, PostgreSQL, and CSV. Any system that speaks one of these protocols works as a contact resolution provider.
Directories (via LDAP) Microsoft Active Directory, OpenLDAP, Azure AD, FreeIPA, Oracle Directory Server, Red Hat Directory Server
CRM and Service Platforms (via REST API) Salesforce, ServiceNow, HubSpot, Zoho CRM, Microsoft Dynamics 365, Freshdesk, ConnectWise, Zendesk, or any system with a REST/JSON API
Databases (via PostgreSQL) Any PostgreSQL-compatible database — ERP platforms, student information systems, patient management systems, custom CRM databases, billing systems
CSV Import Any system that exports contacts as CSV — PBX directories, spreadsheets, CRM exports, phone directories, HR systems
Requirements
- Call Telemetry Appliance 0.8.6 or later
- Call Telemetry Premium license
- Cisco CallManager with CURRI API integration configured
- Active Call Policy Inspection enabled on the route pattern, translation pattern, or phone extension you want to resolve
Contact resolution requires CURRI integration. CUBE XCC is monitor-only and cannot modify caller ID or inject contact data into the call.
Related Topics
- SIP Diversion Header Fix -- Resolve caller ID display issues when calls are forwarded through CUBE or Jabber
- Policy Design Guide -- How contact resolution fits into the CURRI call flow
- Call Apps Catalog -- All available policy apps including CRM integrations