7.3 Cisco Unified Border Element (CUBE) Configuration & Redundancy

7.3 Cisco Unified Border Element (CUBE) Configuration & Redundancy

As enterprise voice communications transition entirely from legacy TDM circuits to IP-based Session Initiation Protocol (SIP) trunking, the Cisco Unified Border Element (CUBE) serves as the indispensable enterprise Session Border Controller (SBC). Operating natively on Cisco IOS XE platforms, CUBE acts as an intelligent, protocol-aware voice firewall and demarcation point between trusted enterprise internal networks (such as Cisco Unified Communications Manager or Webex Calling) and untrusted public networks (such as Internet Telephony Service Providers [ITSPs] or cloud communications clouds).

+-----------------------------------------------------------------------------------------+
|                        CISCO UNIFIED BORDER ELEMENT (CUBE)                              |
|                                                                                         |
|  +--------------------+                                           +------------------+  |
|  |   INTERNAL TRUSTED |                                           | UNTRUSTED PUBLIC |  |
|  |      NETWORK       |                                           |     NETWORK      |  |
|  |                    |        LAN Leg             WAN Leg        |                  |  |
|  |  +--------------+  |  SIP Signaling       SIP Signaling        |  +------------+  |  |
|  |  |     CUCM     |  |================> [ CUBE ] ================>  |  ITSP SIP  |  |  |
|  |  +--------------+  |                     /    \                |  |   SBC /    |  |  |
|  |                    |     RTP Media      /      \    RTP Media  |  |   CARRIER  |  |  |
|  |  +--------------+  |  (Call Leg 1)     /        \ (Call Leg 2) |  +------------+  |  |
|  |  | IP Endpoint  |  |<-----------------+          +------------>|                  |  |
|  |  +--------------+  |             [ Media Flow-Through ]        |                  |  |
|  +--------------------+                                           +------------------+  |
+-----------------------------------------------------------------------------------------+

---

1. CUBE Architectural Role & Core Capabilities

CUBE terminates and re-originates both signaling and media sessions at the enterprise perimeter. Its primary responsibilities include:

1. Demarcation & Security: Shields internal network topologies by hiding internal IP addresses, directory structures, and device types from the carrier (Topology Hiding). Prevents toll fraud via the ip address trusted list.
2. Protocol & Header Normalization: Resolves interoperability disparities between carrier SIP implementations and internal CUCM formatting using SIP profiles.
3. Media Interworking: Bridges disparate media streams requiring codec transcoding (e.g., G.711 to G.729), dual-tone multi-frequency (DTMF) conversion (e.g., RFC 2833 to SIP KPML), or media encryption conversion (SRTP to RTP).
4. Call Admission Control (CAC): Enforces bandwidth and call volume thresholds to prevent WAN link saturation.
5. High Availability: Delivers uninterrupted call continuity via active/standby stateful failover.

---

2. Global Media Flow Modes: Flow-Through vs. Flow-Around

CUBE can be configured in one of two fundamental media modes under voice service voip:

voice service voip
 mode border-element
 media flow-through   ! (Or 'media flow-around')

Media Flow-Through (Standard Enterprise Default)

In media flow-through mode, CUBE acts as a true back-to-back user agent (B2BUA) for both signaling and media:

• CUBE terminates the incoming RTP media stream on one interface (LAN), inspects and buffers the media packets, and re-originates a completely independent outbound RTP media stream on the other interface (WAN).
• Topology Hiding: Internal IP addresses of IP phones are never exposed to the public carrier; the carrier only sees the public WAN IP of CUBE in the Session Description Protocol (SDP) c= connection line.
• Full Media Services: Enables hardware transcoding, DTMF interworking, audio conferencing, media recording, and SRTP-to-RTP interworking.
• Resource Consumption: Consumes router CPU, packet memory, and DSP resources for all active concurrent calls.

Media Flow-Around

In media flow-around mode, CUBE terminates and processes SIP signaling, but directs the RTP media streams to bypass CUBE entirely:

• CUBE passes the endpoints' own SDP connection addresses through unchanged, so the internal IP phone and the carrier's gateway exchange RTP packets directly end to end.
• Resource Efficiency: Drastically reduces router CPU and memory overhead; zero DSP resources are consumed on CUBE for media handling.
• Architectural Limitations: Completely eliminates topology hiding (carrier sees internal endpoint IPs). Transcoding, DTMF translation, and SRTP-to-RTP interworking are impossible because media never touches the router.

---

3. Voice Class SIP Profiles (SIP Header Manipulation)

Public telephony carriers strictly enforce SIP header formatting for caller billing verification, regulatory compliance, and call tracking. Often, CUCM sends internal SIP headers that an ITSP rejects (e.g., private domain names or unroutable extensions). Cisco IOS XE provides Voice Class SIP Profiles (voice class sip-profiles)—a powerful regular-expression-based engine that modifies, adds, or removes SIP and SDP headers across any SIP request or response method.

SIP Profile Syntax Structure

voice class sip-profiles <tag>
 request <method> sip-header <header-name> {modify | add | remove} ...
 response <status-code> sip-header <header-name> {modify | add | remove} ...
 request <method> sdp-header <header-name> {modify | add | remove} ...

Key Practical Applications

1. Modifying the Remote-Party-ID (RPID) or P-Asserted-Identity (PAI) Header: Telecom providers require a valid, billed E.164 number in the PAI or RPID header to authorize outbound calls.
2. Removing Private Internal Domain Names: Replacing internal CUCM hostnames (e.g., cucm01.corp.internal) with the carrier's registered domain (e.g., carrier-trunk.com).
3. Diversion Header Manipulation: Stripping or reformatting SIP Diversion headers on forwarded calls so the ITSP can identify the original forwarding subscriber for billing.

