Skip to main content

CUBE Integration with Call Telemetry via XCC API

Call Telemetry connects to Cisco CUBE over the XCC API so you can enforce voice policies, fire alerts and webhooks in real time, and stream edge call-quality metrics into the same appliance.

This guide walks through adding a CUBE, configuring peer inspection, wiring the router remote-url, and verifying registration.

Feature Overview​

Cisco Unified Border Element (CUBE) exposes the Extended Call Control (XCC) API (also documented by Cisco as CUCISAPI — we use XCC). An external application can inspect and act on calls as they traverse the CUBE, with built-in keepalive and fail-open behavior so calls continue if the application path is briefly unavailable.

Cisco XCC API documentation

For dashboards, MOS/jitter/packet-loss reporting, and peer health, see CUBE XCC Analytics and the product overview at CUBE & CMR Analytics.

Feature Requirements​

XCC Integration Process​

Adding a Cisco CUBE XCC Integration​

  1. Log in to your Call Telemetry dashboard
  2. Open Cubes → CUBE XCC Dashboard (CUBE Management)
  3. Click Add CUBE

Screenshot of the Add CUBE control on the CUBE XCC Dashboard

Screenshot of Create Cube XCC Application — XCC Integration tab

Configuration Fields​

  • CUBE Name: Unique, descriptive identifier (e.g., HQ-CUBE-01)
  • XCC Hostname or IP Address: Address Call Telemetry uses to reach the CUBE XCC provider
  • Enable XCC Integration: Activates or deactivates the XCC session
  • CUBE Analytics Enabled: Collects call-quality metrics (MOS, jitter, packet loss)
  • Enable Policy Enforcement: Real-time policy checks; configure Peer Inspection below
  • XCC Disconnect Code: SIP response used when blocking (suggested: 603 Decline)
  • Blocking Response Timeout: Seconds to wait for a blocking decision
  • Blocking Timeout Action:
    • Continue Processing: Allow the call to proceed
    • Release Call: End the attempt
  • XCC Keepalive Interval: Keepalive period in seconds (recommended: 10–30)
  • Admin Alerts for Restarts: Notify when the XCC application restarts
  • XCC Calling Number Field:
    • callingAddrData: Current calling number
    • origCallingAddrData: Original calling number before translations
  • XCC Called Number Field:
    • calledAddrData: Current called number
    • origCalledAddrData: Original called number before translations

XCC Traffic Policy Filtering​

XCC can inspect Call Telemetry policies in inbound and outbound directions. Add peer IP addresses (or CIDR ranges) to the XCC Peer Filter fields — similar to a Cisco VoIP trust list.

Direction is from the CUBE’s perspective. For example, Twilio SIP peers listed as Inbound are inspected on calls arriving from those peers. Listing your CallManager clusters as Outbound inspects calls leaving the CUBE toward those peers.

tip

Inspect in one direction only; leave the other blank. The default policy action ignores and permits calls that do not match.

Screenshot of XCC Peer Inspection filters

Review settings and click Submit to add the CUBE.

XCC Application URL​

After saving, reopen the edit dialog. Call Telemetry shows the generated XCC Application URL. Configure that URL on the CUBE as the XCC remote-url.

The Application URL is currently generated as http://<appliance-hostname>:80/api/xcc/<cube-id>. Keep the explicit :80 — CUBE XCC matches remote-url as an exact string. Use the appliance’s reachable hostname, not a lab API bind port.

XCC Application URL on the Edit Cube dialog

Configure the Cisco CUBE Router​

ip http server
http client connection persistent
uc wsapi
probing interval keepalive 10
provider xcc
remote-url (use the URL from the Edit Cube dialog)
no shutdown

IOS Router Call Quality Configuration​

On CUBEs you want to monitor, enable call quality statistics so P-RTP-Stat headers feed analytics (Cisco IOS Call Quality Monitoring Docs):

voice service voip
callmonitor
rtcp all-pass-through
media statistics
media bulk-stats
call-quality
max-dropout 100
max-reorder 100

CUBEs then stream disconnect and quality metrics into the CUBE XCC Analytics dashboard.

Configuration Notes
  • SIP-to-SIP calls only: Call quality statistics apply to SIP-to-SIP legs
  • RTCP dependency: Round-trip delay needs RTCP from remote endpoints
  • P-RTP-Stat: These settings enable P-RTP-Stat headers in BYE/200 OK messages

XCC Network and Firewall Configuration​

The CUBE must reach Call Telemetry on the network.

Call Telemetry registers to the CUBE on TCP 8090 (plain HTTP by default). Call-processing requests from the CUBE to Call Telemetry use the Application URL — typically TCP 80.

Verify CUBE Registration​

  1. Return to Cubes → CUBE XCC Dashboard
  2. Confirm the CUBE status shows Online (or Healthy) after the router registers

CUBE XCC Dashboard with registered CUBEs

CUBE Management​

Viewing CUBE Status​

The dashboard lists each integrated CUBE with:

  • CUBE Name
  • XCC Hostname
  • Registration / health status
  • Quality sparklines (MOS, jitter, packet loss) when analytics is enabled
  • Peer health summary

CUBE Actions​

For each CUBE XCC service you can:

  • View metrics / logs: Open event logs and quality views for troubleshooting
  • Reconnect: Force a new registration attempt
  • Delete: Remove the integration (confirmation required)

Event Logging​

Event Logs include timestamp, event type, status, message, registration and transaction IDs, XCC response, IP address, connection and call IDs, calling/called numbers, and disconnect codes.

Filter by event type, status, or custom conditions when isolating registration or policy issues.

CUBE XCC Event Logs

Troubleshooting​

  1. Verify CUBE configuration — XCC settings on the router match Call Telemetry; remote-url matches the Application URL.
  2. Check connectivity — Firewall allows CUBE ↔ Call Telemetry on the ports above; ping or TCP test as needed.
  3. Review Event Logs — Look for failed registrations or policy timeouts.
  4. Reconnect — Use Reconnect on the dashboard to force registration.
  5. IOS debugging — debug wsapi xcc all on the CUBE while reproducing.