Document ID: 111313
Updated: Dec 10, 2009
Contents
Introduction
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 efficiencies.
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 B2B communications.
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.
Prerequisites
Requirements
Ensure that you meet these requirements before you attempt this configuration:
-
Basic knowledge of how to configure and use Cisco IOS voice (such as dial peers)
-
Basic knowledge of how to configure and use CUBE
-
Basic understanding of how firewalls work
Components Used
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 15.0.1M
-
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.
Conventions
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Configure
In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the commands used in this section.
Network Diagram
This diagram shows CUBE external endpoints securely dialing into the customer network via an internal endpoint IP address.
Diagram Call Flow
-
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 signaling.
-
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.
Configurations
This document uses these configurations:
| CUBE Configuration |
|---|
! version 12.4 service timestamps debug datetime localtime service timestamps log datetime msec service password-encryption service sequence-numbers ! hostname cube1 ! boot-start-marker boot system flash:c2800nm-adventerprisek9_ivs-mz.124-22.YB.bin boot-end-marker ! ip source-route ! ! multilink bundle-name authenticated ! ! ! voice service voip allow-connections h323 to h323 h323 emptycapability null-called-number override 1234567890 h225 start-h245 on-connect call start slow h245 passthru all ! ! ! voice class h323 10 ! ! voice-card 0 ! ! ! ! interface GigabitEthernet0/0 ip address 172.16.1.100 255.255.255.0 ip route-cache same-interface duplex auto speed auto 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 destination-pattern .T !--- To match outbound call leg to send to GK process session target ras incoming called-number . !--- For inbound call leg codec transparent ! ! gateway timer receive-rtp 1200 ! ! ! gatekeeper zone local vgk1 cisco.com zone remote CUVCM cisco.com 10.1.1.26 invia vgk1 outvia vgk1 enable-intrazone 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 no shutdown ! end |
| ASA Configuration |
|---|
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. ! interface Ethernet0/0 no nameif no security-level no ip address ! interface Ethernet0/0.2 vlan 2 nameif inside security-level 100 ip address 10.1.1.1 255.255.255.0 ! interface Ethernet0/0.12 vlan 12 nameif dmz security-level 50 ip address 172.16.1.1 255.255.255.0 ! interface Ethernet0/0.500 vlan 500 nameif outside security-level 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 .150.0 255.255.255.0 !--- 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 nat-control 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 172.168.1.0 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. ! policy-map global_policy class inspection_default inspect h323 h225 inspect h323 ras |
Verify
Use this section to confirm that your configuration works properly.
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.
Troubleshoot
There is currently no specific troubleshooting information available for this configuration.
Related Information
Open a Support Case 
(Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.