2.1 Collaboration Edge Architecture: CUBE & Expressway

Collaboration Edge Architecture: CUBE & Expressway

Modern enterprise collaboration environments require secure, high-quality voice and video connectivity that extends beyond the corporate campus. Traditionally, remote workers relied on full-tunnel IPSec or SSL Virtual Private Networks (VPNs) such as Cisco AnyConnect. However, VPN tunnels introduce latency, packet jitter, MTU path fragmentation, and unnecessary cryptographic overhead for real-time RTP voice streams. The Cisco Collaboration Edge architecture eliminates the requirement for client-side VPNs by deploying reverse proxies, session border controllers, and firewall traversal protocols.

---

Cisco Expressway Architecture: Expressway-C and Expressway-E

The Cisco Expressway solution consists of two purpose-built appliances (available as hardware appliances or VMware ESXi / KVM virtual machines):

1. Expressway-Core (Expressway-C): Deployed strictly within the trusted internal local area network (LAN). It interfaces directly with internal call control nodes, including Cisco Unified Communications Manager (CUCM), Cisco Unified Communications Manager IM and Presence Service (CUCM IM&P), and Cisco Unity Connection (CUC).
2. Expressway-Edge (Expressway-E): Deployed in the perimeter Demilitarized Zone (DMZ). It acts as the public-facing termination point for external endpoints on the Internet, remote B2B federated partners, and cloud services such as Cisco Webex.

+-----------------------+       Internal        +-----------------------+       External        +-----------------------+
|     Internal LAN      |       Firewall        |          DMZ          |       Firewall        |       Internet        |
|                       |                       |                       |                       |                       |
|  +-----------------+  |                       |  +-----------------+  |                       |  +-----------------+  |
|  |      CUCM       |  |                       |  |                 |  |                       |  |  Remote Jabber  |  |
|  +--------+--------+  |   Outbound Only       |  |  Expressway-E   |  |   Inbound Allowed     |  |   / Webex App   |  |
|           |           |   TCP 7001 (SIP TLS)  |  |                 |  |   TCP 8443 (Edge)     |  +--------+--------+  |
|  +--------+--------+  |   UDP 2776-2777 (RTP) |  |  Dual-NIC or    |  |   TCP 5061 (SIP TLS)  |           |           |
|  |  Expressway-C   +==+======================>+==+  Single-NIC     +==+======================>+===========+           |
|  | (Traversal Clt) |  |                       |  | (Traversal Svr) |  |   UDP 36000-59999     |  +--------+--------+  |
|  +-----------------+  |   No Inbound Ports!   |  +-----------------+  |                       |  | B2B Partner PBX |  |
+-----------------------+                       +-----------------------+                       +-----------------------+

Traversal Client and Traversal Server Mechanism

Opening inbound firewall ports from a DMZ into the internal corporate network violates core security principles. To avoid opening any inbound firewall pinholes, Cisco Expressway utilizes a Traversal Zone architecture based on standard firewall traversal mechanisms (H.460.18/19 for H.323 and Assent / SIP TLS for SIP):

• Expressway-C acts as the Traversal Client: Expressway-C initiates all TCP and UDP connections outbound from the internal LAN across the internal firewall to Expressway-E.
• Expressway-E acts as the Traversal Server: Expressway-E listens on designated traversal ports. When an external client attempts to connect, Expressway-E multiplexes that traffic across the pre-existing, persistent connection previously opened by Expressway-C.

Traversal Ports and Protocols

---

Expressway-E Network Topologies: Dual-NIC vs Single-NIC with Static NAT

Expressway-E requires public and private network connectivity to bridge external clients with the internal DMZ. Administrators choose between two deployment models:

1. Dual-NIC Deployment (Recommended for Security)

In a dual-NIC topology, Expressway-E has two physical or virtual network interfaces assigned to separate subnets:

• Interface 1 (LAN-facing): Configured with a private IP address within the internal DMZ subnet. It communicates exclusively with Expressway-C across the internal firewall.
• Interface 2 (Internet-facing): Configured with a DMZ IP address connected to the external DMZ subnet, which is mapped or routed directly toward the public Internet.
• Routing Rules: In Dual-NIC mode, IP forwarding between interfaces is disabled at the kernel level to prevent network bridging across the DMZ. The default gateway must reside on Interface 2 (external). Static routes must be configured on Expressway-E pointing all internal enterprise subnets (including Expressway-C and internal endpoints) out through the Interface 1 gateway.

2. Single-NIC with Static NAT Deployment

In a single-NIC topology, Expressway-E uses one physical or virtual interface assigned a single private IP address inside the DMZ:

• The perimeter firewall translates the private DMZ IP address to a public, routable IP address using 1:1 Static NAT.
• The public address is entered in the IPv4 static NAT address field (System > Network interfaces > IP) so that Expressway-E writes the public address into SIP and SDP instead of its private one.
• Dual-NIC operation and static NAT are part of Expressway-E's Advanced Networking feature set.

---

Mobile and Remote Access (MRA) Call and Registration Flow

Mobile and Remote Access (MRA) allows off-premises Cisco Jabber, Webex App, and Cisco IP Phone 7800/8800 series devices to securely register with on-premises CUCM without requiring a VPN.

Detailed MRA Registration Sequence

1. External DNS SRV Discovery: When the client device boots or connects outside the corporate network, it queries public DNS for the SRV record _collab-edge._tls.<domain>.
2. Expressway-E Resolution: The DNS server returns the FQDN and port of Expressway-E (for example, edge01.example.com:8443).
3. TLS Session Establishment: The client initiates an HTTPS connection to Expressway-E on TCP port 8443. Expressway-E presents its public CA-signed server certificate, which the client validates against its local trust store.
4. Get Edge Configuration (get_edge_config): The client issues an HTTPS request for edge configuration. Expressway-E passes this request to Expressway-C through the SSH tunnel that Expressway-C opened to TCP 2222 on Expressway-E.
5. Authentication Verification: Expressway-C queries the CUCM Publisher or Subscriber via User Data Services (UDS) over HTTPS port 8443. If Single Sign-On (SSO) is enabled, the client is redirected to authenticate with the enterprise Identity Provider (IdP) via SAML 2.0 or OAuth 2.0.
6. Cluster Node Retrieval: Upon successful authentication, CUCM UDS returns the cluster topology, including the active TFTP server list and home CUCM call processing nodes.
7. TFTP Configuration Retrieval: The client requests its device configuration file (<SEPmac>.cnf.xml) from Expressway-E over port 8443. Expressway-E proxies this request to Expressway-C, which fetches the file from the CUCM TFTP service over port 6970/6972 and returns it encrypted to the client.
8. SIP Registration: The client sends a SIP REGISTER message over TLS to Expressway-E. Expressway-E encapsulates the SIP message across the Traversal Zone over TCP port 7001 to Expressway-C. Expressway-C decapsulates the message and delivers it to the target CUCM Subscriber over internal SIP signaling (port 5060 or 5061).
9. Media Stream Establishment: When a call is placed, the media (audio/video RTP) is negotiated. The external endpoint sends media to the external interface of Expressway-E (UDP ports 36000-59999). Expressway-E relays the media across the traversal zone (multiplexed UDP 2776/2777 or 36000/36001) to Expressway-C, which forwards the media to the internal IP phone or voice gateway.

---

Business-to-Business (B2B) Calling and Federation

Business-to-Business (B2B) calling allows enterprise users to place voice and video calls directly to external organizations using SIP Uniform Resource Identifiers (URIs), such as sip:alice@company-a.com calling sip:bob@company-b.com.

B2B Architecture Components

• DNS SRV Records: The originating Expressway-E resolves the recipient's domain using external DNS SRV records:
  • _sips._tcp.<domain> (Port 5061) — Secure SIP over TLS (highest priority).
  • _sip._tcp.<domain> (Port 5060) — Standard SIP over TCP (fallback if TLS is unavailable).
• Search Rules and Transforms:
  • Transform Rules: Modify dialed strings before routing (for example, converting an E.164 alias +14085550100 into 14085550100@company.com).
  • Search Rules: Inspect dialed URIs and determine the next-hop Zone based on regex matching and priority.
• Expressway Zones:
  • DNS Zone: Configured on Expressway-E to evaluate the domain portion of an outbound URI, perform external DNS SRV queries, and establish outbound SIP TLS connections to foreign enterprises.
  • Traversal Zone: Carries signaling and media between Expressway-C and Expressway-E.
  • Neighbor Zone: Connects Expressway-C to internal CUCM call processing nodes using standard SIP trunks.

---

CUBE vs. Cisco Expressway: Architectural Comparison

Both Cisco Unified Border Element (CUBE) and Cisco Expressway operate at the enterprise perimeter, but they fulfill fundamentally distinct roles in collaboration engineering:

Media Flow-Through vs. Flow-Around on CUBE

On CUBE, administrators can configure how real-time media is routed:

• Media Flow-Through (Default): Both SIP signaling and RTP media pass through the CUBE router. CUBE terminates the media stream from the service provider and originates a new media stream to the internal endpoint. This enables topology hiding, QoS remarking, transcoding, and lawful intercept.
• Media Flow-Around: CUBE processes SIP signaling to maintain call control and billing, but passes each endpoint's own SDP connection address (c= line) through unchanged, so RTP flows directly between the originating endpoint and the service provider gateway, bypassing CUBE. In flow-through mode, by contrast, CUBE substitutes its own address in the SDP.