Guest

Cisco Unified Border Element

Unified Border Element (CUBE) with Unified Videoconferencing (CUVC) IVR Configuration Example

Document ID: 111313

Updated: Dec 10, 2009

   Print

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.

cube-cuvc-01.gif

Diagram Call Flow

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

cube-cuvc-02.gif

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.

cube-cuvc-03.gif

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.

cube-cuvc-04.gif

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.

cube-cuvc-05.gif

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Related Information

Updated: Dec 10, 2009
Document ID: 111313