A Cisco Unified Border Element (Cisco UBE) has the capability to interconnect voice and VoIP networks, offering protocol interworking, address hiding, and security services. This topic gives an overview of Cisco UBE functionality and describes how to implement a Cisco UBE within an enterprise voice network.

The Cisco UBE is similar to a traditional voice gateway, the main difference being the replacement of physical voice trunks with an IP connection. This section describes the concepts and features of a Cisco UBE in enterprise environments.


Cisco Unified Border Element Overview

The Cisco UBE is an intelligent unified communications network border element. A Cisco UBE, formerly known as the Cisco Multiservice IP-to-IP Gateway, terminates and reorigi-nates both signaling (H.323 and SIP) and media streams (Real-time Transport Protocol [RTP] and RTP Control Protocol [RTCP]) while performing border interconnection services between IP networks. Cisco UBE, in addition to other Cisco IOS Software features, includes session border controller (SBC) functions that help enable end-to-end IP-based transport of voice, video, and data between independent unified communications networks.

Originally, SBCs were used by service providers (SPs) to enable full billing capabilities within VoIP networks. But the functionality to interconnect VoIP networks is becoming more and more important for enterprise VoIP networks as well, because VoIP is becoming the new standard for any telephony solution.

Designed to meet enterprise and service-provider SBC device needs, the Cisco UBE is an integrated Cisco IOS Software application that runs on various Cisco router platforms. For a list of platforms, see the following link: http://www.cisco.com/en/US/products/sw/ voicesw/ps5640/products_white_paper0900aecd8067937f.shtml.

Cisco UBE functionally is implemented on Cisco IOS gateways using a special Cisco IOS feature set. Using this feature set, a Cisco UBE can route a call from one Voice over IP (VoIP) dial peer to another VoIP dial peer.

VoIP dial peers can also be handled by either the Session Initiation Protocol (SIP) or H.323. As a result, the capability to interconnect VoIP dial peers also includes the capability to interconnect VoIP networks using different signaling protocols or VoIP networks using the same signaling protocols but facing interoperability issues.

Protocol interworking includes these combinations:

■ H.323-to-SIP interworking

■ H.323-to-H.323 interworking

■ SIP-to-SIP interworking

Figure below illustrates the capability of Cisco UBE to interconnect VoIP networks, including VoIP networks that use different signaling protocols. VoIP interworking is achieved by connecting an inbound VoIP dial peer with an outbound VoIP dial peer. A standard Cisco IOS gateway without the Cisco UBE functionality will not allow VoIP-to-VoIP connections.


Cisco IOS Image Support for Cisco UBE Gateways

The Cisco UBE functionality is supported on most current Cisco IOS routers, including the Cisco 2800 and 3800 Series Integrated Services Routers (ISRs). The first Cisco IOS release supporting the Cisco UBE functionality was Cisco IOS Release 12.2(13)T.

The Cisco UBE is supported in the following Cisco IOS feature sets:



Cisco UBE Gateways in Enterprise Environments


Cisco UBE in enterprise deployments serve two main purposes:

■ External connections: A Cisco UBE can be used as a demarcation point within a unified communications network and provides interconnectivity with external networks. This includes H.323 voice and video connections and SIP VoIP connections.

■ Internal connections: When used within a VoIP network, a Cisco UBE can be used to increase the flexibility and interoperability between different devices.

Following are some key features offered by Cisco UBE:

■ Protocol interworking: The Cisco UBE supports interworking of signaling protocols, including H.323-to-H.323, H.323-to-SIP, and SIP-to-SIP.

■ Address hiding: A Cisco UBE can hide or replace the endpoint IP addresses used for a media connection.

■ Security: A Cisco UBE can be placed in a demilitarized zone (DMZ) and provide outside connectivity to external networks.

■ Video integration: In addition to VoIP services, a Cisco UBE also supports H.323 video connections.

■ Call Admission Control (CAC): A Cisco UBE can use Cisco IOS-based CAC mechanisms, including the RSVP.

Table 1 Key Features of the Cisco UBE Gateway

Feature Details
Protocols H.323 and SIP
Network hiding IP network privacy and topology hiding
IP network security boundary
Intelligent IP address translation for call media and signaling
Back-to-back user agent, replacing all SIP-embedded IP addressing
Maximum number of calls per trunk
CAC based on IP circuits
CAC based on total calls, CPU usage, or memory usage thresholds
Protocol and signal interworking H.323 to H.323 (including Cisco Unified Communications Manager)
H.323 to SIP (including Cisco Unified Communications Manager)
SIP to SIP (including Cisco Unified Communications Manager)
Media support RTP and RTCP
Media modes Media flow-through
Media flow-around
Video codecs H.261, H.263, and H.264
Transport mode TCP
User Datagram Protocol (UDP)
TCP-to-UDP interworking

