Overview of Cisco Unified Border Element

Cisco Unified Border Element (CUBE) bridges voice and video connectivity between two separate VoIP networks. It is similar to a traditional voice gateway, except for the replacement of physical voice trunks with an IP connection. Traditional gateways connect VoIP networks to telephone companies using a circuit-switched connection, such as PRI. The CUBE connects VoIP networks to other VoIP networks and is often used to connect enterprise networks to Internet telephony service providers (ITSPs).

Information About Cisco Unified Border Element

Cisco Unified Border Element (CUBE) can terminate and originate signaling (H.323 and Session Initiation Protocol [SIP]) and media streams (Real-Time Transport Protocol [RTP] and RTP Control Protocol [RTCP]).

CUBE extends the functionality provided by conventional session border controllers (SBCs) in terms of protocol interworking, especially on the enterprise side. As shown in the chart below, the CUBE provides the following additional features:

Figure 1. Cisco Unified Border Element—More Than an SBC

The CUBE provides a network-to-network interface point for:

  • Signaling interworking—H.323 and SIP.

  • Media interworking—dual-tone multifrequency (DTMF), fax, modem, and codec transcoding.

  • Address and port translations—privacy and topology hiding.

  • Billing and call detail record (CDR) normalization.

  • Quality-of-service (QoS) and bandwidth management—QoS marking using differentiated services code point (DSCP) or type of service (ToS), bandwidth enforcement using Resource Reservation Protocol (RSVP), and codec filtering.

CUBE functionality is implemented on devices using a special IOS feature set, which allows CUBE to route a call from one VoIP dial peer to another.

Protocol interworking is possible for the following combinations:

  • H.323-to-SIP interworking

  • H.323-to-H.323 interworking

  • SIP-to-SIP interworking

The CUBE provides a network-to-network demarcation interface for signaling interworking, media interworking, address and port translations, billing, security, quality of service, call admission control, and bandwidth management.

The CUBE is used by enterprise and small and medium-sized organizations to interconnect SIP PSTN access with SIP and H.323 enterprise unified communications networks.

A CUBE interoperates with several different network elements including voice gateways, IP phones, and call-control servers in many different application environments, from advanced enterprise voice and/or video services with Cisco Unified Communications Manager or Cisco Unified Communications Manager Express, as well as simpler toll bypass and voice over IP (VoIP) transport applications. The CUBE provides organizations with all the border controller functions integrated into the network layer to interconnect unified communications voice and video enterprise-to-service-provider architectures.

Figure 2. Why Does an Enterprise Need the CUBE?

If an enterprise subscribes to VoIP services offered by an ITSP, connecting the enterprise CUCM through a CUBE provides network demarcation capabilities, such as security, topology hiding, transcoding, call admission control, protocol normalization and SIP registration, none of which is possible if CUCM connects directly to the ITSP. Another use case involves mergers or acquisitions in an enterprise and the need to integrate voice equipment, such as CUCMs, IP PBXs, VM servers, and so on. If the networks in the two organizations have overlapping IP addresses, CUBE can be used to connect the two distinct networks until the acquired organization can be migrated into the enterprise addressing plan.

SIP/H.323 Trunking


Note


H.323 protocol is no longer supported from Cisco IOS XE Bengaluru 17.6.1a onwards. Consider using SIP for multimedia applications.


The Session Initiation Protocol (SIP) is a signaling communications protocol, widely used for controlling multimedia communication sessions such as voice and video calls over IP networks. SIP (or H.323) trunking is the use of VoIP to facilitate the connection of PBX to other VoIP endpoints across the Internet. To use SIP trunking, an enterprise must have a PBX (internal VoIP system) that connects to all internal end users, an Internet telephony service provider (ITSP), and a gateway that serves as the interface between the PBX and the ITSP. One of the most significant advantages of SIP and H.323 trunking is the ability to combine data, voice, and video in a single line, eliminating the need for separate physical media for each mode.

Figure 3. SIP/H.323 Trunking

SIP trunking overcomes TDM barriers, in that it:

  • Improves efficiency of interconnection between networks

  • Simplifies PSTN interconnection with IP end-to-end

  • Enables rich media services to employees, customers, and partners

  • Carries converged voice, video, and data traffic

Figure 4. SIP Trunking Overcomes TDM Barriers

Note


For Cisco IOS XE Gibraltar 16.11.1a and later releases, the SIP processes are initiated only when either of the following CLIs is configured:

  • Voice dial-peer with session protocol as SIP.

  • voice register global

  • sip-ua

In the releases before Cisco IOS XE Gibraltar 16.11.1a, the following commands initiated the SIP processes:

  • dial-peer voice (any)

  • ephone-dn

  • max-dn under call-manager-fallback

  • ds0-group 0 timeslots 1 type e&m-wink-start


Typical Deployment Scenarios for CUBE

CUBE in an enterprise environment serves two main purposes:

  • External Connections—CUBE is the demarcation point within a unified communications network and provides interconnectivity with external networks. This includes H.323 and SIP voice and video connections.
  • Internal Connections—When used within a VoIP network, CUBE increases flexibility and interoperability between devices.
Figure 5. Typical Deployment Scenarios


How to Configure Basic CUBE Features