Production SIP Profile Configuration Example

voice class sip-profiles 100
 description == ITSP Outbound SIP Header Normalization ==
 ! Modify From header to replace internal domain with ITSP domain
 request INVITE sip-header From modify "@cucm01.enterprise.local" "@sip.itsp-carrier.com"
 !
 ! Add P-Asserted-Identity header with corporate billing pilot number
 request INVITE sip-header P-Asserted-Identity add "P-Asserted-Identity: <sip:+14155551000@sip.itsp-carrier.com:5060>"
 !
 ! Remove internal Cisco proprietary headers
 request INVITE sip-header Cisco-Guid remove
 !
 ! Modify Contact header in 200 OK responses to present CUBE WAN IP
 response 200 sip-header Contact modify "<sip:(.*)@10.1.10.1:5060>" "<sip:\1@198.51.100.2:5060>"

Applying SIP Profiles

SIP profiles can be applied globally under voice service voip or selectively per dial peer (recommended for targeted carrier trunk control):

dial-peer voice 200 voip
 description Egress Trunk to ITSP Carrier
 destination-pattern +1[2-9]..[2-9]......
 session protocol sipv2
 session target ipv4:198.51.100.1
 voice-class sip profiles 100

---

4. Server Groups and Outbound Trunk Redundancy

Enterprise SIP trunking requires high availability across redundant carrier Session Border Controllers and multiple internal CUCM subscriber nodes. In Cisco IOS XE, Voice Class Server Groups aggregate multiple SIP destinations under a single logical entity assigned to a dial peer.

Dynamic Heartbeats: SIP OPTIONS Keepalives

Without active heartbeat monitoring, a voice gateway only discovers a dead carrier trunk when an active call setup attempt times out (typically after 32 seconds of SIP INVITE retransmissions), causing noticeable user delay.

Configuring voice class sip-options-keepalive commands the gateway to periodically send SIP OPTIONS request messages to target servers. If a server fails to respond within the configured timeout window, CUBE marks the target BUSY-OUT and automatically reroutes subsequent calls to alternate servers without delay.

! --- Define Outbound Server Group with Active Health Monitoring ---
voice class server-group 50
 description == ITSP Redundant Carrier SBCs ==
 ipv4 198.51.100.10 preference 1
 ipv4 198.51.100.20 preference 2
 hunt-scheme preference
!
! --- Define SIP Options Keepalive Profile ---
voice class sip-options-keepalive 1
 down-interval 15
 up-interval 60
 retry 3
!
! --- Assign Server Group to VoIP Dial Peer ---
dial-peer voice 500 voip
 description Egress Route to Monitored ITSP Trunks
 destination-pattern +1[2-9]..[2-9]......
 session protocol sipv2
 session server-group 50
 voice-class sip options-keepalive profile 1
 voice-class codec 1
 dtmf-relay rtp-nte
 no vad

With hunt-scheme preference (the default), CUBE sends calls to the lowest-preference target first; hunt-scheme round-robin spreads calls across the targets instead. The keepalive profile defaults are up-interval 60, down-interval 30, and retry 5; the example tightens them.

---

5. CUBE High Availability: Box-to-Box (B2B) Redundancy

For mission-critical enterprise environments, a single CUBE platform represents a single point of failure. Cisco IOS XE delivers Box-to-Box (B2B) High Availability, pairing two physical CUBE routers in an Active/Standby architecture.

+-----------------------------------------------------------------------------------------+
|                    CUBE BOX-TO-BOX (B2B) HIGH AVAILABILITY PAIR                         |
|                                                                                         |
|       PRIMARY CUBE (Active)                               SECONDARY CUBE (Standby)      |
|   +--------------------------+                         +--------------------------+     |
|   |  - Owns Virtual IPs      |                         |  - Monitors HSRP Health  |     |
|   |  - Processes SIP & Media |                         |  - Hot Standby State     |     |
|   +------------+-------------+                         +------------+-------------+     |
|                |                                                    |                   |
|                +====================================================+                   |
|                     1. Dedicated Control / Checkpoint Link                              |
|                     2. RG Control-Link Heartbeats                                       |
|                     3. SIP & Media State Checkpointing                                  |
+-----------------------------------------------------------------------------------------+

Architectural Components of B2B Redundancy

1. Redundancy Group (RG) infrastructure (older ISR G2 CUBE releases used HSRP instead):
   • Both CUBE routers share a Virtual IP (VIP) address on both their inside (LAN) and outside (WAN) interfaces.
   • CUCM and the ITSP configure SIP trunks pointing solely to the shared Virtual IP addresses, unaware that two physical routers exist.
2. Inter-Chassis Communication & Checkpointing Protocol:
   • A dedicated direct physical Ethernet link connects the two CUBE routers.
   • The active CUBE continuously synchronizes (checkpoints) call control blocks, SIP dialog information, cryptographic keys, and active RTP socket bindings to the standby router in real time.
3. Failover Execution:
   • If the active router suffers a power failure, hardware crash, or interface link loss, the Redundancy Group moves the standby router to the Active state.
   • The newly active CUBE assumes the Virtual IPs via gratuitous ARP.
   • Because RTP media sockets and SIP call states were fully synchronized, active audio calls remain connected without dropping (zero dropped calls).
   • In-flight call setups (calls currently ringing or negotiating SIP SDP) may need to re-originate, but established two-way voice conversations experience only an imperceptible audio gap (< 500 ms).