The adoption of IP-based video communications within the enterprise is
well underway. In today’s economic environment, customers use video more
frequently as a tool for intra-company communications with the major benefits
of this adoption being gains in both employee productivity and operational
Most enterprise IP-based video communications networks today are like
islands relative to other such enterprise networks interconnected using older
Integrated Services Digital Network (ISDN) technology. ISDN is very commonly
used for all extra-enterprise or extra-campus communication with other
businesses and, in some cases, even with remote branches within the enterprise
itself. The far-reaching benefits of IP-based video communications can truly be
realized with end-to-end IP connectivity within or between organizations to
facilitate business-to-business (B2B) communications. This requires a
transition from ISDN to IP-based solutions that traverse the Internet instead
of the PSTN, enabling a less expensive converged option for intra-company and
Wholesale transition from ISDN circuits to IP connections via the
Internet is not a trivial undertaking. ISDN circuits, and the video gateways
that tie ISDN into an IP-based video communications world, are a widely
deployed, time-proven and trusted solutions. Despite limitations in
accommodating next-generation video communications services, ISDN still sets
the standard against which new solutions are measured when taking into
consideration security, privacy, billing, and demarcation. New solutions must
offer similar service-level assurances for enterprises and service providers to
consider them as a viable alternative. Enterprises thus need a way to maintain
all of the benefits associated with ISDN while exploiting the efficiencies of
extending IP-based video communications beyond the enterprise.
This configuration example highlights the features of the Cisco Unified
Border Element (CUBE) and specifically illustrates how CUBE supports the
ability for an endpoint that resides somewhere on the Internet to dial via an
IP address to a Multipoint Control Unit (MCU) or endpoint that is behind a
corporate firewall. This functionality showcases the
null-called-number override feature available in the
12.4(22)YB release of CUBE 1.3 and the IVR functionality available in the 5.6
release of the Cisco Unified Videoconferencing (CUVC) MCU. This document
contains configuration recommendations and possible starting points for
enterprises embarking on this evolution.
Ensure that you meet these requirements before you attempt this
Basic knowledge of how to configure and use Cisco IOS voice (such as
Basic knowledge of how to configure and use CUBE
Basic understanding of how firewalls work
The information in this document is based on:
Cisco Unified Border Element and Cisco IOS Gatekeeper that runs on a
Cisco 2800 router and uses Cisco IOS release 12.4.22(YB) or Cisco IOS release
Cisco IP Video Conferencing 3545 Solution that runs software version
5.6 or later
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
Refer to the
Technical Tips Conventions for more information on document
In this section, you are presented with the information to configure
the features described in this document.
Note: Use the
(registered customers only)
to obtain more information on the commands used in this
This diagram shows CUBE external endpoints securely dialing into the
customer network via an internal endpoint IP address.
An external endpoint on the Internet dials a public IP address of
CUBE (192.168.1.2) to join a video conference that resides on a internal Cisco
Multipoint Control Unit (MCU). The H.323 call setup messages arrive at the CUBE
by virtue of an initial pinhole for TCP port 1720
configured in the Cisco Adaptive Security Appliance (ASA) which is the firewall
that provides the security boundary for the network. In this example, CUBE has
a private IP address so the publicly routable address targeted by the exterior
endpoint is the result of a static NAT (Network Address Translation) performed
by the ASA.
Note: For illustration purposes, Cisco uses only private IP address
spaces in documentation.
Since the incoming SETUP message does not include the usual dialed
digits by which CUBE would normally target the next leg of the call, CUBE uses
the digits (1234567890) configured by the null-called-number
override configuration command. Using this address, call setup
messages proceed toward the internal customer network.
The ASA has two pinholes to support this stage of the call: one to
allow CUBE to look up the desired address via the CUVC-M Internal Gatekeeper
feature and one to allow the resultant SETUP message from CUBE to get to CUVC-M
to establish the call to the MCU based on the E.164 address configured in the
dial peer on CUBE. Using the H.323 inspection feature on the ASA, the remaining
signaling and media flow TCP and UDP connections are opened up dynamically
according to the information gleaned from the call setup
The CUVC-M Internal Gatekeeper routes the call to the IPVC-MCU that
includes a new video IVR feature that presents a graphical options menu to the
external user. This menu is navigated by entering DTMF tones via the dial pad
or remote control of the calling endpoint. The end user simply selects the
conference ID from the join conference menu option and
then enters necessary password if configured.
The internal video endpoint joins the conference by dialing the same
conference ID as the external endpoint.
This document uses these configurations:
service timestamps debug datetime localtime
service timestamps log datetime msec
boot system flash:c2800nm-adventerprisek9_ivs-mz.124-22.YB.bin
multilink bundle-name authenticated
voice service voip
allow-connections h323 to h323
null-called-number override 1234567890
h225 start-h245 on-connect
call start slow
h245 passthru all
voice class h323 10
ip address 172.16.1.100 255.255.255.0
ip route-cache same-interface
h323-gateway voip interface
h323-gateway voip id vgk1 ipaddr 172.16.1.100 1719 priority 1
!--- vgk1 defines zone the cube to register with the local Gatekeeper service
h323-gateway voip h323-id cube1
!--- Defines the ID of CUBE
h323-gateway voip tech-prefix 1#
h323-gateway voip bind srcaddr 172.16.1.100
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 172.16.1.1
ip http server
no ip http secure-server
dial-peer voice 1 voip
!--- To match outbound call leg to send to GK process
session target ras
incoming called-number .
!--- For inbound call leg
timer receive-rtp 1200
zone local vgk1 cisco.com
zone remote CUVCM cisco.com 10.1.1.26 invia vgk1 outvia vgk1
zone prefix CUVCM 1234567890
gw-type-prefix 1#* default-technology
no use-proxy GK1 default inbound-to terminal
no use-proxy GK1 default outbound-from terminal
bandwidth interzone default 1000000
ASA Version 8.2(1)
!--- This is only a portion of the ASA config.
!--- In a typical production scenario, these commands would
!--- be in addition to the current security policies configured.
no ip address
ip address 10.1.1.1 255.255.255.0
ip address 172.16.1.1 255.255.255.0
ip address 192.168.1.2 255.255.255.0
boot system disk0:/asa821-k8.bin
ftp mode passive
clock timezone CDT -6
access-list dmz-in extended permit icmp any any
access-list dmz-in extended permit udp host 172.16.1.100any eq 1719
access-list dmz-in extended permit tcp host 172.16.1.100any eq h323
!--- The access list allows CUBE address lookups and call
!--- signaling respectively to get to the interior of the network.
access-list outside_access_in extended permit icmp any any
access-list outside_access_in extended permit tcp any host 192.168.1.2 eq h323
access-list outside_access_in extended permit udp any host 192.168.1.2 eq 1719
!--- The access list allows exterior call setups and address
!--- look ups respectively to get to the CUBE.
access-list inside-to-DMZ-exemption extended permit ip 10.0.0.0 255.0.0.0 10.150
!--- This access list prevents the global NAT translation intended
!--- for the outside interface from being used on the conversations
!--- between internal endpoints and CUBE.
mtu inside 1500
mtu dmz 1500
mtu outside 1500
global (outside) 1 192.168.1.5-192.168.1.100 netmask 255.255.255.0
!--- Note that the general NAT pool should not overlap the
!--- ASA interface nor the static NAT used for CUBE.
nat (inside) 0 access-list inside-to-DMZ-exemption
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz) 1 220.127.116.11 255.255.255.0
static (dmz,outside) 192.168.1.2 172.16.1.100 netmask 255.255.255.255
!--- The previous statement is what establishes the publicly
!--- routed address for CUBE on the outside interface.
access-group dmz-in in interface dmz
access-group outside_access_in in interface outside
route inside 10.0.0.0 255.255.255.0 10.1.1.2 1
route outside 0.0.0.0 0.0.0.0 192.168.1.254 1
!--- These two static route statements assume the existence of
!--- a next hop router on both inside and outside interfaces.
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:10:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:10:00 h225 1:00:00 mgcp 0:10:00 mgcp-pat 0:10:00
!--- Note: It is a good idea to increase the H.225 timeout. Not all endpoints
!--- send enough traffic on this connection to keep it alive. The H.225 command
!--- includes the H.245 attributes.
inspect h323 h225
inspect h323 ras
Use this section to confirm that your configuration works
This image shows the Cisco IOS Gatekeeper being added to the Cisco
Unified Videoconferencing Manager. The Cisco IOS Gatekeeper model is selected
in the drop-down list.
This image shows verification within the Resource Management section of
Cisco Unified Video Conferencing Manager that the Cisco IOS Gatekeeper was
added successfully. Here you can see the Cisco IOS H.323 Gatekeeper listed with
the IP address of 172.16.1.100.
This image shows the Auto Attendant configuration in the Cisco Unified
Video Conferencing that displays the e.164 address (1234567890) that
corresponds to the Null called number configured on CUBE.
This images shows what the Cisco IPVC Video IVR will send back to the
calling Video Endpoint. Using the remote control or keypad control of the video
endpoint, the user chooses a video meeting via DTMF (in-band) that is hosted on
the CUVC MCU and join the appropriate video meeting.
There is currently no specific troubleshooting information available
for this configuration.