Consider a scenario where XYZ corporation uses a VoIP network to provide phone services and uses a PRI connection for telecommunications services, and the PRI trunk is controlled by MGCP. Migration from MGCP PRI to SIP trunk is provided by ITSP telecommunications. CUCM sends the telephone number, as 10 digits, to CUBE. CUCM may send only the extension (4 digits) to the CUBE. When the call is diverted (using call-forward), the requirement of the ITSP is that they need the full 10-digit number in the SIP Diversion field.

Figure 6. CUBE Configuration Workflow


The following sections describe the basic setup of CUBE through the steps involved in migrating the XYZ corporation to CUBE using a SIP trunk.

Enabling the CUBE Application on a Device

SUMMARY STEPS

  1. enable
  2. configure terminal
  3. voice service voip
  4. mode border-element license [capacity sessions | periodicity {mins value | hours value | days value} ]
  5. allow-connections from-type to to-type
  6. end

DETAILED STEPS

  Command or Action Purpose

Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode. Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

voice service voip

Example:


Device(config)# voice service voip

Enters global VoIP configuration mode.

Step 4

mode border-element license [capacity sessions | periodicity {mins value | hours value | days value} ]

Example:


Device(conf-voi-serv)# mode border-element license capacity 200

Device(conf-voi-serv)# mode border-element license periodicity days 15

Enables CUBE configuration and configures the number of licenses (capacity).

  • Effective from Cisco IOS XE Amsterdam 17.2.1r, the capacity keyword and sessions argument are deprecated. However, the keyword and argument are available in the Command Line Interface (CLI). If you try to configure license capacity using CLI, the following error message is displayed:
    Error: CUBE SIP trunk licensing is now based on dynamic session counting. Static license capacity configuration has been deprecated.
  • Effective from Cisco IOS XE Amsterdam 17.2.1r, the periodicity keyword and [mins | hours| days] argument are introduced. The periodicity keyword configures periodicity interval for license entitlement requests for CUBE. If you do not configure license periodicity, the default license period of 7 days is enabled.

    Note

     

    We recommend you to configure interval in days. Configuring interval in minutes or hours increases the frequency of entitlement requests and thereby increases the processing load on Cisco Smart Software Manager (CSSM). License periodicity configuration of minutes or hours is recommended to be used only with Cisco Smart Software Manager On-Prem (formerly known as Cisco Smart Software Manager satellite) mode.

Step 5

allow-connections from-type to to-type

Example:


Device(conf-voi-serv)# allow-connections sip to sip

Allows connections between specific types of endpoints in a VoIP network.

  • The two protocols (endpoints) refer to the VoIP protocols (SIP or H.323) on the two call legs.

Step 6

end

Example:


Device(conf-voi-serv)# end

Returns to privileged EXEC mode.

Verifying the CUBE Application on the Device

SUMMARY STEPS

  1. enable
  2. show cube status

DETAILED STEPS


Step 1

enable

Enables privileged EXEC mode.

Example:
Device> enable 
          

Step 2

show cube status

Displays the CUBE status, the software version, the license capacity, the image version, and the platform name of the device. In releases before Cisco IOS XE Amsterdam 17.2.1r, CUBE status display is enabled only if mode border-element command is configured with call license capacity. Effective from Cisco IOS XE Amsterdam 17.2.1r, this dependency is removed and Licensed-Capacity information is excluded from output.

Example:

Before Cisco IOS XE Amsterdam 17.2.1r:

Device# show cube status 

CUBE-Version : 12.5.0
SW-Version : 16.11.1, Platform CSR1000V
HA-Type : none
Licensed-Capacity : 10
Calls blocked (Smart Licensing Not Configured) : 0
Calls blocked (Smart Licensing Eval Expired) : 0

Effective from Cisco IOS XE Amsterdam 17.2.1r:

Device# show cube status 

CUBE-Version : 12.8.0
SW-Version : 17.2.1, Platform CSR1000V
HA-Type : none

Configuring a Trusted IP Address List for Toll-Fraud Prevention

SUMMARY STEPS

  1. enable
  2. configure terminal
  3. voice service voip
  4. ip address trusted list
  5. ipv4 ipv4-address [ network-mask]
  6. ipv6 ipv6-address
  7. end

DETAILED STEPS

  Command or Action Purpose

Step 1

enable

Example:

Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:

Device# configure terminal

Enters global configuration mode.

Step 3

voice service voip

Example:

Device(config)# voice service voip

Enters global VoIP configuration mode.

Step 4

ip address trusted list

Example:

Device(conf-voi-serv)# ip address trusted list

Enters IP address trusted list mode and enables the addition of valid IP addresses.

Step 5

ipv4 ipv4-address [ network-mask]

Example:

Device(cfg-iptrust-list)# ipv4 192.0.2.1 255.255.255.0

Allows you to add up to 100 IPv4 addresses in the IP address trusted list. Duplicate IP addresses are not allowed.

  • The network-mask argument allows you to define a subnet IP address.

Step 6

ipv6 ipv6-address

Example:

Device(cfg-iptrust-list)# ipv6 2001:DB8:0:ABCD::1/48

Allows you to add IPv6 addresses to the trusted IP address list.

Step 7

end

Example:

Device(cfg-iptrust-list)# end

Returns to privileged EXEC mode.