Table 2 Key Features of the Cisco UBE Gateway

Feature   Details
DTMF H.245 Alphanumeric
H.245 Signal
RFC 2833
SIP Notify
Key Press Markup Language (KPML)
Interworking capabilities:
■ H.323 to SIP
■ RFC 2833 to G.711 in-band DTMF
Fax support T.38 fax relay
Fax passthrough
Cisco fax relay
Modem support Modem passthrough
Cisco modem relay
Supplementary services Call hold, call transfer, and call forward for H.323 networks using H.450
and transparent passing of Empty Capability Set (ECS)
SIP-to-SIP supplementary services (holds and transfers) support using REFER
H.323-to-SIP supplementary services for Cisco Unified Communications
Manager with Media Termination Point (MTP) on the H.323 trunk
NAT Traversal NAT traversal support for SIP phones deployed behind non-Application
Line Gateway (ALG) data routers
Stateful NAT traversal
QoS IP precedence and DSCP marking
Voice-quality statistics Packet loss, jitter, and round-trip time
Number translation Number translation rules for VoIP numbers
Electronic Numbering (ENUM) support for E.164 number mapping into
Domain Name System (DNS)
Codecs G711 mu-law and a-law
G723ar53, G723ar63, G723r53, and G723r63
G726r16, G726r24, and G726r32
G729, G729A, G729B, and G729AB
Internet Low Bitrate Codec (iLBC)


Table 3 Key Features of the Cisco UBE Gateway

Feature      Details
Transcoding Transcoding between any two families of codecs from the following list:
■ G711 a-law and mu-law
■ G.729, G.729A, G.729B, and G.729AB
■ G.723 (5.3 and 6.3 kbps)
■ iLBC
Security IP Security (IPsec)
Secure RTP (SRTP)
Transport Layer Security (TLS)
Authentication, authorization, and accounting (AAA) AAA with RADIUS
Voice media applications Tool Command Language (TCL) scripts support for application customization
Voice Extensible Markup Language (VoiceXML 2.0) script support for application customization
Billing Standard CDRs for accurate billing available through
■ AAA records
■ Syslog
■ Simple Network Management Protocol (SNMP)


Protocol Interworking on Cisco UBE Gateways


Cisco UBE can interwork signaling protocols, similar to a proxy. This feature can be used for two scenarios:

■ Interworking between the same signaling protocol: A Cisco UBE that is interwork-ing between the same signaling protocol (for example H.323-to-H.323) can be used to solve interoperability issues between two devices having different capabilities. Because Cisco UBE builds two call legs to each peer, it can interwork between those two call legs. For example, Cisco Unified Communications Manager Express uses H.450, a subset of H.323, for call transfers and call forwarding. When connected directly to a Cisco Unified Communications Manager, which does not support H.450, call forwarding and transfers might lead to hair-pinned calls and suboptimal WAN usage. A Cisco UBE at the Cisco Unified Communications Manager site can be used to solve these issues.

Interworking between different signaling protocols: Cisco UBE can interconnect dial peers that use different signaling protocols, such as a SIP and an H.323 dial peer. This allows for greater flexibility when deploying an IP communications network.

Both H.323 and SIP support two methods of call setups. H.323 uses fast start and slow start, whereas SIP uses early offer and delayed offer. Both H.323 fast start and SIP early offer are used to set up the media channel faster than during standard call setup. Problems arise when one endpoint expects an H.323 slow start or SIP delayed offer and the other endpoint uses H.323 fast start or SIP early offer.

When interworking signaling protocols, a Cisco UBE supports the following combinations:

■ H.323-to-H.323: An Cisco UBE fully supports fast start with slow start interwork-ing in all directions.

■ H.323-to-SIP: H.323 fast start to SIP early offer interworking is fully supported. An H.323 slow start to an SIP delayed offer is supported only for inbound H.323 to outbound SIP calls.

■ SIP-to-SIP: Early offer and delayed offer are fully supported on Cisco UBE in all directions.

Media Flows on Cisco UBE Gateways

Because Cisco UBE is a signaling proxy, it also processes all signaling messages regarding the setup of media channels. This enables a Cisco UBE to affect the flow of media traffic. Two options exist: media flow-through and media flow-around.

When using media flow-through, Cisco UBE replaces the source IP address used for media connections with its own IP address. This operation can be utilized in different ways:

It solves IP interworking issues because Cisco UBE replaces potential duplicate IP addresses with a single, easy-to-control IP address.

■ It hides the original endpoint IP address from the remote endpoints.

This makes Cisco UBE with media flow-through ideal for interworking with external VoIP networks and enforcing a tighter security policy.

When using Cisco UBE internally, media flow-through might not be necessary or even desirable. One of the main drawbacks when using media flow-through is the higher load on a Cisco UBE router, which decreases the number of supported concurrent flows. In addition, media flow-through might result in suboptimal traffic flows because direct endpoint-to-endpoint communication is prohibited. Thus Cisco UBE can also be configured for media flow-around.

When using media flow-around, Cisco UBE leaves the IP addresses used for the media connections untouched. Call signaling will still be processed by Cisco UBE, but after the call is set up, Cisco UBE is no longer involved with the traffic flow.

Figure 9-4 shows a Cisco UBE router configured for media flow-through. The signaling between the two Cisco Unified Communications Manager clusters is processed by Cisco UBE, and the source IP addresses of the endpoints are replaced by the Cisco UBE IP address. Both endpoints have the same IP address, but because Cisco UBE is involved, no interworking issues arise.


Figure 9-4 Media Flow-Through Topology


Figure 9-5 shows a Cisco UBE router configured for media flow-around. No duplicate IP address ranges exist, and IP address hiding is not required—so media flow-through is not required. Cisco UBE still processes all signaling traffic, but the endpoints have direct media channels. You might use media flow-around when you are not concerned with hiding your network addresses.


Figure 9-5 Media Flow-Around Topology

Codec Filtering on Cisco UBEs

VoIP networks usually support a large variety of codecs, and mechanisms exist to perform codec negotiations between devices. Regardless of which mechanisms are used, preferences determine which codecs will be selected over others.

Because a Cisco UBE router is essentially a Cisco IOS gateway with the capability to interconnect VoIP dial peers, the same codec selections mechanisms are available as on any other Cisco IOS gateway. A dial peer can be configured to allow a specific codec or to use a codec voice class to specify multiple codecs with a preference order. This enables Cisco UBE to perform codec filtering, because a dial peer will set up a call leg only if the desired codec criteria are satisfied. This adds to the Cisco UBE role of a demarcation point within a VoIP network.

If codec filtering is not required, Cisco UBE also supports transparent codec negotiations. This enables negotiations between endpoints with Cisco UBE leaving the codec information untouched.

Whether performing codec filtering or operating in transparent mode, Cisco UBE is required to support the codec used between endpoints. The following codecs are supported:

■ Audio codecs: G.711u, G.711a, G.723, G.726, G.729r8, G.728, and AMR-NB

■ Video codecs (H.323 only): H.261, H.263, and H.264

Figure 9-6 shows how codec negotiation is performed on a Cisco UBE router. Two VoIP clouds need to be interconnected. In this scenario, both VoIP 1 and VoIP 2 networks have G.711 a-law as the preferred codec.

In the first example, the Cisco UBE router is configured to use the G.729a codec. This can be done by using the appropriate codec command on both VoIP dial peers. When a call is set up, Cisco UBE will accept only G.729a calls, thus influencing the codec negotiation.

In the second example, the Cisco UBE is configured for a transparent codec and will leave the codec information contained within the call signaling untouched. Because both VoIP 1 and VoIP 2 have G.711 a-law as their first choice, the resulting call will be a G.711 a-law call.

RSVP-Based CAC on Cisco UBEs

Because a Cisco UBE router is a Cisco IOS gateway, it also supports RSVP-based CAC. Two Cisco Unified Communications Manager clusters can interconnect using Cisco UBE, thus enabling intercluster RSVP-based CAC. RSVP supports both voice and video calls.

Figure 9-6 Codec Filtering on Cisco UBEs

RSVP requires at least two RSVP peers, so two Cisco UBE Gateways are required to enable RSVP-based CAC. When deploying Cisco UBE and RSVP-based CAC, ensure that the flows that should utilize RSVP are configured for media flow-through. Media flow- around is not supported with RSVP-based CAC.

Figure 9-7 shows a call setup combined with RSVP-based CAC example.

Following is the call flow:

1. The Cisco Unified Communications Manager Cluster 1 sends an H.225 setup to the Cisco UBE router.

2. Cisco UBE processes the call setup information and associates an outbound VoIP dial peer requiring an RSVP reservation. Cisco UBE sends out an RSVP request to the remote Cisco UBE router.

3. The remote Cisco UBE acknowledges the reservation and initiates the reservation for the return path, which is acknowledged by the local Cisco UBE router.

4. The H.225 setup message is routed to the remote Cisco UBE router, which then routes the call to the outbound VoIP dial peer pointing to Cisco Unified Communications Manager Cluster 2.

5. H.245 negotiation occurs with media flow-through enabled.

6. The call is established.