Академический Документы
Профессиональный Документы
Культура Документы
Cisco Press
800 East 96th Street
Indianapolis, IN 46240
ii
000_9780133845969_frontm.indd ii
6/24/14 3:40 PM
iii
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been
appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of any
trademark or service mark.
Special Sales
For information about buying this title in bulk quantities, or for special sales opportunities (which
may include electronic versions; custom cover designs; and content particular to your business,
training goals, marketing focus, or branding interests), please contact our corporate sales department at corpsales@pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact international@pearsoned.com.
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each
book is crafted with care and precision, undergoing rigorous development that involves the unique
expertise of members from the professional technical community.
Readers feedback is a natural continuation of this process. If you have any comments regarding
how we could improve the quality of this book, or otherwise alter it to better suit your needs, you
can contact us through email at feedback@ciscopress.com. Please make sure to include the book
title and ISBN in your message.
We greatly appreciate your assistance.
Publisher: Paul Boger
iv
vi
Dedication
This book is dedicated first to my family, my dear wife Kanika and my lovely sons
Shivansh and Shaurya, for without their support, encouragement, and patience, it would
not exist. Secondly, to my parents, Vijay Behl and Ravi Behl, and my brothers, Nikhil
Behl and Ankit Behl, who have always been there to support me and guide me in all my
endeavors.
Acknowledgments
I would like to thank the following amazing people and teams for helping me create this
book:
My wife, Kanika, and my kids, Shivansh and Shaurya, for sacrificing many days and
weekends over the past year so that I could work on this book. Without their patience
and support, this book would not have been possible.
The technical reviewer, Paulo Lopes, for his invaluable feedback and for providing
exceptional technical coverage.
The Cisco Press editorial team: Brett Bartow, the executive editor, for seeing the value
and vision in the proposed title and providing me the opportunity to build this title; and
Marianne Bartow, development editor, and Christopher Cleveland, senior development
editor, for their support and guidance all throughout. It is my sincere hope to work again
with them in the near future.
Everyone else in the Cisco Press production team, for their support and commitment.
vii
Contents at a Glance
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Chapter 6
Chapter 7
Chapter 8
Chapter 9
Chapter 10
viii
Contents
Chapter 1
18
18
18
ix
Layer 2 Marking
34
Layer 3 Marking
35
38
43
44
48
Medianet 49
Medianet QoS Classes of Service 52
Chapter 3
84
Digital Telephony 85
Integrated Services Digital Network 85
Q Signaling Protocol 87
Channel Associated Signaling 87
T1 CAS 87
E1 R2 88
Non-Facility Associated Signaling
88
90
102
104
xi
106
107
107
108
110
111
Time-of-Day Routing
112
123
126
135
Mobile Connect
136
133
138
140
142
xii
Chapter 5
145
145
146
Layer 2 Security
147
149
149
802.1x 149
Layer 3 Security
151
151
152
154
Port-Based ACLs
154
xiii
Chapter 6
167
168
169
171
172
174
175
178
180
184
187
Intersite Networking
188
191
192
193
xiv
Chapter 8
209
209
210
214
215
216
225
225
237
238
239
242
249
252
254
xv
xvi
Communication
Server
PC
PC with
Software
Terminal
File
Server
Sun
Workstation
Macintosh
Access
Server
ISDN/Frame Relay
Switch
Ciscoworks
Workstation
ATM
Switch
Modem
Token
Ring
Token Ring
Printer
Laptop
Web
Server
IBM
Mainframe
Front End
Processor
Cluster
Controller
Multilayer
Switch
FDDI
Gateway
Router
Network Cloud
Bridge
Line: Ethernet
Hub
Line: Serial
DSU/CSU
DSU/CSU
FDDI
Catalyst
Switch
xvii
Boldface indicates commands and keywords that are entered literally as shown.
In actual configuration examples and output (not general command syntax),
boldface indicates commands that are manually input by the user (such as a
show command).
Braces within brackets ([{ }]) indicate a required choice within an optional
element.
Chapter 1
Cisco Collaboration
Infrastructure
Distributed deployment model: The call control is dispersed across multiple remote
sites and multiple campus and/or centralized deployments that are interconnected
over a QoS-enabled WAN.
These three broad deployment models can be further classified into the following categories of UC deployment models, which are described in more detail in the following
subsections:
Single-site
Apart from the preceding on-premises models, Cisco offers cloud-based (managed)
Collaboration solutions such as Cisco Hosted Collaboration Solution (HCS) and Cisco
Hosted Unified Communications Services.
Media Resources
Infrastructure
Internet
CUCM
Cluster
CC
PSTN
V
Endpoints
Figure 1-1
The following are some best practices associated with the single-site deployment model:
Ensure that the infrastructure is highly available, enabled for QoS, and configured to
offer resiliency, fast convergence, and inline power.
Deploy QoS from IP Phone (user access layer) to CUCM (data center access layer) to
gateways for optimum voice quality.
Use a high-quality, low-compression codec such as G.711 for highest audio quality.
This also allows digital signal processor (DSP) resources to be allocated for conferencing or media termination point (MTP).
Deploy voice gateways or Session Border Controller (SBC) for Session Initiation
Protocol (SIP) trunks to the IT service provider (ITSP) for off-net calls to the PSTN
or a legacy PBX. All on-net calls should be limited to a central site based on calling
patterns for your enterprise.
Media Resources
Infrastructure
Internet
CUCM
Cluster
IP WAN
CC
PSTN
V
Endpoints
V
Endpoints
Figure 1-2
The following are some best practices associated with the multisite WAN with centralized call processing deployment model:
Use CUCM locations-based Call Admission Control (CAC) or Cisco IOS Resource
Reservation Protocol (RSVP)-based CAC. This prevents oversubscription of the IP
WAN as a result of voice calls.
Deploy Automated Alternate Routing (AAR) if the WAN bandwidth is full and CAC
doesnt allow for new calls via the IP WAN.
Deploy SRST for remote sites to ensure that the branch router has the capacity for
handling IP Phone registration in case of a WAN failure. The voice gateway also
provides local PSTN connectivity for remote site endpoints so that emergency calls,
toll-free calls, and calls local to a region use the local gateway instead of the IP
WAN to the campus PSTN SBC or router.
Deploy a low-bandwidth audio codec (for example, G.729) between remote sites and
the central site and deploy G.711 within a site for optimum voice quality.
Deploy DSP resources at remote sites for conferencing, transcoding, or MTP resources.
Media Resources
Infrastructure
Internet
CUCM
Cluster
CUCM
Cluster
IP WAN
V
CC
PSTN
V
Endpoints
Endpoints
Figure 1-3 Multisite WAN with Distributed Call Processing Deployment Model
001_9780133845969_ch01.indd 4
6/24/14 4:23 PM
The following are some best practices associated with the multisite WAN with distributed call processing deployment model:
Deploy SIP proxies such as the Cisco Unified SIP Proxy (CUSP) to provide call routing and SIP signaling normalization.
In addition to other specific best practices for this model, follow general guidelines
for the single-site and multisite WAN with centralized call processing models.
Infrastructure
Internet
Internet
IP WAN
V
CUCM
Cluster Over WAN
PSTN
V
PSTN
V
Endpoints
Endpoints
Figure 1-4
The following are some best practices associated with the clustering over WAN call processing deployment model:
The round-trip time (RTT) for cluster over WAN call processing should not be more
than 80 ms.
Network Services
This section covers the various network services essential for a functional Cisco
Collaboration solution:
Network Services
In Example 1-1, the ip dhcp excluded-address command helps segregate addresses from
the assignment pool so they are not assigned to any endpoint. The DHCP pool defines a
network from which the endpoints can get their IP address, option 150, and other parameters, as explained earlier.
001_9780133845969_ch01.indd 7
6/24/14 4:24 PM
Figure 1-5
This should be performed even if the system is configured to use DNS (that is, the DNS
client is enabled on the cluster servers).
Certificate Trust List (CTL) files (only if the cluster is in mixed mode)
Identity Trust List (ITL) files (for all endpoints that register with CUCM)
Network Services
Background images
The Cisco Unified IP Phone to TFTP interaction process can be best illustrated by going
through the IP Phone bootup cycle, as shown in the following steps:
Step 1.
Step 2.
Step 3.
As the IP Phone receives power and boots, the switch sends a Cisco
Discovery Protocol (CDP) packet to the IP Phone. This CDP packet provides
the IP Phone with voice VLAN (also known as auxiliary VLAN) information
so that the IP Phone can reach the appropriate VLAN and initiate a DHCP
request.
Step 4.
Step 5.
The IP Phone contacts the Cisco TFTP server or external TFTP server to
request firmware and files. The TFTP server sends the configuration information for that IP Phone, which contains an ordered list of up to three CUCM
servers or two CUCM servers and an SRST reference. If the IP Phone was
manually preconfigured in CUCM, the SEP<MAC address>.cnf.xml file is
downloaded for that phone. Otherwise, the XMLDefault.cnf.xml configuration file is used for IP Phones that request auto-registration.
Step 6.
The .cnf.xml file indicates the firmware load that the IP Phone should be running. If this image load differs from the one that is currently on the IP Phone,
the phone contacts the TFTP server to request the new firmware load file,
which has a .bin file extension. The IP Phone installs the firmware in its nonvolatile RAM and reboots.
Step 7.
After rebooting, the IP Phone downloads other information such as the softkey template and phone button template. The IP Phone attempts to make a
TCP connection to a CUCM server that is considered the highest priority in
its list. The phone registers to the CUCM server and obtains a directory number (DN).
10
Cisco TFTP service can be supported in multiple ways to serve local and remote-site
Cisco Unified IP Phones:
Cisco TFTP Server: The default method of using one or more CUCM servers in
the cluster as TFTP servers that allows IP Phones to download the firmware, configuration, and other files. This is an ideal model for an enterprise environment with
high-speed WAN links because the Cisco Unified IP Phones at a remote site will
download firmware during initial setup or firmware upgrade via centralized TFTP
servers. In case of the multisite WAN with distributed call processing deployment
model or the clustering over WAN call processing deployment model, CUCM TFTP
servers can be deployed at larger remote sites to serve local phones. Cisco CUCM
also supports proxy TFTP that enables phones to sync with a proxy TFTP server
that forwards the requests to their respective clusters. This is especially useful in the
case of multiple phones tied to multiple clusters at remote sites. It saves the overhead
of manually defining multiple option 150 for IP Phone subnets to the correct TFTP
servers.
Load Server: A CUCM administrator can assign a TFTP server to each individual
phone record using the Load Server parameter. Assigning the Load Server parameter
is particularly useful for remote sites where downloading firmware to the phone
is difficult due to lower WAN speeds. In such cases, a CUCM administrator can
deploy local TFTP servers (Windows- or IOS-based TFTP) to allow the phones to
operate at remote sites without having to traverse the WAN for firmware download.
To enable the Load Server parameters on a per-phone basis, go to the Cisco Unified
CM Administration page, choose Device > Phone, and select the phone for which
a particular load server is to be defined. Browse to Product Specific Configuration
Layout, define the Load Server IP address/hostname, and enable the same.
Peer Firmware Sharing (PFS): PFS is a feature that allows phones participating in
this firmware distribution model to form a peering relationship in a tree-based hierarchy. One phone peers with two other phones. The administrator, however, does
not need to designate parents (phones initiating PFS) and hosts (phones accepting
PFS). All the peer-enabled Cisco Unified IP Phones on a given IP subnet form a tree
structure to distribute the firmware. After the peering relationship is established, the
root phone retrieves the firmware files from the Cisco TFTP server and distributes
them to the associated peers. This helps to reduce the load on the WAN during firmware upgrades and minimize the overall time needed to upgrade remote-site phones.
PFS is supported with Cisco Unified IP Phone firmware 8.3(1) and later. To ensure
that the phones are participating in a PFS distribution, go to the Cisco Unified CM
Administration page, choose Device > Phone, and select the phone that should be
enabled for PFS. Browse to Product Specific Configuration Layout and ensure that
the Peer Firmware Sharing option is enabled.
Network Services
11
CUCM automatically synchronizes the NTP time of all subscribers in the cluster to the
publisher. During installation, each subscriber is automatically configured to point to an
NTP server running on the publisher. Cisco recommends using an NTP time source with
NTP stratum 3 or better (the lower the better). An NTP time source can be added to the
CUCM publisher by navigating to the Cisco Unified Operating System Administration
page and choosing Settings > NTP Servers, as shown in Figure 1-6.
Skinny Call Control Protocol (SCCP) endpoints leverage the CUCM publishers NTP
source implicitly. You can add a phone NTP reference for SIP endpoints. To add a phone
NTP reference in CUCM, go to the Cisco Unified CM Administration page and choose
System > Phone NTP Reference. You must assign this NTP reference to a date/time
group, which in turn is assigned to a device pool.
12
Figure 1-6
Device ID
Port ID
Address
Capabilities
Version
Platform
Native VLAN
CDP messages are made up of Version, Time to Live (TTL), and Checksum fields, followed by a number of Type, Length, and Value (TLV) fields. Table 1-1 illustrates various
CDP TLV fields.
Network Services
Table 1-1
13
Description
Device ID
Address
Port ID
Specifies the port from which the CDP update is sent (outgoing
port)
Capabilities
Version
Platform
Full/Half Duplex
VTP Domain
Management Address
Example 1-3 illustrates how to access CDP timer, holdtime, and version information as
well as CDP discovery information.
Example 1-3 CDP Information
UCSwitch# show cdp
Global CDP information:
Sending CDP packets every 60 seconds
Sending a holdtime value of 180 seconds
Sending CDPv2 advertisements is enabled
!
UCSwitch# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater
Device ID
Local Intrfce
Platform
Port ID
CM91PUB
Fas 0/30
Holdtme
135
Capability
H
VMware
eth0
CUPS91
Fas 0/26
169
VMware
eth0
UCRouter
Fas 0/24
163
R S I
CISCO3945-Gig 0/0
14
Disabling CDP is useful when phones are not connected to switch ports, and for security
reasons, such as hiding device details that you may not want to share with other infrastructure components.
Description
Port Description
System Name
System Description
System Capabilities
Management Address
Port VLAN ID
MAC/PHY
Configuration/Status
15
Example 1-5 illustrates LLDP configuration on a Cisco switch at a global level and an
individual interface level.
Example 1-5 LLDP Information
UCSwitch# show lldp
% LLDP is not enabled
!
UCSwitch(config)# lldp run
!
UCSwitch(config)# interface FastEthernet 0/1
UCSwitch(config-if)# lldp transmit
UCSwitch(config-if)# lldp receive
Midspan power injector: Sits between a switch port and the IP Phone and supplies
power to the IP Phone
Cisco supports two types of inline power delivery as PoE: the Cisco original implementation (Cisco proprietary) and the IEEE 802.3af standards-based PoE. The original Cisco
implementation has the following features:
Provides .48 V DC at up to 6.3 to 7.7 W per port over data pins 1, 2, 3, and 6.
After first developing (pre-standard) PoE, Cisco worked with IEEE to create a standardsbased PoE delivery mechanism to develop what is currently known as the IEEE 802.3af
standard, which has the following features:
Specifies .48 V DC at up to 15.4 W per port over data pins 1, 2, 3, and 6 or over the
spare pins 4, 5, 7, and 8 (power sourcing equipment [PSE] can use one or the other,
but not both).
16
The process via which PoE-enabled switches detect and power a Cisco Unified IP Phone
varies depending on whether you are using the Cisco original standard or the IEEE standards-based implementation. If you employ the Cisco-proprietary method, a switch sends
a Fast Link Pulse (FLP) to the connected device. When the connected device loops the
FLP back to the switch, the switch starts supplying power over the Ethernet connection
to the device. If you use IEEE 802.3af, the switch applies a voltage in the order of 2.8 to
10 V, and if a resistance of 25K ohm is detected, the switch supplies power to the connected device.
It is recommended to deploy PoE-capable switches at the campus access layer within wiring closets to provide inline-powered Ethernet ports for IP phones, thus eliminating the
need for wall power. If the switches are non-Cisco switches, LLDP-MED can be used to
detect power and voice VLAN.
To provide QoS marking and classification for real-time voice traffic vis--vis data
traffic
17
Example 1-6 illustrates configuration of voice and data VLANs on a Cisco Catalyst
switch.
Example 1-6 Voice and Data VLAN Configuration
UCSWITCH(config)# vlan 100
UCSWITCH(config-vlan)# name Data-VLAN
!
UCSWITCH(config)# vlan 200
UCSWITCH(config-vlan)# name Voice-VLAN
!
UCSWITCH(config)# interface range FastEthernet 0/1 - 10
UCSWITCH(config-if-range)# switchport mode access
UCSWITCH(config-if-range)# switchport access vlan 100
UCSWITCH(config-if-range)# switchport voice vlan 200
UCSWITCH(config-if-range)# spanning-tree portfast
Inter-VLAN routing
For optimum performance of the Cisco Collaboration solution, the network should be
modeled after Ciscos recommended core, distribution, and access (CDA) layer approach.
Layer 3 routing protocols such as Routing Information Protocol (RIP), Enhanced Interior
Gateway Routing Protocol (EIGRP), and Open Shortest Path First (OSPF) are commonly
employed in unified IP environments. Routing protocol parameters such as timers,
path/link costs, and route summaries can be used to optimize and control convergence
times and distribute traffic across multiple paths. Cisco recommends using the passiveinterface command to prevent routing neighbor adjacencies via the access layer.
18
design is to introduce and enable a hierarchy in the network infrastructure. This allows
each network layer to play a specific role, thus ensuring scalability, reliability, and better
management.
Campus-wide VLANs are based on the flat design model, meaning they avoid the logical,
hierarchical structure and the route summarization provided by routers. Layer 3 switching
provides the same advantages as routing in campus network design with the added performance boost from packet forwarding handled by specialized hardware. Layer 3 switching in the distribution layer and core of the campus segments the campus into smaller,
more manageable pieces. A multilayer approach combines Layer 2 switching with Layer 3
switching to achieve robust, highly available campus networks.
19
with Virtual Switching System (VSS) can be used to aggregate two Catalyst Supervisor
Engines to act as one.
Traditional Cisco campus design: Traditional design with Layer 2 at the access layer
and Layer 3 at the distribution and core layers
Core
Layer 3
Layer 3
Distribution
Layer 2
Access
Layer 2
Figure 1-7
Compared to the traditional Cisco campus design, the routed access campus design
(combining Layer 3 switching at the access and distribution layers) provides the fastest convergence of voice and data traffic flows. Other advantages over the traditional
approach include a single control plane, dynamic traffic load balancing, and use of a
single set of tools for troubleshooting.
20
The following best practice recommendations apply to the L2/L3 campus network
design:
Use Layer 3 links beginning with the access layer connecting to the distribution and
core layers for maximum redundancy and fastest convergence time in case of link or
device failure.
The access layer switches should have dual connectivity to distribution switches and
support the required QoS features.
All Cisco Collaboration device switch ports (e.g., IP phones) should be put in
spanning-tree PortFast so that they can move to a fully operational state as fast as
possible.
Spanning tree should be limited to access switches, and Layer 3 links should be used
between access, distribution, and core switches.
Two colons (::) can be used to compress successive hexadecimal fields of 0s at the
beginning, middle, or end of an IPv6 address. However, this can be done only once
in an address; that is, one instance of :: is allowed per address.
21
Multicast: Similar to IPv4, IPv6 multicast allows a host to send a single data stream
to a subset of all hosts simultaneously.
Link-local
Figure 1-8
Unique-local
Global
Unique-local address: IPv6 unicast address that uses the prefix FEC0::/10 (1111
111011) and concatenates the subnet identifier (the 16-bit field) with the interface
identifier. Unique-local addresses are analogous to RFC 1918 private addresses in
IPv4 and are not advertised beyond the local site. They are used for local communications, inter-site VPNs, and so forth. Subnet IDs are typically defined using a hierarchical addressing plan to allow for route summarization.
22
Global address: Address that is routable across the Internet. Global addresses constitute IPv6 addresses for widespread generic use and are structured as a hierarchy to
allow address aggregation. Global addresses are identified by their three high-level
bits set to 001 (2000::/3). These are the unique addresses assigned by service providers or regional registries for participation in the public network.
In context of IPv6, CUCM supports one link-local address, one unique-local address or a
global address, and an IPv4 address.
Cisco Unified IP Phones can support one link-local address, multiple unique-local
addresses, multiple global addresses, and an IPv4 address. If the phone has both uniquelocal and global addresses, the global addresses take precedence over unique-local
addresses. If multiple unique-local addresses or multiple global addresses exist, the first
address configured is used as the signaling and media address sent to CUCM. Cisco
Unified IP Phones use one IPv6 address (global or unique-local) for CUCM signaling and
media.
When configured for receiving an IPv6 address, Cisco Unified IP Phone IPv6 address
selection priority is as follows:
1. If configured, use the address that has been manually configured via the IP
Phones UI.
2. If an address has not been manually configured, use DHCPv6 to assign an address.
3. If neither a DHCPv6 address nor a manually configured address is available, and
Stateless Address Autoconfiguration (SLAAC, RFC 2462) is enabled for the IP Phone
(CUCM default is on), the IP Phone uses SLAAC to create an IPv6 address. The
router RA O bit should be set.
Cisco IOS devices support one link-local address, multiple unique-local addresses, multiple global addresses, and multiple IPv4 addresses. Cisco IOS routers use link-local
addresses for routing protocols and use the address selection algorithm (RFC 3484) for
applications running on routersfor example, Telnet, Secure Shell (SSH), and so on. For
responses to devices, routers attempt to use the same network prefix as the device that is
initiating communication.
To allow IPv6-based call processing, IPv6 must first be enabled throughout a CUCM
cluster. This involves the following steps:
Step 1.
Step 2.
Step 3.
23
The following are IPv6 deployment guidelines for Cisco Collaboration infrastructure:
LAN and WAN environments must be considered when deploying IPv6, as most
applications and infrastructure components may be configured for or support IPv4.
Dual-stack deployments offer the best approach when introducing IPv6 into any
network environment, as both IPv4 devices and dual-stack IPv4/v6 devices can interoperate. Disruption to the existing network is minimal.
Infrastructure can be simplified and consolidated using virtualized computing platforms to reduce server count, network ports, cabling, and power consumption.
Cisco offers many virtualization solutions for Cisco Collaboration environments, ranging
from desktop to data center. Some of the virtual solutions for Cisco Collaboration are
listed in Table 1-3.
Table 1-3
Virtual Solution
Description
Cisco UCS
Cisco Virtualization
Experience Infrastructure
(VXI)
Cisco Virtualization
Experience Media Engine
(VXME)
Cisco Virtualization
Experience Client (VXC)
A thin client designed to easily integrate into a virtualized infrastructure. This is a subcomponent of the Cisco VXI solution.
24
Virtual Solution
Description
Used for managing and deploying VXC thin client. This is a subcomponent of the Cisco VXI solution.
UCS Manager can be used to manage both B-Series and C-Series servers. Integration
between VMware vCenter and Cisco UCS Manager provides unparalleled control over
physical and virtual assets.
For virtualization, Cisco UCS supports hypervisors, including VMware ESXi and Citrix
XenServer. Cisco UCS interacts with Fabric Extenders or Fabric Interconnects to communicate with other data center infrastructure, including SAN switches, storage, and Cisco
Nexus. Cisco UCS supports Fibre Channel over Ethernet (FCoE). Figure 1-9 depicts a
Cisco UCSbased virtualized UC application and network architecture.
Cisco UCS leverages the concept of service profiles for statelessness. This allows for any
damaged hardware (blade) to be changed without affecting the virtual machines (VM)
running on it. The VMs can be moved to another blade by disassociating the service profile from a nonfunctional blade to a functional one.
Cisco UC application configuration templates are available in Open Virtualization
Archive (OVA) format, which allows administrators to build and configure UC applications. For most supported UC applications, preconfigured OVA templates are available
on Cisco.com. If an OVA template is not available for an application, the administrator
must manually build OVA files that meet the indicated requirements. Cisco has stringent
requirements for co-residency of UC applications with non-Cisco or non-UC applications.
The Cisco-recommended guidelines for co-residency can be found at http://
docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines.
25
UC Applications
(Guest Virtual Machines)
VMware
Hypervisor
B-Series Blade
Fibre Channel
Ethernet
LAN Switch
Figure 1-9
Nexus 5000
Series Switch
Storage Array
SAN Switch
(MDS 9000 Series)
While virtual machine (OVA) definitions, VMware product, version, and feature support,
VMware configuration requirements for UC, and application/VM co-residency policy
remain consistent across all three support models, there are a few things to consider when
going with one model or another. For example, a TRC model is configuration based,
whereas UCS Specs-based and Third-party Server Specs-based models are rules based.
For details and updated information, refer to http://docwiki.cisco.com/wiki/
UC_Virtualization_Supported_Hardware.
26
The answer file generator also has the following areas to complete in the Primary Node
Configuration and Secondary Node Configuration sections:
NIC Interface Settings: Use Auto Negotiation, NIC Speed, NIC Duplex, MTU Size
Network Time Protocol: NTP Server(s) information (only for primary node)
IP Multicast
27
After the platformConfig.xml file is generated, you can use it to install primary and secondary nodes in a UC application cluster by following these steps:
Step 1.
Create a virtual floppy image using a virtual floppy program (for example,
WinImage or RawWrite).
Step 2.
Insert the platformConfig.xml file into the virtual floppy image and save the
resulting image with a .vmd or .flp extension.
Step 3.
Upload the virtual floppy image to a datastore accessible from VSphere. For
SAN storage, go to View > Inventory > Datastores. For local storage (such as
an internal hard drive), select the host and click the Summary tab. Browse the
datastore and upload the virtual floppy image to it.
Step 4.
From the VSphere client, go to Inventory > Virtual Machine > Edit Settings.
In the dialog box that opens, select Floppy Drive on the Hardware tab. Click
the Use Existing Floppy Image in Datastore radio button, click Browse,
browse to and choose the virtual floppy image, and click OK.
Step 5.
In the Device Status area of the Hardware tab, check the Connected and
Connect at Power On check boxes. Click OK in the lower-right corner.
Step 6.
Proceed with installation of the UC application using the ISO file from the
datastore.
Step 7.
Step 8.
IP Multicast
IP multicast can be used for various functions in a Cisco Collaboration network. The
most common services that leverage IPv4 or IPv6 multicast are
Multicast Music on Hold (MoH) for branch sites. (Cisco Unified IP Phones support
only IPv4 multicast MoH. IPv6 multicast MoH is not supported.)
Cisco SAF forwarder automatic discovery and communication with other SAF
forwarders.
To allow the use of multicast for all the preceding services, the underlying network infrastructure must support the forwarding of multicast IP traffic from the CUCM servers or
28
endpoints or gateways to respective VLANs across the campus and extended network
(inter-domain).
Protocols commonly used to enable multicast in a campus environment include the
following:
IPv6 multicast is based on the same basic principles as IPv4 multicast. The major differences being that IPv6 relies on multicast for more functions, such as neighbor discovery
and node autoconfiguration. Moreover, Mobile IPv6 relies heavily on IPv6 multicast for
their operations. IGMP is replaced by Multicast Listener Discovery (MLD) in IPv6.
Cisco WLC
The interaction between endpoints and wireless APs is where Wi-Fi primarily comes into
play; the rest is an augmentation to existing wired infrastructure.
Cisco WLC
29
CUCM
Lightweight AP
Switch
Cisco Unified IP
Laptop with
Phone (Wireless) Softphone (Jabber)
Figure 1-10
Switch
LDAP
Cisco Unified IP
Phone (Wired)
For a successful VoWLAN solution deployment, certain conditions must be met. They
are as follows:
Noise levels should not exceed 92 dBm with a signal-to-noise ratio (SNR) of
25 dB.
Packet error rate (PER) should not exceed 1 percent and Jitter should be less than
100 ms.
To avoid one-way audio issues resulting from different power settings between Wi-Fi
IP phones and access points, World mode (IEEE 802.11d) should be configured.
QoS for voice VLAN must be enabled on Cisco WLC and APs such that the markings match those on wired infrastructure. IEEE 802.11e UP markings should be
matched to Voice, Video, and Signaling DSCP markings (Voice EF = 6, Video AF41
= 5, and Signaling AF31 = 4).
Chapter 2
Voice and video over IP trafc consists of two parts: media/bearer trafc and signaling
trafc. Media trafc is based on the Real-time Transport Protocol (RTP), which runs
on top of the User Datagram Protocol (UDP). Signaling trafc is based on a number
of protocols, such as Session Initiation Protocol (SIP), Skinny Call Control Protocol
(SCCP), H.323 protocol, and Media Gateway Control Protocol (MGCP), all of which are
TCP/UDP based. When an RTP packet is lost, re-creating or retransmitting it is neither
possible nor worthwhile. As its name indicates, RTP works in real time, so any attempt to
restore missing packets would not make sense because the packets would arrive out of
order/sequence during a live conversation.
In todays converged networks where voice, video, and data coexist, it is important to
treat voice and video trafc differently from data trafc, which is mostly TCP based and
is easily retransmitted without loss of quality. Quality of service (QoS) enables network
administrators to leverage tools for providing special treatment for delay and timesensitive trafc such as voice. The network infrastructure must provide classication,
policing, and scheduling services for multiple trafc classes.
Voice quality is directly affected by the following three QoS factors:
Latency (delay): The unwarranted time required for a packet to traverse the network
from source to destination
Packet loss: Packets lost in transit from source to destination due to network congestion, link flapping, or other reasons
Many sources of delay are introduced both during a packet formation and during transit
from source to destination, as outlined in Table 2-1. Moreover, the delay can be either
a xed delay or a variable delay depending on where it is introduced. Fixed delay adds
to overall delay introduced from source to destination. Variable delay is a function of
queues and buffers.
32
Table 2-1 Sources of Delay During Voice Packet Formation and Traversal from Source
to Destination
Delay
Description
Coder delay
Packetization delay
The time it takes to put a payload (encoded voice) into a voice packet
and encapsulate it within IP, UDP, and RTP headers. Its a fixed delay
function.
Queuing delay
The delay experienced as a frame is queued waiting to be transmitted on a link. Its a variable delay function because it depends on link
speed.
Serialization delay
The time taken to put a frame on the wire from a network interface.
Its a fixed delay function.
Propagation delay
The time taken for a bit to traverse a network link (from one end to
the other).
De-jitter delay
Voice bearer traffic should be marked to DSCP EF per the QoS baseline and
RFC 3246.
Additionally, for voice calls, the following are recommended leading practices:
17 to 106 kbps of guaranteed priority bandwidth should be provided per call for
media (depending on the sampling rate, codec, and Layer 2 overhead).
150 bps + Layer 2 overhead guaranteed bandwidth should be provided for voicecontrol traffic per call.
33
Congestion avoidance
Traffic policing
Traffic shaping
Medianet
Figure 2-1 illustrates the QoS tools order of operation at a high level.
Classification/
Marking
IP Precedence
DSCP
RSVP
ACLs
Figure 2-1
Policing
Queuing
Traffic Policing
Rate Limiting
LLQ
CBWFQ
WRED
Shaping/
Fragmentation
FRTS
LFI
FRF.12
MLP
QoS operation largely depends on QoS policies provisioned in a network. It starts with
classification and marking, followed by policing, queuing, and, finally, shaping and fragmentation. It is essential to plan and deploy end-to-end QoS in LAN, WAN, and virtualized environments to ensure that voice and video quality is acceptable. The sections that
34
follow discuss QoS tools and their application. The following QoS tools and applications,
as well as considerations for LAN, WAN, wireless, and virtualized environments, are covered in this chapter.
Layer 2 Marking
Class of service (CoS) markings are applied to frames that transit an 802.1Q trunk. An
IEEE 802.1Q tag consists of Tag Protocol ID (TPID) and Tag Control Information (TCI)
fields. Figure 2-2 depicts the Layer 2 frame with IEEE 802.1Q tag.
IEEE 802.1Q
VLAN Tag
802.1Q Frame
Preamble
(8)
Destination
Address
(6)
Source
Address
(6)
User Priority
(3)
TPID
(2)
TCI
(2)
Type/
Length
(2)
CFI
(1)
Data
(Payload)
FCS
(2)
VLAN ID
(12)
Figure 2-2
The TPID field is a 2-byte field and contains a fixed value of 0x8100 that indicates a
tagged (802.1Q) frame. The TCI field is a 2-byte field that contains three subfields:
User Priority: A 3-bit field used to reflect the QoS priority of the frame
Canonical Format Indicator (CFI): A 1-bit field that indicates whether the type of
information that a frame carrier is in a canonical (Ethernet) or noncanonical (Token
Ring) format
VLAN ID: A 12-bit field that indicates the VLAN from which the frame originated
CoS markings leverage the 3 bits from the User Priority field from within the TCI field
in a 802.1Q tagged frame. Because CoS markings use 3 bits, CoS values range from 0
through 7, with values 6 and 7 being reserved.
Layer 3 Marking
At Layer 3 (network layer), packet marking can be accomplished using the ToS byte in an
IPv4 header. Two predominant types of marking mechanisms leverage the ToS byte: IP
Precedence and Differentiated Services Code Point (DSCP).
IP Precedence is an old approach and has been successively replaced by DSCP for marking IP packets. IP Precedence uses the 3 leftmost bits in the ToS byte. With 3 bits to use,
IP Precedence values can range from 0 to 7, with 6 and 7 reserved. The fields in the ToS
byte are as follows:
(IP) Precedence: A 3-bit field used to specify the relative priority or importance of a
packet
Type of Service (ToS): A 4-bit field that defines how the network should make
trade-offs between throughput, delay, reliability, and cost
DSCP, on the other hand, uses the 6 leftmost bits from the ToS byte in an IPv4 header as
the DiffServ (DS) field. With 6 bits, DiffServ has up to 64 DSCP values (0 to 63) that are
assigned to various classes of traffic. The Internet Engineering Task Force (IETF) recommends selective DSCP values for use to maintain relative levels of priority. These selective
values are called Per-Hop Behaviors (PHB) and determine how packets are treated at each
hop along the path from the source to the destination. The subfields in the DS byte are as
follows:
DiffServ: A 6-bit field used to specify the DSCP value (and therefore PHB) of a
packet
Figure 2-3 illustrates the relationship between the ToS byte, IP Precedence, and DSCP
fields.
36
IPv4 Packet
ToS
Precedence
ToS
MBZ
IP Precedence
DSCP
Figure 2-3
CU
When configuring a router to mark or recognize a DSCP value, decimal numbers or the
name of a specific DSCP value can be used. The four different DiffServ PHBs are as
follows:
Assured Forwarding (AF): Specifies four AF PHBs grouped into four classes. When
using AF, the first 3 bits of the DS field define the queuing class (1 to 4), and the last
3 bits define the drop precedence (1 to 3). AF therefore has 12 classes to it and provides assurance that a packet is forwarded as long as it doesnt exceed the subscribed
rate.
Best Effort (BE): Specified when all 6 bits of the DS field are 0; that is, the packet
doesnt need any specific QoS treatment or doesnt meet the requirements of any of
the other defined classes. BE is also known as default PHB.
Class Selector (CS): Used for backward compatibility with network devices and
applications that use IP Precedence. When using this PHB, the last 3 bits of the
DSCP field are 0.
Expedited Forwarding (EF): States a low-delay, low-loss, and low-jitter QoS treatment with guaranteed bandwidth.
and is deployed using the Cisco Modular Quality of Service Command-Line Interface
(MQC) framework. The following configuration example illustrates NBAR configuration
to match all RTP traffic (audio, video, payload type) based on protocol rather than UDP
port values:
UCRouter(config)# class-map match-any rtp
UCRouter(config-cmap)# match protocol rtp
NBAR can be deployed if you are using IPv4 addressing, whereas NBAR2 can be
deployed if you are using an IPv6 addressing scheme. NBAR is based on the Service
Control Engine (SCE) and is backward compatible.
Network Service/Application
Classification/Service Class
EF (DSCP 46)
CS1 (DSCP 8)
BE (DSCP 0)
002_9780133845969_ch02.indd 37
6/24/14 4:28 PM
38
packets by softclient applications, the packets are overridden by default OS-provided CoS
markings. The issue becomes even more obscure when a PC is connected to a switch via
the PC port on a Cisco Unified IP Phone. In such cases, the IP Phone by default re-marks
all CoS values received from the PC to 0, thereby disregarding any markings by Cisco
softclients.
For Cisco softclients, QoS classification and marking can be provided by a Trusted Relay
Point (TRP). A TRP is a software function that uses a Media Termination Point (MTP)
provider and is dynamically inserted in a call flow by CUCM. Media streams from
softclients can be bridged together, thereby facilitating the QoS markings and classification to be applied for PC-to-PC softphone calls. For more information on TRP, refer to
Chapter 4, Cisco Unified Communications Manager.
Streaming video should be marked to DSCP CS4 (for both unicast and multicast
streams).
Guaranteed bandwidth requirements depend on the encoding format and rate of the
video stream.
Queuing
Beginning with classification and marking, a packet needs to be treated as per the QoS
policy. QoS tools such as policing or queuing can make forwarding or dropping decisions based on these markings. Queuing is a congestion management tool. It ensures that,
during temporary periods of congestion, traffic (packets) is buffered, prioritized, and, if
required, reordered before being transmitted to the destination.
Queuing 39
Queuing Toolset
Queuing Tool
Description
A legacy queuing method with four queues, where higherpriority queues must be emptied before forwarding traffic from
lower-priority queues.
IP RTP Priority
Low-Latency Queuing (LLQ) The queuing method created specifically for voice and video
traffic. LLQ allows traffic to be categorized in up to 64 different classes, with different amounts of bandwidth or priority
treatment for these classes.
Class-Based Weighted Fair
Queuing (CBWFQ)
Cisco recommends CBWFQ or LLQ methodologies for queuing with current versions of
Cisco IOS in Cisco Collaboration networks. Example 2-1 illustrates the MQC approach
to LLQ.
Example 2-1 MQC Approach to LLQ
UCRouter(config)# class-map RTP-Audio
UCRouter(config-cmap)# match protocol rtp audio
!
UCRouter(config)# class-map RTP-Video
UCRouter(config-cmap)# match protocol rtp video
!
UCRouter(config)# class-map match-any Signaling
40
In Example 2-1, NBAR is used to recognize RTP audio and video traffic and DSCP markings (default markings by Cisco UC applications and the majority of endpoints) for signaling that is matched. Voice audio is given priority treatment of guaranteed 20 percent
of the links bandwidth, whereas video traffic is given 10 percent of priority guaranteed
bandwidth. Signaling traffic is given up to 128 kbps of bandwidth, and the remaining traffic is treated by class default via the fair queuing method (that is, this traffic is entertained
only when the priority queues have first been serviced up to their assigned bandwidth).
41
Single-rate two-color policer: A single token bucket is used and traffic either conforms to or exceeds the configured rate. Actions can be stated for traffic that conforms or exceeds the specified rate.
Single-rate three-color policer: Two token buckets are used, with tokens periodically
added to the first bucket and any overflowing tokens going to the second bucket.
Actions can be stated for traffic that conforms, exceeds, or violates the specified
rate.
42
Example 2-2 illustrates a single-rate three-color policer using the MQC where the traffic
conforming to the policy is marked DSCP AF21. The traffic exceeding the policy-defined
rate is marked DSCP AF11, and the traffic violating the exceed action is dropped.
Example 2-2 Traffic Policer Configuration
UCRouter(config)# class-map HTTP-Secure
UCRouter(config-cmap)# match protocol secure-http
!
UCRouter(config)# policy-map HTTPS
UCRouter(config-pmap)# class HTTP-Secure
UCRouter(config-pmap-c)# police cir 512000 bc 64000 be 64000 conformaction set-dscp-transmit af21 exceed-action set-dscp-transmit af11
violate-action drop
!
UCRouter(config)# interface FastEthernet 0/0
UCRouter(config-if)# service-policy output HTTPS
There is a mismatch between link speeds at a central site and remote sites (that is, the
central site link speed is greater than that of the remote sites).
The aggregate link speed at remote sites is greater than that at the central site.
Traffic shaping can also leverage the MQC framework, and when configuring MQCbased shaping, traffic can be shaped to either average or peak. If shape average is specified, traffic is sent at the CIR, with bursting of Be bits per timing interval enabled. If
shape peak is specified, traffic is forwarded at the peak rate.
Example 2-3 shows the configuration of class-based Frame Relay traffic shaping for
HTTPS traffic at least 256 kbps but no more than 512 kbps.
Example 2-3 Frame Relay Traffic Shaping
UCRouter(config)# class-map HTTP-Secure
UCRouter(config-cmap)# match protocol secure-http
!
UCRouter(config)# policy-map HTTPS
UCRouter(config-pmap)# class HTTP-Secure
UCRouter(config-pmap-c)# shape average 512000
UCRouter(config-pmap-c)# bandwidth 256
!
UCRouter(config)# map-class frame-relay FRFMAP
UCRouter(config-map-class)# service-policy output HTTPS
UCRouter(config-map-class)# frame-relay fragment 640
!
43
Compressed RTP
Real-time Transport Protocol (voice media) is encapsulated inside UDP datagrams, which
are further encapsulated in IP packets. The IP, UDP, and RTP headers on voice packets
total approximately 40 bytes. RTP Header Compression (cRTP) compresses IP/UDP/
RTP headers of packets, reducing the header size to approximately 2 to 4 bytes, thereby
saving bandwidth on WAN links. Cisco recommends enabling cRTP on low-speed WAN
links that have a speed of less than or equal to 768 Kbps.
To enable cRTP for Point-to-Point Protocol (PPP) or High-Level Data Link Control
(HDLC) on an interface, use the ip rtp header-compression command. For a Frame Relay
circuit, use the command frame-relay ip rtp header-compression to enable cRTP on an
interface. An optional passive keyword can be input along with the preceding commands.
When its specified, the PPP, HDLC, or Frame Relay interfaces send compressed headers
only if they receive compressed headers. cRTP can be configured via the MQC and by
using the command compression header ip rtp.
44
disseminating larger data packets into smaller fragments and thereby allows interleaving
smaller voice packets as the packets are queued for transmission on a WAN interface. LFI
can be provisioned for MLP and FRF.12.
Multilink PPP
MLP can be run for several physical links or a single link. Because MLP configuration
is performed under a virtual multilink interface, one or more physical interfaces can be
assigned to a multilink group. The virtual multilink interface has an IP address assigned
to it. Moreover, MLP fragments traffic by default, which is advantageous pertinent to
QoS configuration. Cisco recommends using MLP on links with bandwidth less than or
equal to 768 Kbps. Example 2-4 shows configuration for MLP LFI.
Example 2-4 MLP LFI Configuration
UCRouter(config)# interface multilink 1
UCRouter(config-if)# ip address 10.10.1.250 255.255.255.0
UCRouter(config-if)# ppp multilink
UCRouter(config-if)# ppp multilink interleave
UCRouter(config-if)# ppp fragment delay 10
UCRouter(config-if)# ppp multilink group 1
!
UCRouter(config)# interface serial 0/0
UCRouter(config-if)# no ip address
UCRouter(config-if)# encapsulation ppp
UCRouter(config-if)# ppp multilink
UCRouter(config-if)# ppp multilink group 1
45
The fragment value can be derived from the following formula, keeping in mind that
Cisco recommends maximum jitter of no more than 10 ms:
Fragment Size (bytes) = PVC Speed / 800
In this case, the speed is 64 Kbps, which works out to 64000 / 800 = 80 bytes for fragment size.
Cisco recommends the following for Voice over Frame Relay (VoFR):
Enable FRF.12 (fragment size for 10 ms) for circuits less than or equal to 768 Kbps.
An option to VAD is available for multicast-enabled dial peers: vad aggressive reduces
the noise threshold from 78 to 62 dBm. However, VAD has a small issue associated
with it. Because of the complete silence during quiet periods, the call seems to be disconnected for the parties participating in the call. Comfort noise generation (CNG) eliminates this situation by providing white noise. CNG is generated local to a site by the voice
router and can be configured via the comfort-noise command in voice-port configuration
mode, as shown here:
UCRouter(config)# voice-port 0/3/0:23
UCRouter(config-voiceport)# comfort-noise
46
Untrusted endpoints: Devices from which QoS marking cannot be trusted when traversing to the switch port, such as workstations, PCs, and servers.
Trusted endpoints: Devices that can be trusted from a Cisco Collaboration network
point of view, such as Cisco Unified Wireless IP Phones, Cisco IOS gateways, wireless access points, and that mark traffic (media and signaling) and can also re-mark
traffic that has been marked by any connected untrusted devices.
Conditionally trusted endpoints: Cisco Unified IP Phones are categorized as conditionally trusted endpoints because they have untrusted endpoints, such as PCs or
laptops connected via a PC port. Because the switch must extend its trust boundary
to a Cisco Unified IP Phone (based on Cisco Discovery Protocol exchange), the IP
Phone transits from a potentially untrusted device to a trusted device, and hence is
conditionally trusted.
Because Cisco Unified IP Phones can exchange CDP messages with the Cisco switch, the
switch can extend trust to the IP Phones and trust traffic received from the IP Phones.
The Cisco IP Phones can re-mark any traffic received from a connected PC on the PC
port to CoS 0. This process is illustrated in the following steps:
Step 1.
Step 2.
Step 3.
The IP Phone sets CoS to 5 for media traffic and to 3 for signaling traffic.
Additionally, the IP Phone sets CoS to 0 for traffic from the PC port.
Step 4.
The switch trusts CoS values from the IP Phone and maps CoS to DSCP for
output queuing. The result is CoS 5 = DSCP EF and CoS 3 = DSCP AF31/CS3.
Table 2-4
47
Description
The switch trusts the CoS value of all frames entering an interface.
Network Service/
Application
PHB/DSCP
EF (DSCP 46)
48
Network Service/
Application
PHB/DSCP
Queuing on the WLAN occurs in two directions, upstream and downstream. For
upstream queuing, devices that support Wi-Fi Multimedia (WMM) can take advantage
of queuing mechanisms that include PQ. For downstream traffic, Cisco Wireless Access
Points (WAP) can provide up to eight queues.
Lightweight APs (LAP) and autonomous APs both offer queuing; however, LAPs have
a built-in platinum-class queuing for voice traffic, whereas for autonomous WAPs, QoS
policies for voice and video have to be created manually. To implement QoS on a WLAN
AP, it is important to apply appropriate settings for WLAN (SSID) for voice to specify
how the Wireless LAN Controller (WLC) and LAP treat the DSCP values and CAC. This
can be done by browsing to the QoS tab on LAPs WLAN GUI > Edit. For autonomous
WAPs, CAC can be enabled from the CLI by entering the dot11 ssid voice command
followed by the admit-traffic command. Beyond the wireless realm, the QoS for wired
infrastructure helps ensure that voice and video signaling and media traffic go from
source to destination within the expected time and with minimal packet loss and jitter.
Medianet
49
corresponding L2 CoS values that can be interpreted by FIs. This traffic can then be prioritized or de-prioritized based on the L2 CoS value inside the UCS FI. Hence, sending
all UC application traffic to Nexus 1000V ensures that the DSCP markings are mapped
to relevant CoS values, or vice versa, and the traffic reaches the intended destination
that is, the endpoint with proper QoS markings.
Example 2-6 describes the configuration of Nexus 1000V to map L3 DSCP values to L2
CoS values. In this instance, L3 DSCP EF (media) is mapped to CoS 5 and DSCP CS3/AF31
(signaling) is mapped to CoS 3. Finally, the service policy is applied to the port profile.
Example 2-6
UC on UCS applications, when deployed on B-Series servers, store data on one or more
hard drives (SAN storage) that are remote and accessed via FC SAN. Hence, there is a
potential for FC SAN traffic to compete for bandwidth with the Ethernet traffic in the
UCS FI switch. This congestion or oversubscription scenario is very unlikely because the
UCS FI switch provides a high-capacity switching fabric with the usable bandwidth per
server blade far exceeding the possible maximum traffic requirements of a typical UC
application/co-resident configuration.
Medianet
With a host of Cisco Collaboration applications and endpoints at their disposal,
organizations prefer video conferencing to facilitate business communication and
50
Medianet
Mediatrace
Performance Monitor
Flow Metadata/
Meta Databases
Figure 2-4
Medianet Architecture
Mediatrace
Performance Monitor
Cisco TelePresence
Medianet
EX Series endpoints
51
The various Medianet architecture components are listed and described in Table 2-6.
Table 2-6
Medianet Component
Description
Mediatrace
IP Service Level
Agreement Video
Operation (IP SLA VO)
Performance Monitor
A Cisco tool that discovers and validates RTP traffic on a hopby-hop basis. It is used to determine jitter, packet loss, and multiplexed media streams. Performance Monitor also recognizes TCP
flows and IP constant bit rate (CBR) traffic. For TCP, Performance
Monitor reports on round-trip time (RTT) and packet loss, whereas for IP CBR traffic, Performance Monitor reports packet loss
and media rate variation (MRV). It also helps isolate faults in the
network quickly because of its ability to discover and report on a
per-hop basis.
52
Medianet Component
Description
Flow Metadata/Meta
Databases
Medianet
Table 2-7
53
Network Service/Application
VoIP Telephony
EF
PQ
Broadcast Video
CS5
Optional PQ
Real-Time Interactive
CS4
Optional PQ
Multimedia Conferencing
AF4
Bandwidth Queue +
WRED
Multimedia Streaming
AF3
Bandwidth Queue +
WRED
Network Control
CS6
Bandwidth Queue
Voice/Video Signaling
CS3
Bandwidth Queue
CS2
Bandwidth Queue
Transactional Data
AF2
Bulk Data
AF1
Best Effort
DF
Scavenger
CS1
Minimum Bandwidth
Queue
Table 2-8 lists the various service classes defined by Cisco for Medianet and describes
their respective services.
Table 2-8
Class
Service
VoIP Telephony
Broadcast Video
Real-Time Interactive
Multimedia Conferencing
54
Class
Service
Multimedia Streaming
Network Control
Signaling
Operations/Administration/
Management (OAM)
For network operations, administration, and management traffic, such as SSH and SNMP.
Transactional Data
Bulk Data
Best Effort
Scavenger
Chapter 3
Cisco Collaboration networks build on various standards and protocols that enable
organizations and people to harness the power of Voice over IP (VoIP). This chapter
describes telephony protocols and criteria, including
56
Table 3-1
Codec
Description
H.264
Internet Low Bitrate Codec A narrowband, high-complexity speech codec that was developed
(iLBC)
by Global IP Solutions. iLBC has built-in error correction functionality. iLBC is supported by SIP, SCCP, MGCP, and H.323 endpoints. iLBC results in a payload bit rate of 13.33 kbps for 30-ms
frames and 15.20 kbps for 20-ms frames.
Internet Speech Audio
Codec (iSAC)
G.722
Wideband codecs
003_9780133845969_ch03.indd 56
6/25/14 8:28 AM
57
Signaling Protocol
RTP/SRTP
IP Phone
Figure 3-1
RTCP/SRTCP
IP Phone
58
59
10Call Transfer
11Call Park
12Call Proceed
13In Use Remotely
14Invalid Number
Figure 3-2 illustrates the SCCP call flow between a CUCM server and SCCP endpoints
registered to it.
The following events occur during the SCCP call flow illustrated in Figure 3-2:
1. IP Phone A goes off-hook and signals this event to CUCM.
2. CUCM sends messages to IP Phone A to play the dial tone, display text, and set its
lamp state to on.
3. IP Phone A starts sending digits dialed by the user, with the first digit dialed and
sent to CUCM leading CUCM to specify to IP Phone A to stop playing the dial
tone.
4. The user continues dialing the number, and these digits are sent to CUCM. CUCM
performs digit analysis and finds a match for the dialed number that corresponds to
the directory number (DN) of IP Phone B.
5. CUCM indicates to IP Phone B that it should blink its lamp and ring to inform the
user of an incoming call. CUCM also sends information about the calling party (IP
Phone A) to IP Phone B. This information contains calling party name, calling party
number, and so on.
6. CUCM sends an alerting (ringback) message to IP Phone A at the same time as it
rings IP Phone B. CUCM also sends information about the called party (IP Phone B)
to IP Phone A.
7. The user of IP Phone B answers the call and goes off-hook. An off-hook message is
sent to CUCM.
8. CUCM instructs IP Phone B to stop blinking the lamp (set to a steady state) and to
stop the ring tone. At the same time, CUCM also informs IP Phone A to stop the
alerting tone.
9. CUCM requests information such as the to/from IP addresses and the UDP ports
for RTP exchange between IP Phone A and IP Phone B. Both phones respond, and
CUCM informs IP Phone A of IP Phone Bs RTP information and vice versa. CUCM
notifies the IP Phones to open the media channel and start media transmission.
10. RTP traffic flow is set up between the two IP Phones as the users begin their
conversation.
11. The user of IP Phone B decides to end the call, thereby sending an on-hook message
to CUCM.
60
IP Phone A
CUCM
IP Phone B
RTP
RTP
Figure 3-2
Station On Hook
Station Set Lamp (Off)
Station Close Receive Channel
Station Stop Media Transmission
61
12. CUCM notifies the IP Phones to close the media channel and end media
transmission.
13. CUCM informs the IP Phones to set their lamp states to off.
14. IP Phone A sends an on-hook message to CUCM as the user goes on-hook.
Description
CreateConnection
(CRCX)
Command from a call-control agent to an MGCP-controlled gateway for creating a new connection between two MGCP endpoints.
The connection creation is based on parameters such as codec,
allowable bandwidth, gain control, silence suppression, and so on.
ModifyConnection
(MDCX)
DeleteConnection
(DLCX)
EndpointConfiguration
(EPCF)
Configuration command from a call-control agent to an MGCPcontrolled gateway. It configures the gateway with the bearer information, which specifies whether audio calls will be encoded using
mu-law or A-law.
62
Description
NotificationRequest
(RQNT)
Command from a call-control agent to an MGCP-controlled gateway to instruct the gateway to inform the call-control agent when
specific events such as on-hook/off-hook actions or DTMF tones
occur on a specified endpoint.
AuditEndpoint (AUEP)
Command from a call-control agent to an MGCP-controlled gateway to audit the status of an endpoint (port), such as bearer information, signal status, and event status.
AuditConnection
(AUCX)
Command from a call-control agent to an MGCP-controlled gateway to discover the status of a connection, such as connection
mode, call ID, and connection parameters.
Notify (NTFY)
RestartInProgress (RSIP) Command from a gateway to a call-control agent to inform the callcontrol agent that the gateway is taking an endpoint or group of
endpoints out of service or returning an endpoint or group of endpoints to service. There are three types of restart: Restart (endpoint
in service), Graceful (wait until call clearing), and Forced (endpoint
out of service).
MGCP also uses certain return codes that reflect different events occurring on the gateway and, accordingly, enables the gateway to update the call-control agent. Following are
the types of MGCP return codes defined in RFC 3661:
MGCP messages are sent on UDP port 2427, and TCP port 2428 is used to exchange keepalive packets between an MGCP-controlled gateway and CUCM. This allows for MGCP
PRI/BRI backhaul between an MGCP gateway and CUCM wherein the backhaul is used
to transport ISDN Q.931 (D channel signaling) information from the gateway to CUCM.
This allows CUCM to recognize the status of ISDN Layer 3 for the port/endpoint/trunk
being controlled on the MGCP gateway.
Example 3-1 shows the MGCP configuration for a voice gateway.
63
In the previous configuration, the command ccm-manager config server defines the
server that the gateway should contact for downloading the XML config file, and
ccm-manager config enables the download.
003_9780133845969_ch03.indd 63
6/25/14 8:28 AM
64
CUCM
MGCP Gateway B
V
Notification Request (RQNT)
RQNT Response
RQNT Response
RTP
Figure 3-3
DLCX
DLCX
DLCX Response
DLCX Response
MGCP Call Flow Between Two Gateways Registered to Same CUCM Server
65
The following events occur during the MGCP call flow illustrated in Figure 3-3:
1. The call-control agent (CUCM) sends a notification request (RQNT) to each gateway.
The request instructs the gateways to wait for an off-hook transition (event). When
the off-hook transition event occurs, the call-control agent instructs the gateways to
supply a dial tone (signal).
2. The gateways respond to the request (RQNT). The gateways and the call-control
agent wait for a triggering event.
3. An endpoint/user on Gateway A goes off-hook. The gateway provides a dial tone.
4. Gateway A sends a notify (NTFY) to CUCM to advise that a requested event has
occurred, followed by identifying the endpoint and the event (that is, the dialed
digits).
5. CUCM does digit analysis and, after confirming that a call is possible based on the
dialed digits, instructs Gateway A to create a connection (CRCX) with its endpoint
(port/trunk).
6. The gateway responds with a session description if it is able to accommodate the
connection. The session description identifies (at least) an IP address and UDP port
for use in a subsequent RTP session.
7. CUCM sends a connection request to Gateway B. In the request, CUCM provides
the session description obtained from Gateway A. CUCM also sends a notification
request that instructs Gateway B about the signals and events that it should now consider relevant, such as ringing and the endpoints off-hook transition.
8. Gateway B responds to the request with its session description to CUCM.
9. CUCM relays the session description received from Gateway B to Gateway A in a
modify connection request (MDCX). This request might contain an encapsulated
notify request that describes the relevant signals and events at this stage of the call
setup. Gateway A responds to the request.
10. Now that Gateway A and Gateway B have the required session descriptions to establish the RTP session, they open an RTP stream over pre-negotiated (CUCM relayed)
IP addresses and UDP ports.
11. The endpoint/user on Gateway A terminates the call and goes on-hook. CUCM
requested a notification of such an event, so Gateway A notifies CUCM.
12. CUCM sends a delete connection (DLCX) request to each gateway so the session
can be terminated.
13. The gateways delete the connection and respond to CUCM.
66
protocol and can leverage TCP or UDP for transmission. It is a text-based protocol and
has many elements of HTTP. SIP can also operate in its secure form with TLS for signaling, known as Secure SIP (SIPS). SIP uses TCP/UDP port 5060 and SIPS uses TCP port
5061.
Analogous to MGCP, SIP uses SDP for negotiating media type and format such as audio
and video codecs, transport protocol parameters, ports, and so on. SDP operates in an
offer-answer approach such that the session-initiating endpoint (UA) specifies desired
session parameters (such as supported codecs), and the receiving endpoint (UA) replies
with matching session parameters. Each resource in a SIP network is identified by a
Uniform Resource Identifier (URI). A typical SIP URI is in the following format:
sip:username:password@host:port.
SIP sends DTMF digits in-band. However, it can use out-of-band DTMF as well. In a SIP
session, DTMF can be transported as KeyPad Markup Language (KPML), Unsolicited
Notify (UN), or Network Termination Equipment (NTE) (RFC 2833). KPML and UN are
out-of-band DTMF transportation mechanisms, whereas NTE is an in-band mechanism
for DTMF delivery. KPML and NTE are standards based, whereas UN is a non-standard
protocol.
SIP phones can leverage either KPML or SIP dial rules for dialing a number to a destination phone/route pattern. SIP (Type-A) phones leverage SIP dial rules and use a different
method compared to SIP KPML (Type-B) phones.
KPML is similar to SCCP in terms of the process used to collect each digit. The caller
enters digits on the keypad of the phone, and digit analysis occurs in real time, after
which CUCM routes the call to the destination device or translation/route pattern. SIP
KPML uses SIP NOTIFY messages to carry the dialed digits from the phone to CUCM.
As indicated, devices that use KPML are known as Type-B SIP phones. The phones that
support KPML are automatically enabled for KPML. No configuration on CUCM is
necessary for these devices to support KPML. KPML is configured under the SIP Profile
applied to the IP Phone.
SIP dial rules on CUCM can be configured to allow the SIP phone to download a dial
plan file (dialplan.xml) from the CUCM TFTP server when the phone boots. When a caller
enters digits on the phone keypad, the phone analyzes the dialed digits and compares
them with the strings contained within the dialplan.xml file stored locally on the phone.
When there is a match to the dialed number and the timeout is set to 0, the phone sends to
CUCM a SIP INVITE message that contains the entire called number. If the dialed number
does not match any of the strings contained within the diaplan.xml file, the call will only
be routed when the inter-digit timeout expires (or the caller presses # or Dial).
If a dialplan.xml file is downloaded to a phone that supports KPML, KPML is disabled
and the phone behaves in the same way as a Type-A SIP phone. A hybrid of using KPML
and dial rules is not supported, and SIP dial rules/dial plan always take priority over
KPML. The exception to this statement is when CUCME is used and the last statement
within the dial plan contains a dial pattern with a single wildcard character (.) as the last
pattern in the dial plan.
67
A SIP network includes many elements for establishing, terminating, and managing SIP
sessions, as listed and described in Table 3-3.
Table 3-3
Network Element
Description
Manages send and receive SIP messages and manages a session. A SIP
endpoint can act as both a user agent client (UAC) and a user agent
server (UAS).
Initiates and sends requests and gets a response from a SIP UAS or
SIP proxy server. UAC, however, is a logical role and lasts only for the
duration of a SIP transaction.
Provides routing, enforces policies, provides features, and authenticates and authorizes users.
UAS server that provides address translation and that generates 3XX
(Redirection) responses to requests it receives, thereby directing the
client to contact an alternate set of URIs. It allows SIP proxy servers
to redirect invites to external domains as well.
A SIP endpoint that accepts REGISTER requests from SIP UAs and
places the information received in those requests into a location service for the domain it handles. This allows users to register their current locations.
There are two SIP message types: request and response. A request message is sent by a
client to a server and is used to invoke certain methods (functions). A response message is
sent by a server to a client in answer to the request and indicates the status of the request
received.
Table 3-4 lists the methods available for SIP requests.
Table 3-4
Method
Description
INVITE
68
Method
Description
REGISTER
ACK
BYE
CANCEL
OPTIONS
Provisional Response
Acknowledgement
(PRACK)
SIP Responses
SIP Response
Description
Provisional (1XX)
Success (2XX)
Redirection (3XX)
Figure 3-4 depicts a SIP call flow between UAs (Cisco Unified IP Phones) and a UAS/
B2BUA (CUCM).
IP Phone A
CUCM
69
IP Phone B
REGISTER
REGISTER
200 OK
200 OK
INVITE (SDP)
INVITE (SDP)
100 Trying
180 Ringing
200 OK
ACK
RTP
BYE
200 OK
100 Trying
180 Ringing
200 OK
ACK
RTP
BYE
200 OK
Figure 3-4 SIP Call Flow Between Two Endpoints Registered to Same CUCM
The following events occur during the SIP call flow illustrated in Figure 3-4:
1. Cisco Unified IP Phones (SIP UAs) send REGISTER requests to CUCM (SIP UAS).
CUCM sends the response 200 OK after authenticating the UAs.
2. IP Phone A goes off-hook and sends an INVITE to CUCM. In response, CUCM
sends a TRYING 100. At the same time, using the digits dialed by the user, CUCM
reroutes the request to IP Phone B. The INVITE contains SDP information for capabilities negotiation.
3. IP Phone B sends a Ringing 180 response to CUCM when the phone begins to ring.
CUCM sends 180 ringing (alerting) to IP Phone A.
4. The response 200 OK message corresponds to the user at IP Phone B answering the
call, at which time IP Phone A gets 200 OK from CUCM as well.
5. IP Phone A sends an ACK to CUCM, and CUCM sends an ACK to IP Phone B in
reply to 200 OK messages followed by opening the media channel. RTP starts with
the parameters (ports, addresses, codecs, etc.) of the SDP protocol (negotiated during INVITE).
6. The user at IP Phone A decides to terminate the call, and the phone sends BYE to
CUCM. Consecutively CUCM sends BYE to IP Phone B.
003_9780133845969_ch03.indd 69
6/25/14 8:28 AM
70
7. Both phones reply with an OK 200 message to confirm that the final message has
been received correctly.
SIP supports Early Offer (EO) and Delayed Offer (DO) for capability negotiation. In case
of an Early Offer, the SDP message is sent from the calling party to the called party in
the initial INVITE message. The called party responds with the negotiated capability in
the 200 OK to the calling party. In case of Delayed Offer, the called party sends the SDP
message in the 200 OK message to the calling party. The calling party responds with the
negotiated parameter in the ACK message to the called party.
SIP also supports Early Media and Delayed Media for media channel negotiation. In the
case of Early Media, the media between the called and calling party is established before
the session establishment. The called party sends 183 instead of 180 and allows the calling party to establish a bearer channel between the two. With Delayed Media, the media
is established once the SIP session negotiation is complete.
On Cisco IOS, voice gateway SIP configuration/options such as transport type (TCP/
UDP), registrar server configuration, binding all traffic to a certain interface, and so on
can be configured under voice services voip. Example 3-2 shows a configuration of the
SIP voice service where the session transport protocol is set to TCP (default is UDP) and
SIP EO is forced for all SIP sessions.
Example 3-2 SIP Global Parameter Configuration
SIPRouter(config)# voice service voip
SIPRouter(conf-voi-serv)# sip
SIPRouter(conf-serv-sip)# session transport tcp
SIPRouter(conf-serv-sip)# bind all source-interface loopback 0
SIPRouter(conf-serv-sip)# early-offer forced
Example 3-3 illustrates the SIP UA configuration for defining a remote registrar server (a
local registrar server can be defined in voice service voip).
Example 3-3 SIP UA Configuration
SIPRouter(config)# sip-ua
SIPRouter(config-sip-ua)# registrar ipv4: 10.76.108.146 tcp
SIPRouter(config-sip-ua)# registrar ipv4: 10.76.108.147 tcp secondary
SIPRouter(config-sip-ua)# authentication username registrar password C1sc0123
Consecutively at least one VoIP dial peer is required on the gateway so it can send calls
to and receive calls from CUCM. Example 3-4 illustrates the configuration of a SIP dial
peer.
71
To configure a SIP gateway for communication with CUCM, a SIP trunk is required.
Unlike an MGCP gateway, a SIP gateway does not register with a call-control agent. The
following steps show how to add a SIP trunk in CUCM:
Step 1.
Step 2.
Step 3.
Step 4.
Step 5.
Enter the Trunk Name, description, CUCM Device Pool, and other parameters.
Step 6.
In the SIP Information section, you can add either an IP address for the SIP
router or a DNS Service (SRV) record. After entering the other mandatory
parameters, click Save.
v = Protocol version
s = Session name
72
Media description:
Time description:
For an example of SDP format, see the next section. SIP SDP messages are specifically
useful in certain events such as early media exchange (183 with SDP), ENAT for SIP
trunks, mid-call parameter changes, and so on.
Floor chair: A logical entity that manages one floor and can grant, deny, or revoke a
floor
Floor participant: A logical entity that requests floors from a floor control server
73
Floor control server: A logical entity that maintains the state of the floor(s)which
floors exists, who the floor chairs are, who holds a floor, and so on
BFCP is designed to rely on the capabilities of the underlying signaling and transport
protocols to set up each stream that is being managed, whether it is voice, video, or media
content that is being transported in the RTP stream. BFCP supports use of Transport
Layer Security (TLS) to provide encryption of floor information concerning each
resource that is being controlled and the participants using and viewing each resource.
TLS also provides the capability to support anonymous users for sessions where anonymity is desired.
SIP BFCP is an application-sharing mechanism that leverages the BFCP protocol. For
instance, a user participating in a Cisco WebExenabled TelePresence conference call
can share content from his or her desktop. SIP BFCP works with Cisco TelePresence, EX
Series endpoints, and Cisco Jabber with video desktop sharing. Example 3-5 shows SDP
output from a video conference where one of the participants is sharing PowerPoint slides
during the call.
Example 3-5 SDP Output from BFCP-Enabled Call
v=0
o=Sam
s=meeting
c=IN 10.10.200.100
t=0 0
m=video 49680 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides
m=video 49680 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:main
In Example 3-5, slides is the presentation stream and main is the main video stream.
The streams are controlled by both SIP and BFCP, where BFCP is used for asking permission to send the second stream, and the SIP offer-answer model (i.e., sending SDP
messages over INVITE or UPDATE) is used for opening the stream. If a participant wishes to start sharing a slide with other participants, the sharing participant begins by asking
for permission by sending a BFCP floor request and then opens the stream by sending a
Re-INVITE with a new SDP message adding the second m=video line.
74
H.225: H.225 (also known as H.255.0) is a call-control and signaling protocol used
to establish, control, and terminate calls between H.323 endpoints.
H.225 RAS (Registration, Admission, and Status): RAS is used for communication between H.323 endpoints (such as Cisco Unified IP Phones, CUCM) and the
gatekeeper and between the gatekeeper and a peer gatekeeper. RAS has a number of
messages for registration, admission, and status, most of which have a response of
Confirmation or Reject.
H.235: H.235 provides security within the H.323 suite, for both signaling and
media.
H.239: H.239 is a standard for multiple video channels within a single H.323 session.
H.239 enables dual streams for use in videoconferencing, one for live video and the
other for presentation/still images.
H.450: The H.450 series of protocols describes various supplementary services such
as call transfer, call hold, and so on.
H.460: The H.460 series of protocols defines optional extensions that may be implemented by an endpoint or a gatekeeper Network Address Translation (NAT)/firewall
(FW) traversal.
H.323 endpoints use H.225 RAS UDP port 1718 for gatekeeper discovery and UDP port
1719 for gatekeeper H.225 RAS communication. H.323 endpoints can also use multicast
for gatekeeper discovery (the multicast IPv4 address is 224.0.1.41). H.323 voice gateways
can send DTMF digits in a number of ways, such as H.245 alphanumeric, RTP-NTE,
Cisco-proprietary, or H.245 signaling. In H.245 alphanumeric signaling, alphanumeric
digit tones are sent out-of-band via H.245, but H.245 alphanumeric signaling does not
include tone duration. H.245 signaling is like H.245 alphanumeric signaling but with
tone duration. Both RTP-NTE and Cisco-proprietary methods send DTMF tones within
an RTP stream. Its important to note that H.323 call signaling is based on the ITU-T
Recommendation Q.931 protocol.
An H.323 ecosystem has many elements to it:
H.323 gateways: Fundamental units of an H.323 ecosystem that enable the IP and
POTS worlds to come together. H.323 gateways can connect to call-control agents,
gatekeepers, session border controllers, and so on.
Session border controller (SBC): Known as Cisco Unified Border Element (CUBE)
in Cisco terminology, an SBC can process H.323 messages and can help interconnect
multiple organizations leveraging the H.323 suite for voice and video calls, either
directly or via an IT service provider (ITSP).
75
H.323 Gateway
An H.323 gateway is a device that can interface with the public switched telephone network (PSTN), IP networks, call-control agents, H.323 gatekeepers, H.323 endpoints, and
so on. To configure an H.323 gateway to communicate with a call-control agent such as
CUCM, the gateway can be configured as shown in Example 3-6.
Example 3-6 H.323 Gateway Configuration
H323Router(config)# voice service voip
H323Router(conf-voi-serv)# h323
H323Router(conf-voi-h323)# ccm-compatible
!
H323Router(config)# interface loopback 0
H323Router(config-if)# ip address 10.10.1.250 255.255.255.0
H323Router(config-if)# h323-gateway voip interface
H323Router(config-if)# h323-gateway voip h323-id H323Router
H323Router(config-if)# h323-gateway voip bind srcaddr 10.10.1.250
!
H323router(config)# dial-peer voice 1001 voip
H323router(config-dial-peer)# destination-pattern 1...
H323router(config-dial-peer)# session target ipv4:10.76.108.146
H323router(config-dial-peer)# dtmf-relay h245-alphanumeric
H323router(config-dial-peer)# codec g711ulaw
H323router(config-dial-peer)# no vad
In Example 3-6, under the voice service voip command, the subcommand h323 enters
the H.323 submode. The command ccm-compatible enables CUCM-compatible signaling. The interface-specific command h323-gateway voip h323-id is used to identify the
ID of the gateway. The command h323-gateway voip bind srcaddr is employed to configure the IP address used as a source IP address for messages sent to CUCM server(s).
Consecutively, an H.323 gateway must be defined in CUCM so that CUCM servers can
communicate with the same. To add an H.323 gateway in CUCM, follow these steps:
76
Step 1.
Step 2.
Step 3.
Step 4.
Enter the Device Name (IP address or DNS name of the gateway), description, CUCM Device Pool, and other parameters.
Step 5.
H.323 gateways initiate an H.323 session in two ways: fast start and slow start. Fast-start
(also known as fast connect) is a newer method (available in H.323 version 2) of call setup
that allows the media channels to be operational before the CONNECT message is sent.
Essentially, H.245 is still negotiated later. However, the actual media channels can be
established by tunneling H.245 within H.225 messages. The following snippet states the
fast-start configuration:
H323Router(config)# voice service voip
H323Router(conf-voi-serv)# h323
H323Router(conf-serv-h323)# call start fast
Compared to fast start, slow-start implementations require that the media channels wait
until after the CONNECT message to negotiate IP addresses, ports, and codecs. In slow
start, many H.245 messages are exchanged over a separate TCP connection.
An H.323 gateway can also interface with a gatekeeper using RAS. For configuration of
an H.323 gateway, the following configuration is required under the interface, with the
remaining configuration being the same as in the earlier configuration:
H323Router(config)# interface loopback 0
H323Router(config-if)# h323-gateway voip id CUCMGK ipaddr 10.10.1.180
The command h323-gateway voip id identifies the ID and IP address of the gatekeeper
with which the gateway should register. The configuration of a gatekeeper to support an
H.323 gateway is covered in the next section.
H.323 Gatekeeper
H.323 gatekeepers are devices that can provide functions such as the following:
77
GKRouter(config)# gatekeeper
GKRouter(config-gk)# zone local CUCMGK corp.local 10.10.1.180
GKRouter(config-gk)# zone prefix CUCMGK 1*
GKRouter(config-gk)# gw-type-prefix 1#* default-technology
GKRouter(config-gk)# bandwidth session zone CUCMGK 256
GKRouter(config-gk)# bandwidth total zone CUCMGK 2048
GKRouter(config-gk)# no shutdown
The zone local CUCMGK corp.local 10.10.1.180 command defines the local zone controlled by the gatekeeper, domain name, and the IP address (for RAS) for one of the
interfaces on the gatekeeper router. A gatekeeper can also work with another gatekeeper,
in which case the remote zone command is used. The zone prefix CUCMGK 1* command is employed to specify the gatekeepers name and add a prefix to the local zone
list. In this case, all prefixes beginning with digit 1 are associated with the gatekeeper
CUCMGK. The gw-type-prefix 1#*default-technology command specifies a default
technology prefix 1#*, which is used to route calls if the called number does not correspond with a registered E.164 address. Next, the bandwidth commands are employed
to specify the per-session maximum bandwidth (256 Kbps) and total bandwidth (2048
Kbps) assigned to the zone CUCMGK. The no shutdown command activates the gatekeeper function on the Cisco IOS router.
003_9780133845969_ch03.indd 77
6/25/14 8:28 AM
78
Table 3-6
Description
Setup
Setup Acknowledge
Call Proceeding
Connect
Sent by the destination endpoint to the calling endpoint to indicate that the call has been accepted/answered.
Alerting
Information
Release Complete
Progress
Status
Status Inquiry
Notify
Description
Sent from an endpoint/gateway for gatekeeper discovery. A GRQ message can be a unicast or multicast
message.
Acceptance message from the gatekeeper to an endpoint/gateway so that the endpoint/gateway can work
with a gatekeeper.
Description
Sent by a gatekeeper to an endpoint/gateway to confirm it can now register itself to the gatekeeper, after
which it can make or receive calls.
Message commonly used between interzone gatekeepers to obtain the IP of a different zones endpoint.
Sent by the gatekeeper if the remote endpoint is available and starts bandwidth monitoring at this time.
Sent by the gatekeeper in response to a DRQ confirming it has disengaged the call and released the associated bandwidth.
79
80
Description
Informs the requester that the request is being processed; is particularly useful to avoid multiple instances
of the same request.
Resource Availability Indicator (RAI) Used by gateways to inform the gatekeeper whether
resources are available in the gateway to take on additional calls.
Resource Availability Confirmation
(RAC)
Figure 3-5 depicts the H.323 RAS call setup between two H.323 gateways and a
gatekeeper.
The following events occur during the H.323 RAS call flow as illustrated in Figure 3-5:
1. H.323 Gateways A and B send a GRQ message to the H.323 gatekeeper to see if any
gatekeepers are available for registration.
2. The H.323 gatekeeper returns a GCF message indicating that the responding gatekeeper is able to register new endpoints/gateways.
3. Both gateways send an RRQ message to the H.323 gatekeeper in an attempt to register as part of that gatekeepers zone.
4. The H.323 gatekeeper returns an RCF indicating that the gatekeeper will add
Gateways A and B to its zone.
5. Gateway A sends a local ARQ message to the H.323 gatekeeper seeking authorization to place a call over the H.323 network.
6. The gatekeeper returns an ACF indicating that the gatekeeper is going to allow
Gateway A access to the network.
H.323 Gateway A
Gatekeeper
81
H.323 Gateway B
V
GRQ
GRQ
GCF
GCF
RRQ
RRQ
RCF
RCF
H.225 ARQ
H.225 ACF
Call Setup
Call Processing
H.225 ARQ
H.225 ACF
Alerting
Connect
H.245 Terminal Capabilities
H.245 Terminal Capabilities
H.245 Master-Slave Determination
H.245 Open Audio Logical Channel
H.245 Open Audio Logical Channel ACK
H.245 Open Audio Logical Channel
H.245 Open Audio Logical Channel ACK
RTP
RTP
End Session
End Session
Release Complete
Figure 3-5
DRQ
DRQ
DCF
DCF
82
7. Call setup initiates from Gateway A. Remote Gateway B acknowledges call setup
initiation.
8. Remote Gateway B contacts the common H.323 gatekeeper, seeking authorization to
complete the two-way H.323 network call.
9. The gatekeeper returns ACF, indicating that it is going to allow Gateway B access to
the network.
10. Various endpoint transmission and reception capabilities defining operation of voice,
video, and data are exchanged and acknowledged to ensure consistent, reliable twoway communication between endpoints.
11. Gateways A and B determine master and slave assignments between themselves.
12. Before actual transmission or reception of voice or video, Gateway A opens a logical channel for RTP transmission, ensuring clear two-way communication. Remote
Gateway B acknowledges the notification.
13. Gateway B also opens a logical channel for RTP transmission, ensuring two-way
communication. Gateway A acknowledges the notification.
14. Two-way communication ensues between endpoints over the H.323 network. At this
time RTP and RTCP streams are established between Gateways A and B (or between
the endpoints leveraging Gateways A and B for H.323 session).
15. A user at Gateway A goes on-hook and the gateway sends an End Session message
to remote Gateway B. Gateway B replies with an End Session message as well.
16. Both gateways inform the gatekeeper that the call has ended and request disengagement via DRQ.
17. The gatekeeper sends a response as DCF, meaning the gateways are released from the
session and the bandwidth used for the conversation is returned to the gatekeepers
bandwidth pool.
Analog Telephony
83
Analog Telephony
When you speak into a microphone (MIC) of a phone, your voice generates sound waves
and traditional telephone converts the sound waves into electrical signals in analog form.
In an IP world, interoperability with analog devices is important. Cisco analog/digital
voice gateways and Cisco Analog Telephone Adaptor (ATA) help connect to the PSTN
and analog devices using a variety of interfaces and signaling types. The most common
analog interfaces are the following:
FXO Disconnect
As discussed earlier, loop-start signaling can introduce issues such as glare with FXO to
CO switch signaling. Because the CO switch always provides 48 V, there is no disconnect supervision from the switch side, thus a CO switch expects a phone (in this case,
FXO port) to hang up when the call is terminated on either side. However, the FXO port
expects the CO switch to tell it when to hang up, and this is where the disconnect issue
84
between the calling side and called side can occur. The most common symptom of this
problem is either that phones continue to ring when the caller has cleared the call or that
FXO ports remain busy after the previous call is supposed to be cleared.
This issue can be rectified by using the FXO Answer and Disconnect Supervision feature
that enables analog FXO ports to monitor call-progress tones and voice and fax transmissions returned from a PBX or from the PSTN. Answer Supervision can be accomplished
by detecting battery reversal or by detecting voice, fax, or modem tones.
E&M
E&M is a supervisory line signaling that uses DC signals on separate leads, called the
E lead and the M lead. E&M can be interpreted as Ear and Mouth or Earth and
Magneto. The E&M standard defines two sides to the interface (8-line, using RJ-48 connector): Trunk Circuit and Signaling Unit. The Signaling Unit and Trunk Circuit communicate their status over the E and M leads, using a combination of Signal Battery (SB) and
Signal Ground (SG), where the battery used is standard 48 V. E&M trunks are frequently used for tie-line (private analog circuit) connectivity for PBXs. There are five variants
of E&M types I, II, III, IV, and V. Their main features are described in Table 3-8.
Table 3-8
E&M Variants
E&M Type
Description
E&M type I
Uses E and M leads for signaling, but it doesnt offer ground isolation
and cannot be used in a back-to-back configuration. This variant is common in North America.
E&M type II
Uses E, M, SB, and SG leads for signaling, offers ground isolation, and
can be used in a back-to-back configuration.
Uses E, M, SB, and SG leads for signaling and offers ground isolation,
but cannot be used in a back-to-back configuration.
Digital Telephony
E&M Type
Description
E&M type IV
Uses E, M, SB, and SG leads for signaling, offers ground isolation, and
can be used in a back-to-back configuration. This E&M variant type is
not supported on Cisco devices.
E&M type V
Uses E and M leads for signaling and can be used in a back-to-back configuration, but doesnt offer ground isolation. This E&M variant is common outside North America.
85
Wink Start: As the call initiator goes off-hook, the other end transmits a short (140
290 ms) off-hook signal and returns to on-hook. The initiator detects the wink and
then sends the dialed digits. At this time, the other end goes permanently off-hook
(seized) as the call is answered.
Delay Start: As the initiator goes off-hook, it waits for a predefined delay and then
checks for on-hook from the other end before sending the digits.
Immediate Start: Similar to Delay Start but the initiator doesnt wait for the on-hook
at the receiver side. The initiator goes off-hook and waits for 150 ms and then sends
the dialed digits.
Digital Telephony
Similar to analog telephony, digital telephony also transmits human voice from one point
to another. However, the major distinction is that digital telephony leverages digitization
of signaling and audio transmissions. This is accomplished by transforming analog signals
into digital signals by use of digital electronics. Digitization of voice has many benefits,
including quality improvement, more channels to transmit voice, and overall lower cost of
operation (compared to individual FXO trunks). Digital interfaces/circuits come in many
flavors, such as T1, E1, Basic Rate Interface (BRI), Primary Rate Interface (PRI), and so on.
ISDN Q.911 is a physical layer protocol, equivalent to the physical layer of the Open
Systems Interconnection (OSI) model.
At Layer 2, ISDN signaling is provided by the Link Access Procedure on the D (signaling) channel (LAPD), as specified in ITU-T Q.921. The LAPD protocol is similar
to High-Level Data Link Control (HDLC) and is the Layer 2 ISDN signaling protocol.
86
Terminal Endpoint Identifier (TEI) identifies end devices and can either be statically
configured at the end device or dynamically allocated by the PSTN.
Basic Rate Interface (BRI): Provides two 64-Kbps bearer channels and a 16-Kbps
signaling channel, also known as 2B+D. A BRI interface has an aggregate bit rate of
144 kbps.
Primary Rate Interface (PRI): Provides 23 (T1) or 30 (E1) channels each with
64-Kbps bearer channels and a single 64-Kbps signaling channel, also known as
23B+D or 30B+D. A T1 has an aggregate bit rate of 1.544 Mbps, whereas an E1 has a
bit rate of 2.048 Mbps
Digital Telephony
87
Q Signaling Protocol
QSIG is an ISDN-based signaling protocol, based on Q.931 signaling. It is primarily used
for feature transparency between different vendor PBXs. QSIG has two layers of signaling
procedures:
Basic call: Defines the signaling procedures and protocol for the purpose of circuitswitched call control at the Q reference point between Private Integrated Services
Network Exchanges (PINX) and is explained in Standard ECMA-143.
Generic function: Defines the signaling protocol for the control of supplementary
services and additional network features and is explained in Standard ECMA-165.
Path replacement
T1 CAS
T1 CAS uses in-band robbed-bit signaling. Signaling for a particular traffic circuit is permanently associated with that circuit. Signaling is based on analog signaling: loop-start,
88
ground-start, and E&M variants. E&M supports feature groups such as feature groups D
and FGD. Example 3-11 describes the configuration of a T1 CAS circuit.
Example 3-11 T1 CAS Configuration
CASRouter(config)# controller T1 0/0/0
CASRouter(config-controller)# framing esf
CASRouter(config-controller)# linecode b8zs
CASRouter(config-controller)# ds0-group 0 timeslots 1-12 type e&m-fgd
CASRouter(config-controller)# ds0-group 1 timeslots 13-24 type fgd-eana
!
CASRouter(config)# dial-peer voice 90 pots
CASRouter(config-dialpeer)# destination-pattern 9T
CASRouter(config-dialpeer)# direct-inward-dial
CASRouter(config-dialpeer)# port 0/0/0:1
E1 R2
E1 R2 is an equivalent of T1 CAS for E1 systems. E1 R2 signaling specifications are
defined in ITU-T Recommendations Q.400 to Q.490. E1 R2 supports inbound and
outbound Digital Number Identification Service (DNIS) and Automatic Number
Identification (ANI). The channel in timeslot 0 is used for framing, syncing, and alarms.
The channel in timeslot 16 is reserved for signaling. However, there is no LAPD. Example
3-12 describes the configuration of an E1 R2 circuit.
Example 3-12 E1 R2 Configuration
CASRouter(config)# controller E1 0/0/0
CASRouter(config-controller)# framing no-crc4
CASRouter(config-controller)# linecode ami
CASRouter(config-controller)# ds0-group 0 timeslots 1-31 type r2-digital
r2-compelled ani
!
CASRouter(config)# dial-peer voice 99 pots
CASRouter(config-dialpeer)# destination-pattern 9T
CASRouter(config-dialpeer)# direct-inward-dial
CASRouter(config-dialpeer)# port 0/0/0:0
003_9780133845969_ch03.indd 88
6/25/14 8:28 AM
89
trunks. A backup D channel can be configured on a T1 trunk other than the primary
trunk for resiliency. Hence, a sample configuration will be (for four T1 trunks) 94B + D +
D. NFAS is only supported with a channelized T1 controller.
Example 3-13 shows the configuration of NFAS for 2 PRI trunks.
Example 3-13 NFAS Configuration
NFASRouter(config)# controller t1 1
NFASRouter(config-controller)# pri-group timeslots 1-24 nfas_d primary
nfas_interface 1 nfas_group 1
NFASRouter(config-controller)# pri-group timeslots 1-24 nfas_d backup nfas_interface
2 nfas_group 1
!
NFASRouter(config)# dial-peer voice 199 pots
NFASRouter(config-dialpeer)# destination-pattern 9T
NFASRouter(config-dialpeer)# direct-inward-dial
NFASRouter(config-dialpeer)# port 1:D
Caller ID
Caller ID can be sent via FXO and FXS ports so that the called party can receive the calling partys information, such as number and calling name (where supported). With Cisco
voice gateways, Caller ID has certain restrictions with certain protocols. Caller ID works
for FXS ports with all supported protocols such as MGCP, H.323, SIP, and SCCP. Caller
ID, however, does not work on FXO ports with the MGCP protocol because it is not supported with FXO ports when configured for MGCP. To ensure Caller ID works with FXO
ports on Cisco IOS gateways, it is recommended to configure the gateway with H.323,
SCCP, or SIP support (depending on the model of the gateway and module type).
003_9780133845969_ch03.indd 89
6/25/14 8:28 AM
90
Echo
Echo is defined as the sound of your own voice reflected back to you on the telephone
receiver while you are talking. In the POTS world, echo is usually caused by an impedance mismatch when the four-wire network is converted to the two-wire local loop. It can
be controlled by echo suppression or echo cancellation. The latter is more effective and
is used in most traditional and packet-switched networks. In a Cisco Collaboration network, echo cancellation (ECAN) can be achieved by echo cancellers built into low-bitrate
codecs operated on a DSP (DSP firmware). In Cisco IOS voice gateways, echo cancellation is enabled using the echo-cancel enable command, and echo trail (time to wait for
reflected voice) can be configured using the echo-cancel coverage command. Example
3-14 illustrates configuration of a Cisco IOS voice gateway to enable echo cancellation.
Example 3-14 Echo Cancellation Configuration
UCRouter(config)# voice-port 1/0/1
UCRouter(config-voiceport)# echo-cancel enable
UCRouter(config-voiceport)# echo-cancel coverage 16
UCRouter(config-voiceport)# non-linear
In Example 3-14, echo-cancel coverage is set to 16 ms (default value) for echo trail, followed by the non-linear command that enables nonlinear processing in case no near-end
speech is detected.
Place a call over the FXS/FXO/DID voice port for which impedance setting is
to be determined.
Step 2.
91
Execute the Tone Sweep test for this voice port by issuing the command test
voice port <port number> thl-sweep verbose.
Fax pass-through
Fax relay
Store-and-forward
In fax pass-through mode, voice gateways do not distinguish a fax call from a voice call.
Modulated fax information from the PSTN is passed in-band, end to end over a voice
speech path in an IP network. Incoming T.30 fax data is not demodulated or compressed,
and the fax machines (or modems) communicate directly with each other over a transparent IP network so the fax traffic is carried between the two gateways in RTP packets
(tunneled). Fax pass-through supports only G.711 mu-law and a-law and requires Voice
Activity Detection (VAD) to be disabled. It is supported by H.323, MGCP, and SIP protocols. T.30 fax pass-through can be configured globally under voice service voip or per
dial-peer basis using the fax protocol pass-through command. Figure 3-6 depicts fax
pass-through call flow.
Fax (Analog) Data
1100101101
G.711 64 kbps
Encoding
V
Fax Machine A
IP Network
Voice Gateway A
V
Voice Gateway B
Fax Machine B
003_9780133845969_ch03.indd 91
6/25/14 8:28 AM
92
sends the same to the receiving fax machine. Cisco IOS gateways support two types of
fax relay mechanisms: T.38 fax relay and Cisco Fax Relay.
Cisco Fax Relay is a Cisco-proprietary method and is the default fax transmission mechanism on Cisco voice gateways. T.38 fax relay is based on the ITU-T T.38 standard. T.38
is a real-time fax transmission method, which means that having two fax machines communicating with each using T.38 fax relay is like having a direct phone line between them.
Both fax relay mechanisms are supported by the H.323, SCCP, MGCP, and SIP protocols.
T.38 fax relay can be configured globally under voice service voip or per dial-peer basis
using the fax protocol t.38 command. Figure 3-7 illustrates the fax relay call flow.
Fax (Analog) Data DSP Demodulates
1100101101
Fax Data
DSP Modulates
Fax Data
IP Network
Fax Machine A
Voice Gateway A
Voice Gateway B
Figure 3-7
Fax Machine B
Also known as on-ramp and off-ramp faxing, store-and-forward fax is based on the
ITU-T T.37 standard. It converts a traditional G3 fax incoming call from a fax machine
to an email message with a Tagged Image File Format (TIFF) attachment. The fax email
message and TIFF image (attachment) are handled by an email server while traversing
the IP network. This email and attachment can be stored for later delivery or delivered
immediately to a PC (with an email client) or to an off-ramp gateway. An off-ramp gateway handles calls coming from an on-ramp gateway and going out to a fax machine or
PSTN and converts a fax email with a TIFF attachment into a traditional fax format. The
functionality of store-and-forward fax can be facilitated through Simple Mail Transfer
Protocol (SMTP) or Extended SMTP (ESMTP). Figure 3-8 illustrates store-and-forward
fax call flow.
Fax (Analog) Data
1100101101
On-Ramp
Gateway
IP Network
V
Fax Machine A
Voice Gateway A
Figure 3-8
PC
Voice Gateway to PC (Email)
93
Modem pass-through
Modem relay
Modem pass-through over VoIP provides the transport of modem signals through a
packet network by using PCM-encoded packets. It is based on the same logic as fax passthroughthe analog voice stream is encoded into G.711 and passed through the network
tunneled in an RTP stream and decoded back to analog signals at the far end. Modem
pass-through can be configured globally in voice service voip or per dial-peer basis
using the modem passthrough command.
Modem relay supports modem connections across traditional TDM networks. Similar to
fax relay, modem relay demodulates a modem signal at one voice gateway and passes it as
packet data to the receiving voice gateway, where the signal is re-modulated and sent to
the receiving modem. Cisco voice gateways, upon detection of the modem answer tone,
switch into modem pass-through mode. If the Call Menu (CM) signal is detected, the
gateways switch into modem relay mode. Modem relay supports V.34 modulation and
V.42 error correction. Signaling support includes SIP, MGCP, SCCP, and H.323. Modem
relay can be configured globally in voice service voip or per dial-peer basis using the
modem relay command.
003_9780133845969_ch03.indd 93
6/25/14 8:28 AM
Chapter 4
Cisco Unified
Communications Manager
Cisco Unied Communications Manager (CUCM) is an IP PBX that delivers enterpriseclass telephony features and functions. CUCM offers interfaces that include Cisco
Unied IP Phones, voice messaging (Cisco Unity Connection), presence (Cisco Unied
IM Presence), interactive voice response (IVR), voice gateways, and other multimedia
applications.
CUCM is the core of almost every Cisco Collaboration solution.
96
CUCM
Subscriber 1
Signaling with
Primary CUCM
Figure 4-1
CUCM
Subscriber 2
Backup Connection
with Secondary CUCM
Description
Description
Adjunct CSS
Intercompany Media
Services Enrolled Group
Date/Time Group
Region
Location
Network Locale
Connection Monitor
Duration
Physical Location
AAR Group
97
Calling Party Transformation Modifies the number used as the caller ID.
CSS
98
Description
Geolocation Filter
Calling Party Transformation Allows modification of the number used as the caller ID to, for
CSS
example, E.164 format.
Connected Party
Transformation CSS
Redirecting Party
Transformation CSS
Description
User Locale
IP Addressing Mode
Specifies whether IPv4 only, IPv6 only, or a combination can be used for system addressing.
Specifies whether IPv4 only, IPv6 only, or a combination can be used for signaling.
Codec Selection
Description
99
MLPP Preemption
MLPP Domain
Codec Selection
CUCM offers a system default codec preference. However, since CUCM version 9.x, the
administrator has the ability to deterministically specify the order of the default codec
preference. This allows codec selection based on received offer at a global level or a gateway/trunk level. Codec selection/preference can be applied to the following:
SIP
MGCP
SCCP
H.323
EMCC-capable endpoints
100
Figure 4-2
CUCM Features
This section covers the commonly used CUCM features.
Step 2.
Step 3.
Step 4.
CUCM Features
101
More often than not, users prefer to select a number that the call will be parked on. This
feature, known as Directed Call Park, enables the user to transfer a call to the directed
call park number by pressing the Transfer softkey and then entering the directed call park
number. To configure Directed Call Park, follow these steps:
Step 1.
Step 2.
Step 3.
Enter the number/pattern in the Number field. Enter other required details.
Step 4.
In the Reversion Number field, enter an extension that the parked call should
be forwarded to if it is not retrieved.
Step 5.
In the Retrieval Prefix field, enter the prefix that will be dialed by the user followed by the number to retrieve the call. Click Save.
Step 2.
Step 3.
In the Call Pickup Group Number field, enter the number to be used. Enter
the other details.
Step 4.
Choose options from the Call Pickup Group Notification Policy and Call
Pickup Group Notification Timer drop-down lists. Click Save.
Step 5.
Navigate to Device > Phone. Select the phone for which Call Pickup is to be
configured. Choose the line and select the preferred Call Pickup group. Click
Save.
102
Meet-Me Conference
CUCM supports two types of conference calls: ad-hoc conference calls and Meet-Me
conference calls. As the name suggests, an ad hoc conference call can be initiated by
either of two parties already on a voice call. Meet-Me, on the other hand, requires the
initiating party to start a conference call by pressing the Meet-Me softkey, after which
other participants can join by dialing a predetermined Meet-Me number. Each Meet-Me
conference can host up to 16 participants, and each conference call requires a unique
Meet-Me number. Follow these steps to configure Meet-Me patterns in Cisco Unified
CM Administration:
Step 1.
Step 2.
Step 3.
Step 2.
Select the appropriate phones Phone Button Template, click Copy, and
instead of regular Speed Dials, select Speed Dial BLF (for the number of BLF
speed dials required).
Step 3.
Go to Device > Phone and select the phone for which BLF needs to be
enabled. Select the new Phone Button Template and click Save.
Step 4.
CUCM Features
Figure 4-3
103
Queue announcements can be set up by going to Media Resources > Music on Hold
Audio Source, under Announcement Settings.
Call Hunting
Call Hunting is a mechanism wherein a call is placed to a Hunt Pilot and the number
hunts (dials) among the group of lines in a predefined manner. If a line member is available, the call is answered. Otherwise, it hunts to the next line or moves to the next available hunt member in the Hunt Group, or the call can be sent to voice mail. A Hunt Group
consists of various components such as Line Group, Hunt List, and Hunt Pilot. A Line
Group can consist of Line Group members such as SCCP/SIP endpoints, voice-mail ports,
and FXS ports. A Line Group is assigned to a Hunt List that contains an ordered list of
one or more Line Groups. In turn, a Hunt List is assigned to a Hunt Pilot that is the point
where call hunting starts. Hunt Pilot has the DN at which an incoming call can be forwarded, and as a result, the call goes to Hunt List > Line Group > Line Members in that
order.
Line Group members can process an incoming call by using various hunting options
such as Ring No Answer, Busy, and Not Available. Moreover, the Distribution Algorithm
defines how the call hunting takes place, such as Top Down, Circular, Longest Idle Time,
or Broadcast. The Hunt List, as described, contains one or more Line Groups in order
of preference. Hunt Pilot allows assigning a DN to the hunting mechanism and provides
enhanced options like call queuing (discussed earlier).
To add a Line Group, go to Call Routing > Route/Hunt > Line Group. Add the Line
Group members and define the distribution algorithm, hunting conditions, and other
details. To add a Hunt List, navigate to Call Routing > Route/Hunt > Hunt List. Select a
CUCM Group and Line Groups that should be part of the Hunt List.
104
Annunciator
Annunciator is a Cisco IP Voice Media Streaming (IPVMS) application service process
that runs on a CUCM node that has the IPVMS service activated. Annunciator plays
recorded announcements to devices on specific events, such as a user dialing an invalid
number. An annunciator is automatically created when IPVMS service is activated on
one or more nodes in a cluster. No configuration is needed except to change the device
pool to a specific device poolfor example, changing to Datacenter-DP a device pool
that contains all media resources. To change the device pool, go to Media Resources
> Annunciator and select the annunciator for which the device pool is to be changed.
Choose the appropriate device pool and click Save.
Conference Bridge
As discussed in a previous section, CUCM supports two types of conferences, ad-hoc
and Meet-Me. For either conference type, a conference bridge resource is required, either
a hardware conference bridge or a software conference bridge. Similar to Annunciator,
a software conference bridge runs on CUCM and is automatically created when IPVMS
service is activated on a node. Where possible, use of hardware conference bridge(s)
is recommended because software conference bridges have an impact on CUCM CPU
and memory, and only support G.711 calls. Hardware conference bridges can be configured on Cisco IOS gateways leveraging DSPs on Packet Voice Digital Signal Processor
Modules (PVDM). Follow these steps to configure a hardware conference bridge in Cisco
Unified CM Administration:
Step 1.
Step 2.
Step 3.
Select Cisco IOS Enhanced Conference Bridge. Enter the name matching the
associated DSP Profile name in the Cisco IOS router.
Step 4.
Enter other required details. Ensure that the security mode matches what is
configured on the Cisco IOS router. Click Save.
The Cisco IOS configuration for conference bridges is covered in Chapter 9, Cisco IOS
UC Applications.
105
Provide supplementary services (hold, transfer, conferencing, and so on) for the
H.323 version 1 endpoint/gateway
Provide SIP trunk codec interworking (G.711 ulaw to alaw and vice versa) as well as
conversion of dual-tone multifrequency (DTMF) tones from SCCP to SIP and vice
versa
Software MTPs are created when IPVMS service is activated on a CUCM server. For a
software MTP, the only configuration required is to change the device pool. To change
the MTPs device pool, go to Media Resources > MTP and select the MTP for which
the device pool is to be changed. Choose the appropriate device pool and click Save. For
hardware MTP configuration, refer to the Resource Reservation Protocol section later
in this chapter.
Transcoder
Sometimes it is required to have one codec converted to another; for example, G.729
calls traversing over a WAN from a remote site might need to be converted to G.711 at
the data center. Transcoders are the hardware resources that enable a Cisco Collaboration
network to convert calls from one codec to another. Transcoders can be enabled on Cisco
IOS gateways and, like hardware conference bridges, they also leverage DSPs off PVDMs.
To configure a transcoder, follow these steps in Cisco Unified CM Administration:
Step 1.
Step 2.
Step 3.
For Transcoder Type, select Cisco IOS Enhanced Media Termination Point
and enter the name matching the associated DSP profile name in the Cisco
IOS router. Enter other required details. Click Save.
Music on Hold
MoH is played to a caller when the remote party in the call puts the caller on hold. MoH
requires an MoH server to be configured and an audio file that will be played during
the hold event. MoH is also part of Cisco IPVMS and is automatically created when
IPVMS is activated on a CUCM server. To configure/fine-tune an MoH server, go to
Media Resources > Music On Hold Server and select the server you wish to configure.
MoH audio can be played as unicast (default) or multicast streams. When multicast support is enabled, the multicast stream can increase, based on port number or IP address.
004_9780133845969_ch04.indd 105
6/25/14 10:15 AM
106
Multicast MoH is especially useful for remote sites to conserve bandwidth over WAN.
The concept of multicast MoH was briefly covered in Chapter 1, Cisco Collaboration
Infrastructure.
For the MoH audio source, additional audio files can be added to the MoH server.
Endpoints/devices can be configured to play different audio files as required. An MoH
audio source file can be assigned as User Hold Audio Source and/or Network Hold Audio
Source to the phones. If an audio source file is defined at the device level, it overrides the
device pool audio source preference. To upload an MoH audio file (the file must first be
uploaded to the CUCM that is functioning as the MoH server), go to the Cisco Unified
CM Administration page and choose Media Resources > Music on Hold Audio Source,
click Add New > Upload File, select an audio file you wish to upload as the MoH file,
and click Upload.
Step 2.
Step 3.
Provide a name for the MRG and add a media resource from the Available
Media Resources list to the Selected Media Resources list. Click Save.
Step 4.
To add an MRGL, go to Media Resources > Media Resource Group List and
click Add New.
Step 5.
Enter the MRGL name and add one or more MRGs from the Available Media
Resource Groups list to the Selected Media Resources Groups list.
Step 6.
You can change the order in which an MRG is queried by highlighting the
name and clicking the up and down arrows located to the right of Selected
Media Resource Groups box.
Step 7.
Click Save.
004_9780133845969_ch04.indd 106
6/25/14 10:15 AM
Signaling to
CUCM
TRP (MTP)
Media Anchored
to TRP
Cisco Unified
IP Phone
Figure 4-4
Jabber
Softphone
Media Anchored
to TRP
Jabber
Softphone
Cisco Unified
IP Phone
Call control
Gateways
108
Trunks
Endpoints
Class of Service
INTERNAL,
EMERGENCY
INTERNAL,
EMERGENCY, LOCAL
INTERNAL,
EMERGENCY, LOCAL,
NATIONAL
Calling Search
Spaces
Partitions
Route Patterns
INTERNAL
8XXXXXXX
EMERGENCY
911, 9.911
LOCAL
9.[2-9]XXXXXX
NATIONAL-CSS
NATIONAL
91.[2-9]XX[2-9]XXXXXX
Gateway/Trunks
Route Group
Route Lists
SIP-Trunk-Internal
RG-SIP-Trunk
RL-SIP-Trunk
Gateway 1
RG-Gateway-Trunk
RL-Gateway Trunk
INTERNAL-CSS
LOCAL-CSS
Gateway 2
Directory numbers
Route patterns
Translation patterns
Transformation patterns
004_9780133845969_ch04.indd 108
6/25/14 10:15 AM
Devices
Directory numbers
Gateways
Trunks
Translation patterns
From a user perspective, when the user dials digits, theyre processed by CUCM (digit
analysis/manipulation) and the devices (phones) CSS determines if the digits dialed have
access to the destination resource, which may be another phone, a route pattern, a gateway, and so on.
Translation Patterns
CUCM translation patterns allow digits to be manipulated before forwarding a call to a
local device or to a route pattern for further processing. Translation patterns can use both
pattern masks and transformation masks to perform digit manipulation. The output pattern after the translation pattern is applied is rerouted by CUCM or blocked as a result
of a second round of digit analysis. Translation patterns can only be used to route calls
within a system (on-net calling). To route an off-net call, the call must go to a route
pattern.
Route Patterns
CUCM route patterns are similar to translation patterns, with one major distinction:
route patterns can be used to route calls outside of a CUCM cluster, such as off-net
calls. Route patterns can point either to specific gateways/trunks directly or to route lists
(which further contain route groups, as shown in Figure 4-5). The call routing (off-net or
on-net leveraging trunks) uses the following flow: route pattern > route list > route group
> gateway/trunk. However, the order of configuration is the reverse; that is, a gateway
endpoint or a trunk must be configured before it can be assigned to a route group, which
in turn can be assigned to a route list, which can then be assigned to a route pattern.
Route List
A route list helps specify various route groups. For example, in a case where a call path
is unavailable, such as an IP WAN-based SIP trunk, the call can still be completed using
an alternative call path, such as the PSTN, without the user being aware that a certain call
path was unavailable. If a number dialed is an internal number, it must be expanded to an
E.164 format so that it can be routed over a PSTN network, and this can be achieved with
110
route listbased digit manipulation (digit manipulation is covered later in this chapter).
Hence, route lists serve a twofold purpose: providing alternate call path(s), and amending
a dialed number so that the call goes successfully through the first available call path.
Route Group
Route groups are logical entities that allow multiple gateways/trunks to be placed in one
or more route groups. This offers a level of redundancy when a certain endpoint or trunk
is not available. Also, route groups offer load balancing of calls. Route groups offer two
distribution algorithms: circular and top down. In the circular algorithm, all gateway
endpoints/trunks assigned to a route group are used, starting from the first entity, and
then the cycle begins again from the top. In the top-down algorithm, the first member of
a route group is used until it is unavailable, at which point CUCM call routing logic uses
the next-in-order gateway endpoint or trunk.
111
Site-A IP Phone
Device-Pool Site A
Site-A-RG
Site-A-Gateway
Route Pattern
911
Site-A-Gateway
Site-B-RG
Site-B-Gateway
Site-B Gateway
Site-B IP Phone
Device-Pool Site B
Device-Pool Site B
004_9780133845969_ch04.indd 111
6/25/14 10:15 AM
112
An LRG allows site specificity of call routing to be established by the calling devices
location as derived from the device pool. In this case, and as shown in Figure 4-6,
Device-Pool Sites A and B assign the LRG and inform CUCM that for Site A calls, Site-ARG is to be used, and for Site B calls, Site-B-RG must be used. Hence, different endpoints
in various sites are associated with different LRGs derived from the phones device pool.
However, they can all call the same route pattern(s), and the calls are routed differently
based on the callers currently associated LRG.
Time-of-Day Routing
CUCM offers Time-of-Day routing to help administrators and organizations apply certain
rules pertinent to dialing of long distance or international numbers (or stop dialing of any
numbers except emergency calls, depending on an organizations policy) post business
hours.
The following example illustrates the Time-of-Day routing concept. A phone in an organizations U.S. office is used to call an international number +91XXXXXXXXXX during
business hours. The CSS of the phone has access to a partition that allows calls to access
the (international) route pattern as the partition is active during those hours. Post business hours, the partition is rendered inactive, thereby disregarding calls to that partition
and in turn leaving the same phone unable to make international calls.
The following components are required to build Time-of-Day routing logic:
Time period: A range of time slots, such as 8:00 a.m. to 5:00 p.m. Monday through
Friday. If the time slots cannot be grouped into one time period, multiple time periods can be defined.
Time schedule: A group of time periods. By grouping time periods together into a
time schedule, noncontiguous time range(s) can be created, as required. For example,
if an organizations office is open 8:00 a.m. to 5:00 p.m. Monday through Friday
and 10:00 a.m. to 5:00 p.m. on Saturday, then two time periods can be defined and
assigned to the same time schedule.
Partitions: Once a time schedule is defined, it must be assigned to a partition for the
partition to be active/inactive during a specific time period.
After Time-of-Day routing is enabled, before routing a call, CUCM filters partitions in
the calling devices CSS. This is based on the time and time zone of the calling device and
the time schedules assigned to partitions. Then the active partition is used to route the
call. If there are no active partitions (for the dialed number destination) the caller gets a
fast-busy tone.
have an application dial rule to resolve the number to the route plan. An application dial
rule helps automatically strip numbers from, or add numbers to, a telephone number that
a user dials. For example, an application dial rule can automatically prefix a digit to a
telephone number to provide access to an outside line. The following is an example of an
outline for an application dial plan:
For seven-digit dialing where the number begins with 222 and the number of digits
is seven, prefix 9.
For ten-digit local dialing where the number begins with 408 and the number of digits is ten, strip the first three digits and prefix 9.
For ten-digit national dialing where the number of digits is ten, prefix 91.
For eleven-digit national dialing where the number of digits is eleven, prefix 9.
For international dialing where the number begins with +, strip the first digit and
prefix 9011.
1t7>#..........t1-: This pattern implies that the user must enter at least one digit. Then
the send occurs after 7 seconds. The terminating character # can also be applied
after the first digit is entered. After ten digits are entered, the timeout changes to 1
second.
114
0t2>#.t7-: This pattern implies that after a 0 is entered, if no other digit is entered,
the send occurs after 2 seconds. If another digit is entered, the send occurs after 7
seconds.
Stripping digits
Transformation
Masking a number
Gateway/Trunk
Figure 4-7
Digit Manipulation
In this case, the digit transformation prefixes the required number of digits to the calling number. Various digit manipulation mechanisms and their specifics are listed and
described in Table 4-3.
Table 4-3
Digit Manipulation
Mechanism
Description
Configuration Approach
External Phone
Number Mask
Translation Pattern
Transformation
Masks
Digit Prefix and Digit Prefix digits to or strip dialed digits from
Stripping
a route or translation pattern for outbound calls. Part of Calling/Called Party
Transformation settings. Digit Prefix helps
prepend digits to the pattern, such as digits
0 9, *, and # as part of Calling/Called Party
Transformation settings. Digit stripping
instructions help strip digits from a pattern as part of Called Party Transformation
settings (Discard Digits field). Maximum
digit discard instructions are available with
@ sign i.e. CUCM built-in numbering plan
(default NANP) is used in the route pattern. Valid digit discard instructions include
PreDot, PreAt, Trailing#, and so on.
004_9780133845969_ch04.indd 115
6/25/14 10:15 AM
116
Digit Manipulation
Mechanism
Description
Configuration Approach
Significant Digits
Enables CUCM to manage only the leastsignificant N digits of the called number
for incoming calls (from PSTN gateway/
trunk or from another CUCM cluster) and
is available as part of the Gateway/Trunk
Configuration settings.
Navigate to Device
> Gateway/Trunk
Configuration > Call
Routing Information
Inbound Calls.
SIP trunk
004_9780133845969_ch04.indd 116
6/25/14 10:15 AM
117
gatekeeper or an H.323 gateway. Moreover, H.225 trunks are a preferred way of routing
calls to and from Cisco Unified Communications Manager Express (CUCME).
A SIP trunk is based on RFC 3261 and allows a CUCM cluster to route calls to a SIP
endpoint such as a SIP UA, SIP UAS, SIP proxy, and so on (as discussed in Chapter 3).
CUCM SIP trunks may be used for various purposes, depending on which of the following options you choose for Trunk Service Type at Device > Trunk > Add New:
Call Control Discovery: Used for CUCM Service Advertisement Framework (SAF)
and Call Control Discovery (CCD) service (discussed later in this chapter)
Extension Mobility Cross Cluster: Used for Extension Mobility Cross Cluster
(EMCC) service (discussed later in this chapter)
IP Multimedia Subsystem Service Control (ISC): Used for integration with 3GPP
and fixed mobile convergence
Depending on the chosen trunk type and protocol, enter the required details such as
trunk name, destination IP address (or SRV in case of a SIP trunk), and so on. Click Save.
where, xyz = the username, corp.local = the hostname (domain or IP address), port =
5060 (default unless specified explicitly), and the URI parameters and headers are optional. SIP URIs identify communications resources. CUCM does not support URIs without a
username. Also, CUCM supports a hostname as either FQDN or IPv4 and does not support IPv6.
The Organization Top Domain (OTD) and Cluster Fully Qualified Domain Name
(CFQDN) can be configured at System > Enterprise Parameters to allow a call control
agent to distinguish between a local DN/URI and a remote URI. If the CFQDN, OTD, or
IP address of any cluster member matches the domain part of a URI, it is a local DN/URI.
SIP URI dialing offers multiple benefits, such as:
It offers extended support for SIP video endpoints registered with CUCM.
118
It offers unambiguous dialing from directories and enables easier B2B video call
routing.
In CUCM, the SIP URI concept is realized by the DN being aliased by a SIP/alphanumeric
(alpha) URI. All endpoints still have a DN, and phones always register via the DN and do
not necessarily even know if there is an associated SIP URI. An alpha URI can be associated with the DN on any device (not only SIP). Up to five URIs can be associated with
any DN, though only one alpha URI is marked as primary, as shown in Figure 4-8. It is the
primary URI that is used when blending identity for that DN (blended addressing is covered
later in this chapter). Directory URIs can be defined by an administrator or an end user.
Figure 4-8
Directory URI
A SIP URI call can be represented by the call flow overview shown in Figure 4-9.
CUCM Cluster
Routestring: corp.local
abc@corp.local
xyz@corp.local
DN 99901
DN 99902
Figure 4-9
Currently, URI dialing is supported only by a subset of IP Phones (including 99XX and
8961 IP Phones, except transfer, conferencing, and forwarding in the latter case), Jabber
clients, and video endpoints. In the context of URI-based call routing, the following specifics come into play:
Dialing from an enterprise directory based on CUCM always goes to a number and
not a URI.
An endpoint using other data sources (e.g., LDAP) might dial the alpha URI instead.
All phones can be called via a SIP URI because the URI is mapped to a DN.
Intrasite dialing is a two-step process (normalize and route). A normalization translation pattern might impose calling party transformations (in addition to called party
transformations).
Calling a URI takes a different path as the only option for calling party transformation is the calling party transformation CSS on calling endpoint or calling endpoints
device pool.
The default Directory URI partition will have all auto-generated user-based URIs.
119
si
ca
te
.lo
.c
eA
si
si
p
or
a
oc
te
l
p.
A.
co
rp
.lo
.c
or
or
ca
l
p.
lo
.c
eB
ca
si
l
CUCM Cluster Site C
Route String: siteC.corp.local
ILS Exchange
siteB.corp.local
siteC.corp.local
xyz@corp.local
Figure 4-10
pqr@corp.local
ILS allows propagation of individual alpha URIs between call-control agents (clusters) and
helps bind an alpha URI with attributes that allow routing to the URIs home cluster. Each
call-control agent replicates its alpha URIs to its neighbors and also announces a SIP route
120
string together with the alpha URIs. A SIP route string can be routed based on SIP route
patterns for intercluster call routing of alpha URIs, not based on the URIs host part, but
on the SIP route string.
The following are the components of end-to-end URI dialing/routing:
ILS networking
URI propagation
SIP trunk
There are three important points to consider. SIP connectivity is the foundation for call
routing based on SIP route patterns, ILS networking is the foundation for exchange of URI
reachability information, and URI propagation is enabled independently of ILS networking.
For ILS networking and URI propagation, the following must be considered:
Each call-control agent keeps a local copy of all URIs advertised by all other nodes
in the ILS network.
Each call-control agent periodically pulls in all changes in all URI catalogs advertised
into ILS from directly connected call-control agents (with an interval of 1 to 1440
minutes).
URI catalog updates propagate through the ILS network hop by hop (maximum
diameter is three hops).
Figure 4-11 illustrates ILS networking and the relationships between the call-control
agents acting as hubs and spokes.
ILS Spoke
ILS Spoke
ILS Hub
ILS Spoke
ILS Spoke
Figure 4-11
ILS Hub
ILS Networking
121
Ensure that a unique Cluster ID is defined for each cluster that is going to participate in ILS networking. The Cluster ID can be changed from the default by
browsing to the Cisco Unified CM Administration page and choosing System
> Enterprise Parameters.
Step 2.
Select a node in a cluster that will communicate with other nodes in other
call-control agents (clusters). This node is known as XNode and needs
to exchange Cisco Tomcat certificates with other XNodes. Using the
Bulk Certificate Management option in Cisco Unified Operating System
Administration (Security > Certificates), exchange the Cisco Tomcat certificates of an XNode with other XNodes.
Step 3.
Figure 4-12
ILS Configuration
Step 4.
On other clusters, to join an ILS network, set the Role to Spoke Cluster and
configure Registration Server as the SME IP address/hostname (in the window that pops up when saving the configuration for spoke cluster).
Step 5.
To define the unique SIP route string to be advertised for local alpha URIs, go
to Call Routing > Intercluster Directory URI > Intercluster Directory URI
Configuration. Check the Exchange Directory URI Catalogs with Remote
Clusters check box and provide the route string that should be exchanged
with ILS neighbors.
Step 6.
Configure SIP route patterns on leaf nodes and SME. SME needs specific SIP
route patterns for each SIP route string pointing to the respective leaf cluster,
such as siteA.corp.local or siteB.corp.local, whereas leaf clusters only need a
catch all SIP route pattern that matches on all SIP route strings and points
up to SME, such as *.corp.local.
122
At this time, ILS configuration is complete. Remote cluster information and services provided can be viewed by navigating to Advanced Features > Cluster View. Also, the ILS
Configuration menu enables you to monitor the sync state of URI data.
Blended Addressing
In CUCM, alpha URIs are assigned to DNs, and DNs are the primary identity with which
a device registers to CUCM. While electing between a DN or alpha URI, it becomes
ambiguous as to what is the correct identity to be presented during calls. While this may
depend largely on the devices involved in the call, a solution to overcome the ambiguity
is to use blended identity, which is a combination of the DN and alpha URI.
CUCM can build missing pieces, such as building the DN from the alpha URI by looking at the primary URI configured on the DN, or building the alpha URI from the DN by
searching for the DN that has the alpha URI as its primary URI. In blended addressing,
Remote-Party-ID (RPID) carries both the alpha URI and number in the following format:
Remote-Party-ID:<sip:abc@corp.local;x-cisco-number=+919999900000>
CUCM supports blended addressing that can be enabled as a policy on SIP trunks for
outbound calls, as shown in Figure 4-13. The default setting is Deliver DN Only in
Connected Party (for backward compatibility). The recommended setting is Deliver URI
and DN in Connected Party, If Available between clusters using URI dialing.
Figure 4-13
123
Locations-Based CAC
A CUCM location protects a WAN link at a remote site from being oversubscribed by
defining the maximum audio/video bandwidth allowed within a location. Locations work
in conjunction with regions to define the characteristics of a network link. Locations can
be associated to device pools and to devices themselves, such as a phone, trunk, gateway,
conference bridge, or MoH serverbasically, any device that sources media. Locations
can be dynamically associated to endpoints via device mobility groups (IP subnets).
Figure 4-14 depicts location configuration between a hub site and a remote site.
Figure 4-14
LCAC has a new option for immersive video: TelePresence. Now, you can establish separate immersive bandwidth settings on locations and links (links are explained in the next
section). Desktop video and TelePresence can reside in the same location, and the bandwidth can be deducted separately for either.
SIP trunks are used to classify a device or system as one of the following:
This is achieved by configuring a SIP profile to set a specific video class and assigning
that profile to a SIP trunk. However, LCAC has some restrictions:
LCAC isnt supported in real-world network models where customer networks are
multitier and multihop instead of simple hub-and-spoke topology.
124
Enhanced LCAC
E-LCAC enables network administrators to perform network modeling such as applying
locations and links to determine the best path(s) for a call to proceed between different
sites. The following are fundamentals of E-LCAC network modeling:
Links: Interconnect locations (to build the topology) and are used to define bandwidth available between locations. Links logically represent the WAN link.
Weights: Used on links to provide a cost to the effective path. Weights are pertinent only when there is more than one path between any two locations.
CUCM calculates shortest paths (least cost) from all locations to all locations and builds
the effective paths. CUCM tracks bandwidth across any link that the network model indicates from the originating location to the terminating location.
Figure 4-15 illustrates the network modeling with locations, links, and effective paths.
Location
Link
Link
Effective Path
Effective Path
Location
Link
Link
Location
Location
Figure 4-15
Intra-location bandwidth limits are assigned to a location to apply CAC to all calls made
To/From/Within the location. Intra-location bandwidth values are unlimited by default.
125
The Location Bandwidth Manager (LBM) service computes the effective path from the
source location to the destination location based on the following:
The sum weight of links across each possible path from source to destination. The
least-cost value of the paths weight determines the effective path.
After the effective path is determined, all subsequent calls that have the same source
and destination locations will use the same effective path.
LBM is a CUCM service that is activated by default for upgrades to CUCM 9.x from previous versions; however, it must be manually enabled for fresh installs by going to Cisco
Unified Serviceability > Tools > Service Activation. LBM can be enabled on multiple
servers in a cluster so that LBM groups can be configured to provide LBM redundancy.
Cisco CallManager service interacts with LBM service within a server, and LBM service
is replicated in a full mesh within a cluster. LBM groups can be configured within a single
site as well as within a cluster over the WAN. You can configure an LBM group by going
to System > Location Info > Location Bandwidth Manager Group, as shown in
Figure 4-16.
Figure 4-16
For intercluster CAC, each cluster manages its own topology. Each cluster then propagates its topology to other clusters configured in the LBM intercluster replication network. Each cluster then creates a Global Topology (also called Assembled Topology),
piecing together each clusters replicated topology. A single cluster, such as an SME cluster, manages all locations and links for the entire location replication network. All other
clusters, such as leaf clusters, are required to configure only the locations that are necessary to associate with endpoints and devices.
With E-LCAC there are two new location types:
Shadow location: A Shadow location is used to enable a SIP trunk to pass E-LCAC
information such as location name, location PKID, FateShareID, and traffic class. To
126
pass this location information across clusters, the SIP intercluster trunk (ICT) needs
to be assigned to the Shadow location. Similar to the Phantom location, a Shadow
location cannot have a link to other user/device locations, so no bandwidth can be
reserved between the Shadow location and other user/device locations. Any device
other than a SIP ICT that is assigned to the Shadow location is treated as if it were
associated to Hub_None.
Calls are accepted, re-marked, or rejected based on the outcome of RSVP reservation
and configured policy (optional, mandatory).
Figure 4-17 represents RSVP call flow including endpoints, CUCM RSVP agents, and
RSVP-enabled Cisco IOS routers.
CUCM uses two RSVP application IDs:
These IDs allow you to limit the maximum number of audio or video calls across a link.
Voice calls are marked as EF (default) and video calls (both audio and video streams) are
marked AF41 (default).
IP Phone A
CUCM
RSVP Agent A
RSVP Agent B
127
IP Phone B
Alerting Tone
Bandwidth Reservation
Successful
Call Setup to IP Phone B
Answer
Connect
Connect
Connect
Connect
Non-RSVP Protected
RTP Stream
RSVP Protected
RTP Stream
RSVP Protected
RTP Stream
Non-RSVP Protected
RTP Stream
Figure 4-17
RSVP configuration is a twofold process wherein CUCM and the IOS router must be configured for RSVP. Follow these steps to configure RSVP on CUCM:
Step 1.
Step 2.
Configure Mandatory RSVP mid call error handle option to Call Fails
Following Retry Counter Exceeded.
Step 3.
Go to Media Resources > MTP and click Add New. Configure a Media
Termination Point (MTP) similar to Figure 4-18.
As the final step, configure the Cisco IOS gateway as an RSVP agent so it can be inserted
in the call between CUCM and a remote IP Phone (provided the MTP is assigned to the
IP Phones MRGL). Example 4-1 outlines the configuration of Cisco IOS router MTP as
the RSVP agent.
128
Figure 4-18
129
After exchange and handshake between RSVP agents, the SDP (result of UPDATE from
initiator) looks like this:
m=audio 20000 RTP/AVP 0
c=IN IP4 10.10.100.201
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
In reply, the other RSVP agent sends the following SDP (result of 200 OK UPDATE):
m=audio 30000 RTP/AVP 0
c=IN IP4 10.20.10.200
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
With SIP preconditions, only one RSVP agent per cluster is required, and a topology
design with multiple clusters in a single data center or multisite distributed model is
supported.
To configure RSVP SIP preconditions, follow these steps in Cisco Unified CM
Administration:
Step 1.
Step 2.
Copy the default standard SIP Profile and add Trunk Specific Configuration
as follows:
Step 3.
Ensure that the check box Fall Back to Local RSVP is checked.
Apply the new SIP profile with SIP preconditions to a SIP trunk.
130
customers. CUCMs Call Recording feature enables organizations to archive the conversation of two or more parties for review, analysis, and/or legal compliance. A Cisco
Unified IP Phone can simultaneously support one monitoring and one recording session.
It is important to note that Cisco Unified Contact Center Express (UCCX) does not support the CUCM Silent Monitoring and Recording feature as it uses its own built-in silent
monitoring and call recording mechanism.
Figure 4-19 illustrates the CUCM-based Call Recording and Silent Monitoring
architecture.
Caller
(Customer)
PSTN/WAN
CUCM
Voice
Gateway
Observed
Voice Stream
MGCP/H.323/SIP
TAPI/JTAPI
Monitoring/Recording
Enabled Desktop Application
Callers Voice
Stream
SCCP/SIP
TAPI/JTAPI
SIP Trunk
VoiceEnabled Switch
Recording
Server
Monitored and
Recorded User (Agent)
Figure 4-19
Observer
(Supervisor)
Allows supervisors to monitor calls using their IP Phone. The media (RTP) plays
through the IP Phone and not the PC.
Monitoring sessions are managed as normal calls; calls can be transferred, held, or
conferenced.
CUCM-based Silent Monitoring does not require Switched Port Analyzer (SPAN)/
Remote SPAN (RSPAN).
Provides notification tones when legal compliance is required (an audible a periodic
tone can be played for agent or caller or both).
131
To enable Silent Monitoring on a Cisco Unified IP Phone, follow these steps in Cisco
Unified CM Administration:
Step 1.
Choose Device > Phone and set the Built In Bridge option to On.
Step 2.
From the Monitoring Calling Search Space drop-down list, choose the partition used to control who can monitor whom.
Step 3.
Navigate to System > Service Parameters > Cisco CallManager and in the
Clusterwide Parameters (Feature - Monitoring) area, set both Play Monitoring
Notification Tone To Observed Target and Play Monitoring Notification
Tone To Observed Connected Parties to True (or False as per the legal/
compliance requirement).
Step 4.
For Call Recording, an agents IP Phone relays two independent media streams (agent and
caller) to the recording server via the SIP trunk. Two broad recording modes are available
with CUCM-based Call Recording:
Call data is provided in the SIP header via CallID (RefCI), Directory Number (DN),
Device Name (MAC Address), Line Display Name, and Near-end/Far-end. Other callspecific data is retrieved via CTI using CallID.
004_9780133845969_ch04.indd 131
6/25/14 10:15 AM
132
Redundancy can be configured using a CUCM route list and/or DNS SRV records.
The IP Phone sends recorder streams using a codec determined by the region settings. If the codec required is different than the original call, a transcoder is automatically inserted.
Step 2.
Click Add New. Provide the required details such as device name, CSS, and
destination address.
Step 3.
Navigate to Device > Trunk and click Add New. Add a new SIP trunk. Fill in
the required information, and in the Destination Address field, enter the hostname or IP address of the recorder. Select a partition to be used for recording.
Step 4.
Go to Call Routing > Route/Hunt > Route Group and create a new Recorder
Route Group that contains the Recorder SIP Trunks. Consecutively add a new
Route List that contains the Recorder Route Group and a Route Pattern.
The Route Pattern should contain the DN for the Recorder and point to the
Recorder Route List.
Step 5.
Step 6.
Step 7.
Go to Device > Phone and select the phone for which recording is to be
enabled. Set the Built In Bridge option to On and select a Recording Profile
for each line appearance.
Step 8.
Choose the desired recording option for each line appearance: Automatic
Recording, Selective Recording, or Recording Disabled (default).
Step 9.
Add the Record softkey or programmable line key to the device template
and associate this with the IP phone. Disable codecs such as G.722, iSAC,
and iLBC which the Recorder may not support either via CUCM Service
Parameters or via the Audio Codec Preference List.
004_9780133845969_ch04.indd 132
6/25/14 10:15 AM
CUCM Mobility
133
CUCM Mobility
CUCM offers a comprehensive set of mobility features and functions for enterprise
mobile workers and ensures that they have persistent reachability and access to enterprise
voice and video services regardless of location. CUCM-centric mobility features can be
categorized as follows:
Device Mobility
Mobile Connect
User presses the Services button on an IP Phone and selects the Cisco Extension
Mobility service. The user enters an user ID and PIN.
After successful authentication, Extension Mobility selects the device profile associated with the user (or prompts the user to select if multiple associations exist).
The IP Phone configuration is updated with the configuration parameters from the
device profile. The phone is reset and loads the updated configuration.
Go to Cisco Unified Serviceability > Tools > Service Activation and activate
the Cisco Extension Mobility service.
Step 2.
Step 3.
Go to Device > Device Settings > Phone Services and add the Cisco
Extension Mobility phone service http://10.76.108.240:8080/emapp/
EMAppServlet?device=#DEVICENAME#. Create two services with the
same URL, one with the name EM Login and the other with the name
EM Logout. EM Login should be assigned to Phones and EM Logout should
be assigned to device profiles.
004_9780133845969_ch04.indd 133
6/25/14 10:15 AM
134
Step 4.
Navigate to Device > Device Settings > Device Profile and create default
device profiles for all phone models used in your organization.
Step 5.
Step 6.
Go to User Management > End User and select the user(s) for which the EM
service is to be enabled. Associate end user(s) with device profiles.
Step 7.
Navigate to Device > Phone and select the phone for which EM service
should be enabled. Ensure that under Extension Information, the check box
Enable Extension Mobility is checked. Subscribe the phone to the EM
Logout service.
Extension Mobility Cross Cluster (EMCC) takes EM one step further and enables a user
roaming between two or more clusters. Unlike EM, a user is no longer restricted to a single cluster (intra-cluster) device roaming and can log in and log out on devices between
two or more clusters enabled for EMCC.
EMCC has the concept of a home cluster and a visiting (remote) cluster. A home cluster
is where the user is natively configured and usually leverages EM. A visiting cluster is the
nonnative cluster where the user can roam to and still leverage EM and access to all the
features available in the home cluster. EMCC supports the users home clusters dialing
behavior. EMCC supports secure phone registration.
The EMCC process works as follows:
The user from the home cluster logs in to a phone at a visiting cluster.
The login procedure brings the device information into the home cluster database.
The home cluster database builds a temporary device with the users device profile.
The home cluster TFTP server builds the phone configuration file.
After login, the visiting cluster directs the phone to the home cluster TFTP server.
The IP phone downloads its TFTP configuration from the home cluster TFTP server
and cross-registers with the home cluster CUCM.
To configure EMCC, first complete the EM configuration steps, and then follow these
steps:
Step 1.
Step 2.
Step 3.
Repeat Steps 1 and 2 to export, consolidate, and import certificates from visiting clusters to the home cluster.
CUCM Mobility
Step 4.
Step 5.
Navigate to Bulk Administration > EMCC > EMCC Template. Click Add
New to create a new template and enter require details.
Step 6.
Step 7.
Step 8.
Go to System > Geolocation Filter and click Add New. Create a new EMCC
Geolocation filter.
Step 9.
135
Step 10. Configure a SIP trunk by navigating to Device > Trunk > Add New and
choosing SIP as the protocol. Set the Trunk Service Type field to Extension
Mobility Cross Clusters. Enter required details and check the Send
Geolocation check box.
Step 11. Go to Advanced Features > EMCC > EMCC Intercluster Service Profile
and check the Active check box for EMCC, PSTN Access, and RSVP Agent.
Ensure that the right SIP trunk is selected in the PSTN Access pane. Validate
the settings.
Step 12. Navigate to Advanced Features > EMCC > EMCC Remote Cluster and add
required details about the visiting cluster.
Step 13. Go to System > Service Parameters, choose the CUCM server where EM
is enabled, and activate Cisco Extension Mobility. Click Advanced and set
Inter-cluster Maximum Login Time and EMCC Allow Proxy to True.
At this time, the EMCC configuration is complete.
Device Mobility
Device mobility allows CUCM to apply site-specific configuration to roaming devices
such as Jabber clients. This helps ensure that a roaming device uses local-site gateways for
PSTN (where applicable) or is restricted to VoIP-only access. To enable device mobility,
CUCM is configured with IP subnets and matching device pools to identify sites. CUCM
compares the Physical Location parameter in the devices device pool and the device pool
configured on the IP subnet. If the Physical Location is different, CUCM applies the IP
subnets device pool configuration to the endpoint, builds a new configuration file, and
resets the endpoint. The settings applied to roaming handsets include Date/Time Group,
Region, Location, SRST Reference, Physical Location, and MRGL.
136
Choose System > Service Parameters > Cisco CallManager and set Device
Mobility Mode to On. Alternatively, this can be done on a per-endpoint basis
from within the Phone Configuration window.
Step 2.
Navigate to System > Physical Location. Click Add New and enter required
information.
Step 3.
Go to System > Device Mobility > Device Mobility Group. Click Add New
and enter required information.
Step 4.
Navigate to System > Device Mobility > Device Mobility Info. Click Add
New. Enter the name, subnet (for which endpoints have to be tracked), and
subnet size, and choose device pools for which this device mobility information is significant.
Step 5.
Go to System > Device Pool and select the device pool for which device
mobility is to be enabled. Under Roaming Sensitive Settings, select options
in the Device Mobility Group and Physical Location drop-down lists. Under
Device Mobility Related Information, enter the respective information that
will apply to devices when roaming.
Mobile Connect
Mobile Connect is also known as Single Number Reach (SNR). SNR supports redirecting
incoming calls from CUCM to up to ten different remote (destinations) devices. When
theres an incoming call, it rings the local IP Phone as well as any of the enabled remote
devices. If the call goes unanswered, it is routed to the local IP Phone. Figure 4-20 shows
the Mobile Connect call flows.
As shown in Figure 4-20, there are two call flows: one from the PSTN caller to a users
desk phone that is enabled for mobility, and the other from a users remote device to
an internal phone. For the first call flow, when the PSTN caller rings the desk phone
+15555559000, CUCM intercepts the call and, using the users configured remote
destination profile(s), rings all the remote devices (in this case the users mobile phone
at +14088888000) including the desk phone (DN 9000) with caller ID of PSTN caller
(+15558888000). At this time, the user has an option to pick up the call on any local and
reachable device, be it the desk phone or the mobile phone. For the second call flow,
the user dials an internal number (9001) using the E.164 number +15555559001, CUCM
intercepts the call and matches the dialed number to the remote destination(s) configured,
which in turn is mapped to an internal DN. After finding a match, CUCM directs the
call to the internal number (after digit striping/manipulation) with caller ID of internal
DN 9000.
CUCM Mobility
137
Call from
+15558888000
PSTN Caller
+15558888000
Remote Phone
(of DN 9000)
+14088888000
Call to
+15555559000
Call to
+15555559001
PSTN
Voice Enabled
Switch
CUCM
(Mobile Connect)
Figure 4-20
Go to Cisco Unified Serviceability > Tools > Service Activation and enable
Cisco Unified Mobile Voice Access Service.
Step 2.
004_9780133845969_ch04.indd 137
6/25/14 10:15 AM
138
Step 3.
Step 4.
Navigate to User Management > End User and select the user for which
SNR is required. Under Mobility Information, make sure the Enable Mobility
check box is checked.
Step 5.
Go to Device > Phone and select the IP Phone for which mobility is to be
enabled. Assign the Standard Mobility User Softkey template to the phone.
Step 6.
Navigate to Device > Device Settings > Remote Destination Profile. Enter
the required information, including a user ID for which the profile is to be
configured. Click Save. Create a new DN and ensure that the DN is the same
as the users desk phone.
Step 7.
Go to Cisco Unified Serviceability > Tools > Service Activation and enable
Cisco Unified Mobile Voice Access Service.
Step 2.
004_9780133845969_ch04.indd 138
6/25/14 10:15 AM
CUCM Mobility
PSTN Phone
+15558888000
139
Remote Phone
(of DN 9000)
+14088888000
Call from
+15555559000
Call to
+15555559999
PSTN
H.323 VXML
Voice Gateway
(IVR Application)
Remote Destination
Number and PIN
CUCM
(MVA)
9999
5555559XXX
Voice
Enabled Switch
Cisco Unified IP
Phone DN = 9000
Figure 4-21
Step 3.
Go to Media Resources > Mobile Voice Access and configure Mobile Voice
Access Directory Number (for example, 9999) and Mobile Voice Access
Partition.
Step 4.
Navigate to User Management > End User and select the user to be configured for mobility. Ensure that the Enable Mobile Voice Access check box is
checked and that Maximum Wait Time for Desk Pickup is configured (apart
from other mobility-related specifics). Also make sure that the user has the
appropriate roles assigned to it (Standard CCM End Users, Standard CCM
User Administration, Standard CTI Enabled, Standard CTI Allow Control of
All Devices).
Finally, configure an H.323 voice gateway to accept incoming calls on the POTS dial peer
for MVA and forward the same to CUCM, as shown in Example 4-2.
Example 4-2 MVA Configuration on Cisco IOS Router
MVARouter(config)# application
MVARouter(config-app)# service mva http://10.76.108.240:8080/ccmivr/pages/
IVRMainpage.vxml
!
004_9780133845969_ch04.indd 139
6/25/14 10:15 AM
140
SAF Architecture
A Cisco SAF network is composed of multiple entities and multiple protocols. Figure
4-22 depicts the Cisco SAF architecture.
CUCM Cluster
(SAF Client)
CUBE
(SAF Client)
CUCME
(SAF Client)
IOS Gateway
(SAF Client)
SME Cluster
(SAF Client)
CCD
CCD
CCD
CCD
CCD
SAF Client
Protocol
SAF Forwarder
SAF Forwarder
SAF Forwarder
SAF Forwarder
141
SAF Client
Protocol
SAF Forwarding
Protocol
SAF Forwarder
Figure 4-22
SAF Forwarder
Table 4-4 lists some of the SAF terms used to describe the role of each SAF entity in a
Cisco SAF network.
Table 4-4
SAF Component
Description
SAF client
An application that is capable of advertising a service to the network or requesting a service from the network, or both. CUCM
is an example of a SAF client.
SAF forwarder
Service
Any information that a SAF client wishes to advertise and consume, such as dial plans for CCD service.
SAF Advertisement
Non-SAF node
A SAF forwarder learns dial plan information from a SAF client (leveraging CCD service).
Then the SAF forwarder exchanges learned call-routing information with other SAF forwarders as well as SAF clients so that the SAF-enabled network is aware of all learned call
142
routes. This helps overcome the full-mesh, point-to-multipoint manual dial plan proliferation and solves the complexity of managing a full mesh of static trunks without a single
point of failure.
A SAF message consists of two parts: SAF header and SAF service data. The SAF header
is significant to SAF forwarders because it identifies the service type (such as CCD) and
includes information relevant for dynamic distribution of SAF services. SAF service data
is significant to SAF clients and includes the IP address and port of the advertising SAF
client. It also contains detailed client data describing the advertised service (for example,
CCD client data includes call-routing information such as directory numbers, the signaling protocol used by call-control agent, PSTN prefixes, and so on).
CCD Requesting Service: Responsible for learning hosted DN routes from the SAF
network. It stores learned route information locally and registers it with CUCM
Digit Analysis. CCD Requesting Service performs load balancing for calls to learned
routes. If a call cant go through via the IP network, CCD Requesting Service routes
the call via the PSTN network.
Figure 4-23 illustrates CCD advertised and learned routes (dial plan) across a SAFenabled network.
As shown in Figure 4-23, three locations are configured to advertise and learn their
respective hosted DNs: San Jose (CUCM Cluster), Delhi (Cisco Unified CME), and
Singapore (Cisco Unified CME). The SAF forwarders advertise the learned route(s) from
respective SAF clients to their peers and in turn acquire their routes and pass on the
information to SAF clients (CUCM and CUCME), thereby building the CCD dial plan.
Each SAF client builds a database, based on dynamic call routing, that has the route,
PSTN prefix, remote IP address, and protocol to be used for routing calls.
DN Pattern
to DID Rule
IP Address
Protocol
+656585 /4 10.96.108.240
143
SIP
H.323
DN Pattern
to DID Rule
8963XXXX
+1408567 /4 10.76.108.146
IP Address
Protocol
SIP
8962XXXX
+656585 /4 10.96.108.240
H.323
PSTN
8963XXXX
10.76.108.146
San Jose
SAF Forwarder
SAF-Enabled
Network
8961XXXX
10.86.108.230
Delhi
SAF Forwarder
Singapore
8962XXXX
DN Pattern
to DID Rule
8963XXXX
+1408567 /4 10.76.108.146
H.323
H.323
Figure 4-23
IP Address
Protocol
To configure SAF and CCD on a CUCM cluster, use the following steps in Cisco Unified
CM Administration:
Step 1.
Choose Advanced Features > SAF > SAF Security Profile and create a New
Profile and enter the required information. Ensure that the username and
password entered match the credentials entered in IOS routers external-client
configuration. Click Save.
Step 2.
Navigate to Advanced Features > SAF > SAF Forwarder and create a new
SAF forwarder. Use the external client configuration parameters to complete
the Client Label, SAF Forwarder Address, and SAF Forwarder Port fields, and
from the SAF Security Profile drop-down list, select the security profile created in Step 1. Click Save.
Step 3.
Go to Call Routing > Call Control Discovery > Hosted DN Group and create a group. Enter required information and click Save.
144
Step 4.
Navigate to Call Routing > Call Control Discovery > Hosted DN Pattern
and add a route pattern as you expect from the PSTN (after digit manipulation); for example, 8XXX. Assign it to Hosted DN Group and click Save.
Step 5.
Go to Device > Trunk and create a new SIP trunk with Service Type as Call
Control Discovery. Configure this trunk as any other SIP trunk. Click Save.
Alternatively, an H.323 (H.225) trunk may be configured for a SAF client that
does not support SIP.
Step 6.
Navigate to Call Routing > Call Control Discovery > Advertising Service
and add a new service. Select the SIP trunk (or H.323 trunk) and the Hosted
DN group configured earlier. Click Save.
Step 7.
Go to Call Routing > Call Control Discovery > Requesting Service and add
a new service. Add the SIP/H.323 trunk and click Save.
For SAF and CCD configuration on Cisco IOS routers, see Chapter 9.
Additional CUCM service parameters can be fine-tuned for SAF and are listed in
Table 4-5.
Table 4-5
Description
CCD Learned Pattern IP Reachable Specifies the number of seconds that learned patterns
Duration
stay active before CUCM marks them as unreachable.
CCD PSTN Failover Duration
CCD Stop Routing On Unallocated Specifies whether CUCM continues to route calls to the
Unassigned Number
next call-control entity when the current call-control
entity rejects the call with cause code Unallocated/
Unassigned Number.
Chapter 5
Cisco Unified
Communications Security
As discussed in the previous chapters, a Cisco Collaboration solution has many elements,
including infrastructure, endpoints, applications, gateways, and so on. While all of these
work together to deliver a seamless user experience, they need to be secured to ensure
that business continuity is maintained and the communication channels are operational.
The objective of securing a Cisco Collaboration solution is to secure a converged
communications network to protect its availability, the condentiality of data that it
carries, and the integrity of this data.
Security Policy
The fundamental step to achieve a robust and secure converged network is to develop a
security policy that specifies an appropriate security plan, design, implementation, and
operations policy. A security policy gives direction to the efforts to deploy security
controls at the various layers of the OSI model, starting at the physical layer, Layer 1, up
through the application layer, Layer 7. At a high level, a security policy should at least
address the following from a Cisco Collaboration network perspective:
Perimeter security
Server hardening
146
Threat Category
Description
Eavesdropping/
interception attacks
Aimed at voice and signaling sessions, leading to loss of confidentiality or integrity, or both.
Identity theft/
impersonation attacks
Toll fraud
Denial-of-service (DoS)
attacks
Intrusion attacks
Theres no single security control or tool/mechanism to thwart all the attack types listed
in Table 5-1. Defense-in-Depth, also known as a layered security approach, is required to
mitigate these threats. The following sections give insight into security measures at the
various layers of the OSI model.
Layer 1 Security
Physical security entails securing Cisco Collaboration assets from physical access by an
intruder and from potential damage by surrounding environmental factors. The major
physical security controls include
Cisco Collaboration equipment secured in racks in data center and in closets at user
access level
147
Layer 2 Security
Layer 2 security can be deployed at the switching layer to prevent attacks originating
from the user access layer such as:
DHCP spoofing
ARP poisoning
Identity spoofing
Port Security
Cisco Catalyst switches have a feature called port security that helps to reduce spoofing and other attacks. Port security restricts the input to an interface by limiting and
identifying MAC addresses of end devices. The port security feature can leverage MAC
address learning in the following ways:
Static secure MAC address: Manually limits the MAC addresses to be allowed on
a switch port by statically configuring the MAC addresses on a per-port basis. This
feature allows MAC addresses learned to be saved in Content Addressable Memory
(CAM) table and running configuration.
Sticky secure MAC address: The switch port dynamically learns the MAC addresses of connected devices (sticky) configured for sticky secure MAC addresses and
stores these in the CAM table and running configuration.
Dynamic secure MAC address: The MAC addresses learned from the switch port
set up for dynamic secure MAC addresses are stored only in a switchs CAM table
and not in the running configuration.
Upon violation of the number of MAC addresses per port, you can configure violation
rules in one of following three ways:
Protect: When the switch port reaches its configured maximum number of secure
MAC addresses, it starts dropping frames with an unknown source MAC address.
Restrict: Similar to the protect option, the major difference being that the restrict
option can send an SNMP trap and a syslog message. It increments the violation
counter when a port security violation occurs.
Shutdown: After a port security violation occurs, the port is shut down and put in
err-disable state. This option also allows generation of the SNMP and syslog notifications, identical to the restrict option, and it will also increment a violation counter.
148
Example 5-1 illustrates enabling port security on a Cisco Catalyst switch for interface
FastEthernet 0/10 where the maximum number of MAC addresses is set to 3 on this
particular interface, and the port, upon exceeding the maximum count, will be put in errdisable mode (shut down). The mac-address command is used to set a static MAC and
remember the MAC addresses connected to it (sticky).
Example 5-1
DHCP Snooping
DHCP spoofing is used to launch Man-In-The-Middle (MITM), reconnaissance, and DoS
attacks. In the DHCP spoofing attack, the attacker enables a rogue DHCP server on a
network. When an endpoint (Cisco Unified IP Phone or softphone) sends a broadcast
request for the DHCP configuration information, the rogue DHCP server responds before
the original DHCP, thereby assigning the attacker-defined IP configuration information.
DHCP snooping is a Cisco Catalyst switch feature that helps prevent DHCP spoofing
attacks by enabling the switch ports to be set as either trusted (DHCP server-facing
interface) or untrusted (user facing). Trusted switch ports can send DHCP requests and
acknowledgements, whereas untrusted ports can only forward DHCP requests. DHCP
snooping enables the switch to build a DHCP binding table that maps a client MAC
address, IP address, VLAN, and port ID. Example 5-2 outlines DHCP snooping configuration where FastEthernet 0/10 is set to trusted and FastEthernet 0/20 is set to untrusted.
Example 5-2
DHCP snooping is also used for Dynamic ARP Inspection (DAI), as discussed later in this
chapter.
149
802.1x
802.1x is a standard set by the IEEE 802.1 working group. Its a framework designed
to address and provide port-based access control using authentication, primarily using
Extensible Authentication Protocol (EAP) as the key protocol. 802.1x is a Layer 2 protocol for transporting authentication messages (EAP) between a supplicant (user/endpoint/
PC) and an authenticator (switch or access point) with an (optional) authentication server
150
(RADIUS) at the back end to authenticate the supplicant. For wired supplicants, EAP
over LAN (EAPoL) is used, and for wireless supplicants, EAP over Wireless (EAPoW) is
used. Figure 5-1 shows 802.1x via EAPoL and EAPoW for wired and wireless supplicants,
respectively, to a RADIUS (Cisco TACACS+) server.
Wireless AP
(Authenticator)
LAN Switch
(Authenticator)
RADIUS/TACACS+
(Authentication Server)
EAPoL
EAPoW
PVID
Wireless Client
(Supplicant)
Figure 5-1
Wired Client
(Supplicant)
802.1Q
VVID
IP Phone
(Supplicant)
Multidomain Authentication (MDA) helps define two domains on the same physical
switch port: Voice VLAN Identifier (VVID) and Port VLAN Identifier (PVID). The 802.1x
process for voice using an EAPoL and MDA approach is shown in the following steps:
Step 1.
A Cisco Unified IP Phone learns VVID from Cisco Discovery Protocol (CDP).
Third-party phones use Link Layer Discovery Protocol (LLDP). 802.1x times
out.
Step 2.
Step 3.
Step 4.
Step 5.
The daisy-chained PC (connected to the PC port on the IP Phone) authenticates using 802.1x or MAB. PC traffic is allowed on the data VLAN only.
151
Layer 3 Security
At Layer 3 of the OSI model, the following security mechanisms help restrain attacks
from within and outside of a network:
Deploying RFC 2827 filtering, uRPF, and IP source guard (prevents IP spoofing)
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
0.0.0.0/8
127.0.0.0/8
169.254.0.0
IP Source Guard
The IP source guard feature can be enabled on untrusted switch ports. This feature
blocks all IP traffic initially, except for DHCP packets captured by the DHCP snooping
process. When a client receives a valid IP address from the trusted DHCP server, a port
ACL (PACL) is applied to the port. This restricts the traffic only from known client source
IP addresses configured in the binding, disregarding any other IP traffic. The following configuration enables IP source guard on the FastEthernet 0/10 interface of a Cisco
Catalyst switch:
152
RIPv2
EIGRP
OSPF
BGP4
Router Hardening
Cisco IOS routers can be hardened by disabling services such as finger, TCP and UDP
small servers, BootP, and Proxy ARP.
153
Cisco ASA works in routed mode, transparent mode, or multiple-context mode. In routed
mode Cisco ASA appears as a hop in the networkthat is, it works at Layer 3. Routed
mode supports multiple interfaces and practically all Cisco Collaboration services/applications. For Cisco Collaboration network deployments, Cisco ASA should be configured
in a single (default) context as a routed firewall.
Cisco ASA, on the other hand, also works in transparent mode where it is a Layer 2 firewall that acts like a bump in the wire. In transparent mode, Cisco ASA has some limitations pertinent to voice and video traffic:
Cisco ASA also supports multiple-context mode, also known as multimode. In multiplecontext mode, the firewall is regarded as multiple separate virtual firewalls on the same
physical hardware. However, multiple-mode also has some feature limitations (in addition
to those defined for transparent firewall):
NAT Traversal
Almost every firewall (including Cisco ASA) provides NAT services to enable manipulating the IP address or port number, or both, for traffic going out or coming into a network. To ensure that voice traffic is unaltered by NAT, either it should be exempted from
NAT or appropriate inspection mechanisms should be applied to enable the firewall to
look at the contents of the packets. NAT control can be turned off on Cisco ASA, thereby allowing packets to traverse Cisco ASA unaltered. Also, use of RFC 1918 addresses
on internal servers is recommended, where possible, such that globally routable (public)
network addresses do not pass through the firewall using a NAT mechanism. NAT/ALG
firewalls/devices can inspect signaling in normal mode (that is, TCP/UDP-based
154
signaling), but with encrypted signaling leveraging Transport Layer Security (TLS), a
NAT/ALG-aware firewall is unable to look into the content of packets.
IPsec Tunnels
Site-to-site or remote-access VPN IPsec tunnels can be used to enable NAT exemption.
Moreover, if the VPN gateway is placed behind a firewall, the firewall is unable to inspect
or modify the contents of the packet within the tunnel. This is an ideal solution when a
corporate firewall is required to filter all traffic except voice/video traffic.
IP-Based ACLs
Traffic from the Internet, remote sites, telecommuters, and remote workers can be filtered
based on IP ACLs. This allows a modest degree of control on the traffic that traverses
through the firewall. In such cases, inspections may still be required to handle voice and
video signaling and media traffic.
Port-Based ACLs
Synonymous to IP-based ACLs, port-based ACLs can be used for filtering traffic from/
to an external network to the data center. Port-based ACLs give an administrator or a
security engineer a greater degree of control and allow for the least permissive policy.
However, port-based ACLs are also the most tedious to configure because every port for
a Cisco Collaboration protocol or service needs to be looked at and allowed or denied as
per the organizations policy.
In case of voice and video signaling and media traffic, quite a few protocols and ports
must be permitted to ensure that the Collaboration services operate appropriately. As
discussed in Chapter 3, Telephony Standards and Protocols, the most commonly used
voice and video protocols include SCCP, MGCP, H.323, SIP, RTP, and RTCP.
Moreover, there are other protocols that are used for administration and integration of
voice services, such as SSH, TAPI/JTAPI, HTTP, HTTPS, TFTP, DNS, and LDAP.
For a complete list of TCP/UDP ports that are required for firewall traversal for
CUCM, refer to Cisco Unified Communications Manager TCP and UDP Port Usage
at www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/port/9_1_1/CUCM_BK_
T2CA6EDE_00_tcp-port-usage-guide-91/CUCM_BK_T2CA6EDE_00_tcp-port-usageguide-91_chapter_01.html.
For video communications, Cisco Video Communications Server (VCS) can be deployed
as Cisco TelePresence VCS Control for use within an enterprise and as the Cisco VCS
Expressway for communication with external entities. VCS Expressway enables businessto-business (B2B) communications and includes the features of the Cisco VCS Control
with highly secure firewall traversal capability. VCS Expressway can be implemented
either on the inside (secure zone) or in the demilitarized zone (DMZ). VCS Expressway
firewall traversal is shown in Figure 5-2.
Telepresence System
Data Center
Firewall
SIP
Firewall
SIP
Video IP Phone
SIP
Internet
SIP
Video IP Phone
Figure 5-2
155
SIP
CUCM Cluster
VCS Control
VCS Expressway
SIP
Telepresence System
Its important to note that SIP and H.323 protocol inspection on the firewall must be disabled. Instead, the firewall should be configured for traversal leveraging requisite ports.
For details on the ports that are required for firewall traversal, refer to the deployment
guide Cisco VCS IP Port Usage for Firewall Traversal (PDF file) at www.cisco.com/c/
dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-IP-PortUsage-for-Firewall-Traversal-Deployment-Guide-X8-1.pdf.
TLS Proxy: Enables Cisco ASA to decrypt and inspect encrypted signaling before
Cisco ASA re-encrypts the signaling to the destination, thereby ensuring that all traffic passing through the firewall is compliant with the organizations security policy.
TLS Proxy requires encrypted endpoints on the outside and inside of an ASAbrokered network, which implies that the CUCM cluster within the organization is
in mixed mode (a mixed-mode cluster is in secure mode, as explained later in this
chapter).
Phone Proxy: Secures remote access for encrypted Cisco Unified IP Phone endpoints and VLAN traversal for Cisco softphones. It enables a remote user to plug in
an IP Phone directly to a hotel/home network and make secure calls through the centralized CUCM cluster via the Internet. Moreover, unlike TLS Proxy, Phone Proxy
doesnt require internal endpoints to be encrypted; hence, the CUCM cluster within
an organizations data center can be in unsecure mode or mixed mode.
Cisco ASA Phone Proxy and TLS Proxy services are not supported with CUCM version
9.x. Instead, Cisco VPN Phone is recommended for secure remote endpoint connection
and traversal at the enterprise-edge firewall. Also, as an alternative to the ASA Phone
Proxy feature, Cisco Unified Border Element (CUBE) supports Phone Proxy with B2BUA
line-side support for CUCM. Phone Proxy is supported with Cisco IOS version 15.3(3)
M1 and later on the Cisco Integrated Services Routers Generation 2 (ISR G2) platform. It
allows organizations to have phones on the Internet connected to a CUBE at the edge of
the enterprise and securely set up signaling/media with phones in the enterprise premises.
156
Data Center
SCCP
SSL Session
(AnyConnect)
SOHO, Telecommuter,
Hotel Room
Enterprise Premises
Internet
Cisco Unified IP
Phone
CUCM Cluster
Cisco ASA
Cisco Unified IP
Phone
RTP
Figure 5-3
Cisco VPN Phone is supported on 7942G, 7945G, 7962G, 7965G, 7975G, and 99xx
series as well as 89xx series Cisco Unified IP Phones. For a complete list of supported
IP Phones in a certain CUCM version, go to Cisco Unified CM Administration and
choose Cisco Unified Reporting > System Reports > Unified CM Phone Feature List >
Generate a New Report > Feature: Virtual Private Network Client.
The minimum requirements for implementing Cisco VPN Phone are as follows:
AnyConnect premium license and AnyConnect for Cisco VPN Phone license
required for Cisco ASA
Example 5-5 outlines the configuration on Cisco ASA to support Cisco VPN Phone.
Example 5-5 Cisco ASA VPN Phone Configuration
UCASA(config)# group-policy GroupPolicy1 attributes
UCASA(config-group-policy)# vpn-tunnel-protocol WebVPN
!
UCASA(config)# ip local pool VPN-Phone 10.10.1.200-10.10.1.254 mask 255.255.255.0
!
157
The following steps summarize the configuration required on CUCM to support the
Cisco VPN Phone feature:
Step 1.
Step 2.
Step 3.
Create a VPN group under Advanced Features > VPN > VPN Group.
Step 4.
Configure the VPN Profile under Advanced Features > VPN > VPN Profile.
Step 5.
Assign the VPN group and profile to the Common Phone Profile by going to
Device > Device Settings > Common Phone Profile.
Step 6.
Configure the Cisco Unified IP Phone with a TFTP server manually and register the IP Phone internally to test and ensure that VPN works, before you give
it to a user.
Step 7.
158
ITL is similar to CTL, but ITL does not need any security feature to be enabled explicitly.
Moreover, ITL is not a replacement for CTL; it is for initial security so that endpoints
can trust the CUCM. To encrypt signaling or media, CTL is still required. The ITL file is
created automatically when the cluster is installed. The CUCM TFTP servers private key
is used to sign the ITL file. When a CUCM server/cluster is in non-secure mode, the ITL
file is downloaded on every supported Cisco Unified IP Phone; however, when a CUCM
server/cluster is in mixed mode, the CTL file is downloaded followed by the ITL file. The
contents of an ITL file can be viewed by using the CUCM OS CLI command
admin: show itl.
Non-secure mode is the default mode when a CUCM cluster (or server) is installed fresh.
In this mode, CUCM cannot provide secure signaling or media services. To enable secure
mode on a CUCM server/cluster, the Certificate Authority Proxy Function (CAPF) service must be enabled on the publisher and the Certificate Trust List (CTL) service must
be enabled on the publisher and subscribers. Then the cluster can be changed from nonsecure mode to mixed mode. The reason it is known as mixed mode is that in this mode
CUCM can support both secured and non-secured endpoints. For endpoint security,
Transport Layer Security (TLS) is used for signaling and Secure RTP (SRTP) is used for
media.
To convert a CUCM cluster into mixed mode, follow these steps:
Step 1.
Step 2.
Restart CCM and TFTP services on every node where these services are
enabled.
Step 3.
Return to CUCM Administration and choose Application > Plugins to download and install the CTL Client plug-in for Windows.
Step 4.
After the CTL client is installed, log in with the IP address of the publisher
and the CUCMAdministrator credentials. Follow the installation prompts.
Step 5.
Click the Set Cisco Unified CallManager Cluster to Mixed Mode radio
button.
Step 6.
Insert the USB eToken when prompted by the CTL client wizard, and
click OK.
Step 7.
The CTL client wizard prompts for a second eToken, removes the first eToken,
and inserts the second USB eToken. Click OK. Click Finish. When prompted
for the password for the eToken, enter the default password Cisco123.
Step 8.
After the CTL client wizard completes signing certificates on each server in
the cluster, it reminds you to restart the CCM and TFTP services on whichever servers they are configured. Click Done. Restart the CCM and TFTP
services on all servers where they are enabled and activated.
159
You can verify the clusters conversion to mixed mode by going to System > Enterprise
Parameters. The parameter Cluster Security Mode should be 1, which indicates that the
cluster is running in mixed mode.
Server Certificate
Public Key
Serial Number
Signature
Issuer Name
Subject Name
Server Function
005_9780133845969_ch05.indd 159
6/25/14 11:07 AM
160
DNS name
A CTL file (downloaded to Cisco Unified IP Phones and softclients) consists of the following entries (server entries or security tokens):
CUCM
Cisco TFTP
CAPF
CUCM Trusted
Certificate
TFTP Trusted
Certificate
CAPF Trusted
Certificate
CA Trusted
Certificate
Figure 5-4
161
The contents of a CTL file can be viewed by issuing the CUCM OS CLI command
admin: show ctl.
Cisco manufacturing is the source for the MIC. Cisco installs the MIC in nonerasable,
nonvolatile memory on a Cisco Unified IP Phone. It is available in all new phone models, and the root Certificate Authority (CA) is Cisco Certificate Authority. On the other
hand, the CAPF service is the source (root) of the LSC, which must be installed by the
UC administrator in erasable phone memory. The LSC can be signed by an organizations
internal CA or an external trusted CA. Figure 5-5 depicts the difference between the MIC
and the LSC.
Cisco Manufacturing CA
Cisco
Manufacturing
MIC
(Cisco CA
Public Key)
Figure 5-5
CAPF
TLS
LSC
(CAPF
Public Key)
MGCP gateway with SRTP package and IPsec tunnel to CUCM (or default gateway
device for CUCM). IPsec is for protection of signaling, which in the case of MGCP
is in clear text by default.
162
H.323 gateway with certificates exchanged with CUCM for SRTP and IPsec for protecting signaling.
SIP gateway with secure SIP trunk leveraging TLS to protect signaling.
Figure 5-6 gives insight to TLS signaling and SRTP media flow among CUCM, endpoints,
and gateways.
Voice Gateway
CUCM
Secure SIP
Trunk, IPsec for
MGCP/H.323
SCCPS or SIPS
(TLS Signaling)
IP Phone A
Figure 5-6
SRTP (Media)
SRTP (Media)
IP Phone B
TLS and SRTP Call Flow Between CUCM, Endpoints, and Gateways
Table 5-2
163
Description
Time-of-Day routing
Used to control the access to international and long distance calls. FAC/CMC forces a user to enter a predetermined code to proceed with a call hitting a route pattern
that has FAC enabled. Both FAC- and CMC-processed
calls are logged to CUCM Call Detail Records (CDR).
Ad hoc conference calls can be dropped when the originator hangs up. This is achieved by setting the Drop Ad
Hoc Conference service parameter to When Conference
Controller Leaves under Clusterwide Parameters
(Features-General) area. This ensures that the other
parties (such as external users) cannot initiate a call to
another external number.
Route filters
005_9780133845969_ch05.indd 163
6/25/14 11:07 AM
164
By virtue of this feature, the router automatically adds the destination IP address(es)
defined as an IPv4 target in a VoIP dial peer to the trusted source list. This feature is configurable via the global voice service voip command:
UCRouter(config)# voice service voip
UCRouter(conf-voi-serv)# ip address trusted authenticate
165
Create a non-default call-restriction rule for calls and call transfers that denies everything starting with the outside (PSTN) access code; for example, deny 9* transfers
from Cisco Unity Connection to PSTN in the United States and 0* in Europe.
Add restriction table patterns to match appropriate trunk access codes for all phone
system integrations.
Restrict the numbers that can be used for system transfers and for Audio Messaging
Interchange Specification (AMIS) message delivery.
Chapter 6
168
Firewalls must not block the required ports. For a list of all ports required by CUC
9.1, refer to www.cisco.com/en/US/docs/voice_ip_comm/connection/9x/security/
guide/9xcucsec010.html.
Depending on the number of voice messaging ports on each CUC server, guaranteed
bandwidth must be available at all times with no steady-state congestion:
CUCM
Cluster
Cisco
Unified
CME
CUC
Cluster
WAN
CUCM
Cluster
Cisco
Unified
CME
Figure 6-1
CUCME
CUC SCCP Voicemail and SIP Voicemail Integration with CUCM and
169
Step 2.
Step 3.
On the Cisco Voice Mail Ports page, define the number of ports to be added
(should match the licensed number of ports on CUC) and click Next.
Step 4.
On the Cisco Voice Mail Device Information page, fill in the fields such as
Description, Device Pool, Calling Search Space, Location, Device Security
Mode (must match with CUC port security mode), and Use Trusted Relay
Point related information. Click Next.
Step 5.
On the Cisco Voice Mail Directory Numbers page, configure the directory
number (DN) details such as Beginning Directory Number, Partition, Calling
Search Space, AAR Group, Internal Caller ID Display, Internal Caller ID
Display (ASCII Format), and External Number Mask. Each DN will increment
based upon the number of ports defined earlier. Click Next.
Step 6.
On next wizard page, select the option Yes. Add directory numbers to a new
Line Group and click Next.
Step 7.
On the Line Group page, define the name of the line group. Click Next.
Step 8.
Review the Confirmation page and ensure that all settings are as expected.
Click Finish. Figure 6-2 represents the Confirmation page with VM Port
Wizard settings.
170
Navigate to Advanced Features > Voice Mail > Message Waiting and click
Add New. Enter a number in the Message Waiting Number field, and then
click the On radio button for the Message Waiting Indicator option. Click
Save, and then click Add New. Enter a second number and select the Off
radio button. Click Save.
Step 10. Go to Advanced Features > Voice Mail > Voice Mail Pilot and click Add
New. Enter a number in the Voice Mail Pilot Number field and provide the
required details. Click Save.
Step 11. Navigate to Advanced Features > Voice Mail > Voice Mail Profile and click
Add New. Provide a Voice Mail Profile Name and other required details.
Select the Voice Mail Pilot configured in Step 10. Provide the Voice Mail Box
Mask per your organizations requirements, and optionally check the check
box to make the Voice Mail Profile the default for the system (useful when
you have only one CUC system integrated with CUCM).
Step 12. Go to Call Routing > Route/Hunt > Hunt List and click Add New. Provide
the required details. Ensure that the Enable This Hunt List and For Voice
Mail Usage check boxes are checked. Assign the Line Group created earlier
(during the Voice Mail Port Wizard) to this Hunt List.
Step 13. Navigate to Call Routing > Route/Hunt > Hunt Pilot and click Add New.
Enter the Hunt Pilot Number (should match the Voice Mail Pilot Number) and
provide other required details. Select the Hunt List configured earlier.
Step 14. Go to the Cisco Unity Connection Administration page, choose Telephony
Integrations > Phone System, and click Add New. Provide a name for the
Phone System and define other required parameters.
006_9780133845969_ch06.indd 170
6/25/14 11:11 AM
171
Step 15. Choose Telephony Integrations > Port Group and click Add New. Ensure
that the phone system defined in Step 14 is chosen and select the method
of integration as SCCP. Provide other required parameters. Ensure that the
Device Name Prefix matches the one configured in CUCM, that the MWI On
and Off extensions also correspond, and define the primary CUCM server
address. (You can add a secondary CUCM server address by clicking Edit and
adding it.) Its important to note that the primary and backup CUCM addresses must match the order in which they are defined in the CUCM Group
assigned to the device pool used for voicemail ports.
Step 16. Choose Telephony Integrations > Port and click Add New. Define the number of ports (must match the number of SCCP ports configured in CUCM),
select the phone system and port group defined earlier, and choose a CUC
server (if using a CUC cluster, choose between publisher and subscriber).
Under Port Behavior, define the port behavior by checking the corresponding
check boxes that apply: Answer Calls, Perform Message Notification, Send
MWI Requests, or Allow TRAP Connections. (This can be changed later when
ports are added to CUC; the leading practice is to have 80 percent of ports
reserved for CUC incoming calls and 20 percent of ports reserved for outcalling such as MWI, notifications, and TRAP.)
At this time, the CUC SCCP voicemail integration with CUCM is complete. A user can
press the Message button on an IP Phone (or call the VM pilot from an analog endpoint)
to access voice mail.
Step 2.
Navigate to Device > Trunk and click Add New. Add a SIP trunk (as
explained in Chapter 4, Cisco Unified Communications Manager) without
any service type. Provide the required details such as trunk name, device
pool, destination (CUC) IP address, SIP trunk security profile (defined in Step
1), and so on. For integration with a CUC cluster, configure two SIP trunks,
with the first SIP trunk pointing to the CUC subscriber, followed by the second SIP trunk pointing to the CUC publisher (the leading practice recommendation is to send traffic to the CUC subscriber followed by the publisher).
172
Step 3.
Go to Call Routing > Route/Hunt > Route Pattern and click Add New. Add
a route pattern pointing to the CUC Voicemail SIP Trunk configured in Step
2. Make sure that the DN of the route pattern matches the voicemail pilot
number and that any PSTN-relevant settings are disregarded, such as outside
dial tone, off-net classification, FAC, CMC, and so on. If using multiple SIP
trunks to the CUC subscriber and publisher, add a route group, with the two
trunks assigned to it, followed by a route list, and assign the route list to the
route pattern (see Chapter 4 for detailed information on route groups and
route lists).
Step 4.
Add a new Voice Mail Pilot by browsing to Advanced Features > Voice Mail
> Voice Mail Pilot as described in the preceding section on SCCP voicemail
integration. For CUC configuration, follow the steps described in that section, with the exception that, instead of defining the Port Group as SCCP,
define it as SIP. The next two sections cover CUC integration with CUCME.
173
!
CMERouter(config)# ephone-dn 22
CMERouter(config-ephone-dn)# number 7000
CMERouter(config-ephone-dn)# name "VM-Port 3"
CMERouter(config-ephone-dn)# preference 2
CMERouter(config-ephone-dn)# no huntstop
!
CMERouter(config)# ephone-dn 23
CMERouter(config)# number 7000
CMERouter(config-ephone-dn)# name "VM-Port 4"
CMERouter(config-ephone-dn)# preference 3
CMERouter(config-ephone-dn)# huntstop
!
CMERouter(config)# ephone 20
CMERouter(config-ephone)# vm-device-id CMEVM-VI1
CMERouter(config-ephone)# button 1:20
!
CMERouter(config)# ephone 21
CMERouter(config-ephone)# vm-device-id CMEVM-VI2
CMERouter(config-ephone)# button 1:21
!
CMERouter(config)# ephone 22
CMERouter(config-ephone)# vm-device-id CMEVM-VI3
CMERouter(config-ephone)# button 1:22
!
CMERouter(config)# ephone 23
CMERouter(config-ephone)# vm-device-id CMEVM-VI4
CMERouter(config-ephone)# button 1:23
!
CMERouter(config)# ephone-dn 101
CMERouter(config-ephone-dn)# number 7799
CMERouter(config-ephone-dn)# call-forward busy 7700
CMERouter(config-ephone-dn)# call-forward noan 7700 timeout 10
!
CMERouter(config)# ephone 101
CMERouter(config-ephone)# button 1:101
CMERouter(config-ephone)# type 7965
CMERouter(config-ephone)# mac-address 00C3.CF99.B188
!
CMERouter(config)# dial-peer voice 100 voip
CMERouter(config-dial-peer)# destination-pattern 7000
CMERouter(config-dial-peer)# session target ipv4:10.76.108.244
CMERouter(config-dial-peer)# dtmf-relay h245-alphanumeric
CMERouter(config-dial-peer)# codec g711ulaw
!
174
175
CMERouter(config)# sip-ua
CMERouter(config-sip-ua)# mwi-server 10.76.108.244 unsolicited
In Example 6-2, the dial peers point to the CUC subscriber and publisher, respectively,
with the voicemail number as destination-pattern. The max-conn <> command specifies
the number of voicemail ports on each server.
Contacts
Distribution lists
Users
Partitions define who or what can be reached, search spaces (equivalent to CUCM CSS),
and define by whom or what partitions are reachable.
Search spaces can be assigned to any object that can initiate a call or a user that can
address a message to another user or entity. Partitions can be assigned to various search
spaces to ensure that the call restrictions are in place for system entities and subscribers
(users). The following objects can be assigned to a search space:
Routing rules
Users
176
Call Handlers
Call handlers, as the name suggests, are call flow instructions that handle incoming calls
to CUC. These instructions can range from offering a caller a menu of options from
which to select (Auto Attendant), enabling the caller to locate a CUC subscriber (directory user), or presenting information. Call handlers allow users to leverage self-service
(IVR-like call flow) and perform other functions as discussed in this section.
Call handlers can be broadly classified as follows:
Directory handlers
Interview handlers
Opening Greeting: Plays the standard system opening greeting announcement. The
caller is presented with a number of options after the opening greeting, enabling the
caller to select a users (subscribers) extension, the system directory, or the operator.
In case a caller does not make a selection, the caller is directed to the operator.
Goodbye: Plays a goodbye announcement, after which it disconnects the call. This
call handler is invoked by default when a user has finished recording a message via
the Operator call handler.
Figure 6-3 shows the default system call handlers available with CUC.
Figure 6-3
Call Handlers
177
The default system call handlers cannot be deleted, but they can be modified as required.
Table 6-1 lists the available options that can be used to modify any system call handler.
Table 6-1
Description
Transfer Rules
Caller Input
Greetings
System call handlers can be configured with various greetings such as:
Standard greetings
Message Settings
By default, only users that have a role of system administrator can create or modify call handler greetings. This role can
be delegated to another user by defining the user as a call
handler owner such that the user is able to record the greetings using Greeting Administrator.
178
To configure a new system call handler, browse to Call Management > System Call
Handlers > Add New. You can create call handlers that leverage the same functionality
by configuring a call handler template (Templates > Call Handler Templates) to allow
new call handlers to apply a desired/similar set of configuration in terms of Transfer
Rules, Caller Input, Greetings, Message Settings, and Post Greeting Recording.
Figure 6-4
Caller Input: Allows a caller to provide input and accordingly route the call to a
users extension, a call handler, another directory handler, or a conversation. If a
caller doesnt provide any input, the previously stated actions can be repeated or the
caller can be sent to the Goodbye call handler. Finally, if a caller presses 0, the caller
is transferred to an operator.
Call Handlers
179
Greeting: Can be recorded as an opening prompt for a directory handler. If no greeting is recorded, the system directory handler uses a default greeting that prompts the
users input.
Figure 6-5
180
response can be marked as urgent or normal, or a caller can choose from either
of these. The after-interview action can be set to send the caller to an extension, a
voicemail box, a directory handler, another interview handler, a call handler, or a
conversation.
Dual message stores with message synchronization (between CUC and Exchange)
Voice
Messages
Message
Synchronization
Email
Messages
Figure 6-6
Microsoft Exchange
Server
Microsoft Outlook
Client
When configured for single inbox, CUC doesnt synchronize the following messages:
Sent messages
Draft messages
Broadcast messages
181
Note To access voice messages from within the Outlook client, ViewMail for Outlook
(VMO) is required. VMO is a CUC plug-in that you can download from
http://software.cisco.com/download/release.html?mdfid=284532811&flowid=
45679&softwareid=282074348&release=VMO%209.0%282%29&relind=
AVAILABLE&rellifecycle=&reltype=latest.
If users want to use Outlook to send, reply to, or forward CUC voice messages, the
VMO client must be installed on user workstations. Without VMO installed, voice messages are sent by Outlook as emails with .wav file attachments, and are treated as emails
by CUC. If VMO is not installed, when a user replies to or forwards a voice message, the
reply or forward is also treated like an email and hence the message is never sent to the
CUC mailbox (as email routing is handled by Exchange). Moreover, without VMO, users
cannot listen to secure voice messages and must play them via TUI.
CUC synchronizes voice messages between Outlook folders and the CUC inbox folder
for a user as follows:
Messages in Outlook and CUC deleted items folders are synced. So, if a user moves voice
messages (except secure voice messages) into Outlook folders that are not synced with
the CUC inbox folder, the messages are moved to the deleted items folder in CUC. On
the same note, CUC does not sync secure messages with Exchange; instead, it replicates a
decoy message that briefly describes a secure message. When a user plays a secure message employing VMO, the secure message is retrieved from the CUC server and is played
without ever storing the message anywhere else (Exchange or user PC). For secure messages, the same rules apply as with non-secure messages for CUC inbox to Outlook sync.
Before CUC Single Inbox (Unified Messaging) can be configured on CUC, the CUC
administrator must know the following parameters:
182
Moreover, if Secure Sockets Layer (SSL) is required for connectivity between Exchange
and CUC, Exchange certificates must be uploaded into the CUC server(s) Tomcat certificate store.
Assuming the parameters are known, follow these steps in Cisco Unified Connection
Administration to configure CUC Unified Messaging:
Step 1.
Choose Class of Service > Class of Service and ensure that the Allow Users
to Access Voice Mail Using an IMAP Client and/or Single Inbox check box
is checked for Voice Mail User CoS. Also, if you plan to use TTS, check the
check boxes labeled Allow Access to Advanced Features and Allow Access
to Exchange Email by Using Text to Speech (TTS).
Step 2.
Navigate to System Settings > SMTP Configuration > Smart Host and click
Add New. Add a SMART SMTP server that will relay messages between CUC
and other servers (including Exchange).
Step 3.
Figure 6-7
Step 4.
Figure 6-8
183
Ensure that all phones have Web Access set to Enabled. You can accomplish
this either via BAT, by browsing to Cisco Unified CM Administration >
System > Enterprise Phone Configuration, or by setting the Common Phone
Profile Configuration by browsing to Device > Device Settings > Common
Phone Profile.
Step 2.
Create a new Voice Mail Pilot in addition to the standard Voice Mail Pilot.
Provide a unique pilot number (different from that of the regular Voice Mail
Pilot) and other required parameters.
184
Step 3.
Create a new Hunt Pilot specifically for Visual Voicemail. Point it to an existing Hunt List used for regular voice mail.
Step 4.
Go to Device > Device Settings > Phone Services and click Add New. Add
a new service with the name Visual Voicemail and with the service URL as
http://<IP address of CUC>/midlets/VisualVoicemail/VisualVoicemail.jad.
Select Java MIDlet for the Service Category, select Messages for the Service
Type, set Service Vendor to Cisco Systems, Inc., and check the Enable check
box. Set Visual Voicemail Service Parameters with the following:
Create a new parameter log_level with a display name of Log Level, set
the default value to info, and enter a description of Level of logging.
Step 6.
Figure 6-9
Figure 6-10
185
Step 2.
Go to User Management > User Settings > UC Service. Click Add New.
Select the UC Service Type MailStore. Click Next. Enter the required details
for the Exchange server such as Name, Host Name/IP Address/FQDN, Port,
and Protocol. Click Save.
Step 3.
Navigate to User Management > User Settings > Service Profile. Click Add
New. Enter service profile name as Jabber. Check the check box to make this
profile the default profile. Under Voicemail Profile, select the Voicemail UC
186
Service you configured earlier, and make sure that the Credentials Source for
Voicemail Service field is set to Unified CM - IM and Presence, as shown in
Figure 6-11. Under MailStore Profile, select the MailStore UC Service you
configured earlier and ensure that the Allow Dual Folder Mode check box is
checked, also shown in Figure 6-11.
Figure 6-11
Step 4.
Intrasite networking: Networking with other CUC servers/clusters within the same
connection site
Voice Profile for Internet Email (VPIM) networking: Networking with voice messaging platforms such as Cisco Unity Express and third-party voicemail systems
187
Intrasite Networking
Intrasite networking enables you to reach out to other (physical/logical) locations and
enables the administrator to network a CUC cluster or server with other CUC servers/
clusters. This enables an enterprise to increase the total number of users that can be provisioned within the enterprise. CUC supports intrasite networking with other CUC clusters/servers and allows expanding the number of voicemail users beyond the maximum
20,000 up to 200,000 (with the number of global directory users and contacts limited to
100,000). A maximum of ten CUC servers/clusters can be joined together to form a single
voice messaging network. This network is referred to as a connection site, and each
server/cluster participating in a connection site is known as a location. The links between
locations are known as intrasite links. SMTP is used for communication within a site.
Intrasite networking supports the replication of the following within a connection site:
Users
Partitions
Search spaces
Locations
188
CUC Cluster
(Location)
Intrasite Links
CUC Cluster
CUC Cluster
(Location)
(Location)
Figure 6-12
CUC Server
CUC Server
(Location)
(Location)
Intersite Networking
Two connection sites can be linked together using an intersite link to form an intersite
network, as illustrated in Figure 6-13. An intersite network allows increasing the number
CUC servers/clusters to up to 20 servers/clusters to form a voicemail organization.
There can be only a single intersite link between sites participating in intersite networking. A single location from each site acts as a gateway to the other site, and these gateways use HTTP or HTTPS to exchange directory synchronization updates and use SMTP
for voice messages exchange. Similar to intrasite networking, intersite networking also
supports users, system distribution lists, partitions, search spaces, and locations replication between two sites.
To configure intersite links, go to Networking > Links > Intersite Links and provide
required details such as automatic or manual link information, transfer protocol, synchronization settings and tasks, and intersite SMTP routing.
189
Directory Exchange
HTTP/HTTPS
Message
Exchange
SMTP Server
Connection Site
Figure 6-13
SMTP Server
Connection Site
Chapter 7
Cisco Unied Instant Messaging (IM) and Presence is now better known as Cisco Unied
Communications Manager IM and Presence (Cisco Unied CM IM and Presence).
This is due to the integration of Cisco Unied Presence technology with Cisco Unied
Communications Manager for Release 9.0 and later. Cisco Unied CM IM and Presence
offers presence, IM, group chat, desk-phone control, and many other enterprise-grade
features.
Cisco Jabber (Extensible Messaging and Presence Protocol [XMPP] soft client)
192
Third-party applications
Figure 7-1 gives an overview of the Cisco Unified CM IM and Presence architecture and
relationship with different components.
Cisco
MeetingPlace
Video
Phone
SIP
SIMPLE
IBM
Sametime
XMPP
Video Client
On PC
XMPP
CUCM
CTI/SIP/DB
SIP
SIMPLE
Jabber
Client
SIP
SIMPLE
XMPP
SIP
SIMPLE
Cisco Unified
IP Phone
Microsoft
Lync
Figure 7-1
Cisco CM IM
and Presence
XMPP
Google
Talk
Cisco Unity
Connection
LDAP
LDAP
XMPP/SIP
SIMPLE
Third-Party
API
193
DB Sync
2A
IDS
IDS
1B
CUCM Cluster
Subcluster 1
Figure 7-2
3A
2B
Subcluster 2
3B
Subcluster 3
194
Step 2.
Step 3.
Step 4.
Step 5.
Go to User Management > User Settings > UC Service. Click Add New.
Select the UC Service Type IM and Presence. Click Next. In the Product
Type field, enter Unified CM (IM and Presence) and enter other required
parameters as shown in Figure 7-3.
Figure 7-3
Step 6.
Go to User Management > User Settings > UC Service, click Add New, and
select the UC Service Type CTI. Click Next. Enter the required details for
CTI Manager (CUCM server running CTI service).
Step 7.
Go to User Management > User Settings > UC Service, click Add New, and
select the UC Service Type Voicemail. Click Next. Enter the required details
for the Cisco Unity Connection server (voice messaging server).
Step 8.
Go to User Management > User Settings > UC Service, click Add New, and
select the UC Service Type Directory. Click Next. Enter the required details
for the LDAP server (the organizations LDAP server; for example, Microsoft
Active Directory).
Step 9.
Navigate to User Management > User Settings > Service Profile. Click Add
New. Enter the service profile name as Jabber and enter a meaningful description such as Jabber Service Profile. Check the check box to make this profile
the default profile. Under Voicemail Profile, select the one you configured
earlier, followed by directory profile, IM and Presence profile, and CTI profile. For LDAP, enter the required details such as username, password, search
base, and so on as shown in Figure 7-4.
Figure 7-4
195
196
the CUCM subscribers that have access to the Cisco CM Unified IM and
Presence server trunk. Figure 7-6 depicts CCMCIP profile configuration.
Figure 7-5
Figure 7-6
Cisco Jabber
197
The integration of CUCM and the Cisco CM Unified IM and Presence server is complete. You can now begin configuring users for IM and Presence.
Cisco Jabber
Cisco Jabber is an XMPP-based client-server architecture based on the open XML
protocol. Its deployment is available in two flavors: on-premises and cloud-based. The
Cisco Jabber client supports various platforms, including PC, Mac, iOS, Android, and
BlackBerry OS. The design of the client is such that it enables an all-in-one communication tool, giving end users features and functionality such as voice, video, desktop sharing, calendar management, and so on.
The Jabber client supports the following features/services:
Presence and IM
Video
Voice messaging
Click-to-call features
198
Cisco Jabber
IM and Presence
Contact Management
File Transfer
XMPP
IP Phone
Control
Cisco
Figure 7-7
Cisco IM
and Presence
Visual
Voicemail
Directory Search
Authentication
Telephony
Presence
Cisco WebEx
Directory
Search
CUCM
LDAP
Cisco Unity
Connection
Jabber Architecture
As previously mentioned, Jabber can be deployed in two major deployment models, onpremises and cloud/hybrid. The various options for each model are as follows:
Soft Phone Mode: Audio uses sound devices on a workstation. Video is displayed
on a workstation; audio is via headset or PC speakers.
Desk Phone Mode: The Jabber client controls the Cisco IP Phone to make and
receive calls. Video phone control is supported.
Cisco Extend and Connect: Jabber extends the call to a remote destination that
enables the user to work from any location on any device.
Jabber for Windows supports Binary Floor Control Protocol (BFCP) for desktop sharing. BFCP encodes a video stream of the senders desktop in addition to a camera video
stream. Video desktop sharing can link Jabber client and Cisco video endpoints.
Presence Federation
Federation facilitates IM and Presence collaboration between a Cisco Unified CM IM
and Presence server and a third-party vendor. This allows IM and Presence information
Presence Federation
199
sharing not only within an organization but also between two (or more) organizations.
Federation can be classified into two broad categories:
Intradomain federation
Interdomain federation
Moreover, federation(s) can be based on a number of parameters. For example, a federation can be SIP based or XMPP based, can leverage TCP or TLS, and so on.
Intradomain Federation
Intradomain federation is the sharing of presence information and exchange of IM
between systems within the same domain. Intradomain federation can be SIP federation
between Cisco Unified CM IM and Presence and Microsoft Lync Server 2010, Microsoft
Office Communications Server (OCS) 2007 R1/R2, or Microsoft Live Communications
Server (LCS) 2005. In other words, an intradomain federation allows for communications
between other Cisco Jabber or Microsoft-based domains within an enterprise using SIP.
Figure 7-8 illustrates intradomain SIP federation between a Cisco Unified CM IM and
Presence server/cluster and a Microsoft Lync/OCS/LCS server.
CUCM Cluster
Enterprise Domain
DomainA.com
Microsoft Lync/
OCS/LCS Client
Cisco Jabber
Client
LDAP
SIP
Cisco Unified IM and
Presence Cluster
Figure 7-8
Microsoft Lync/OCS/
LCS Server
As shown in Figure 7-8, within a domain, the Cisco Unified CM IM and Presence server
and the Microsoft Lync/OCS/LCS server leverage the same corporate directory. Hence,
a user can exist either in Cisco Unified CM IM and Presence or in Microsoft Lync/OCS/
LCS, but not in both. For the Cisco Unified CM IM and Presence server, the Jabber ID is
in the form of sAMAccountName@domain. For Microsoft Lync/OCS/LCS, the SIP URI
can be in the form sAMAccountName@domain, First.Last@domain, or email address(es).
200
Step 2.
Step 3.
Go to System > Security to configure the incoming ACL and outgoing ACL
to allow incoming and outgoing address patterns from/to Lync/OCS/LCS. If
you do not know the address patterns, set it to All.
Step 4.
Go to System > Application Listeners and ensure that Default Cisco SIP
Proxy TLS Listener - Peer Auth is configured to use port 5061.
Step 5.
Proceed to System > Security > TLS Peer Subjects and add the Lync server
as a peer with FQDN.
Step 6.
Navigate to System > Security > TLS Context Configuration and ensure
that Disable Empty TLS Fragments is checked. Move TLS Peer Subject (created in Step 5) to Selected TLS Peer Subjects.
Step 7.
Step 8.
Step 9.
Under Peer Server Status, you can validate SSL connectivity with Lync (assuming the latter is configured for intradomain federation with CA signed certificates).
The following are some considerations while implementing intradomain federation:
User can only exist in either Cisco Unified CM IM and Presence or OCS/LCS, but
not both.
If the Lync/OCS/LCS SIP URI does not match the sAMAccountName@ domain format, it is recommended to use the Jabber XML file.
Presence Federation
Domain Name System (DNS) A records must be published within the enterprise for
all Cisco Unified CM IM and Presence and Lync/OCS/LCS servers.
Partitioned Intradomain Federation with Microsoft Lync is supported only with TLS.
If TLS is required, use of the same CA to sign Lync/OCS/LCS and Cisco Unified
CM IM and Presence certificates is recommended.
201
Interdomain Federation
Interdomain federation enables business-to-business (B2B) and business-to-consumer
(B2C) collaboration between independent organizations, thereby providing IM and
Presence capabilities. Interdomain federation can also occur between two domains
within an enterprise. Interdomain federation can exist between Cisco Unified CM IM and
Presence and Lync/OCS/LCS over SIP or between Cisco Unified CM IM and Presence
and an XMPP server (for example, IBM Sametime or Google Talk). Cisco Unified CM IM
and Presence to Lync/OCS/LCS and to IBM Sametime is an example of B2B federation,
whereas Cisco Unified CM IM and Presence to Google Talk or to AOL interdomain federation is an example of B2C federation.
Figure 7-9 illustrates interdomain SIP federation between a Cisco Unified CM IM and
Presence server/cluster and a Microsoft Lync/OCS/LCS server.
Enterprise B
DomainB.com
Enterprise A
DomainA.com
Inside (Private)
DMZ
DMZ
Inside (Private)
Microsoft Lync/
OCS/LCS Server
SIP
Cisco
ASA
Cisco Jabber
Client
Figure 7-9
Microsoft
Edge
Microsoft Lync/
OCS/LCS Client
202
You can optionally check the Direct Federation check box if Cisco ASA is not being
used for interdomain federation.
Figure 7-10 illustrates interdomain XMPP federation between a Cisco Unified CM IM
and Presence server/cluster and a third-party XMPP-compatible server.
Enterprise A
DomainA.com
Enterprise B
DomainB.com
Inside (Private)
Inside (Private)
XMPP Server
XMPP
Cisco
ASA
XMPP Client
(Google Talk,
IBM Sametime)
Cisco Jabber
Client
Figure 7-10
XMPP
Gateway
XMPP IM service
Directory
IM archiving
XMPP federation
WebEx
Administrator
203
Inter-Domain
Federation
HTTPS
Cisco
WebEx
XMPP
XMPP
XMPP
Contacts
TLS/SSL
(XMPP)
CUCM
SIP (Softphone)/HTTPS
LDAP
(Directory)
TLS
CTI (Desk Phone)/HTTPS
Cisco Jabber
Clients
IMAP (Visual Voicemail)
Cisco Unity
Connection
IM Archiving
Figure 7-11
On the phone status from the client framework (Jabber client framework)
Chat history
A user can be logged in to Jabber on more than one device. When an IM is sent, it
will fork to all the logged-in devices. Whichever Jabber responds, that device continues with the chat transmission.
204
Contacts are stored in a cloud database (including corporate and federated contacts)
and contact searches are performed in the cloud database.
Ad hoc desktop sharing is available in cloud mode by default. The sharing session is
hosted in the cloud.
Group Chat
When multiple people need to have a chat conversation simultaneously, a group chat can
be established. Group chat can be either an ad hoc chat (temporary group chat) initiated
by a user when required or a permanent group chat.
A temporary group chat doesnt require any special configuration. A permanent chat
room, however, requires an external database such as PostgreSQL. PostgreSQL can be
used for compliance features as well, as covered in the next section. The major difference is that for permanent group chat, each Cisco Unified CM IM and Presence server
in a cluster requires a unique logical database, whereas for compliance, only one external
database server is required (with support for more than one server).
Ad hoc chat rooms remain in existence only as long as one person is still connected to
the chat room. In contrast to ad hoc chat rooms, permanent chat rooms are group chat
sessions that remain in existence even when all users have left the room, enabling users to
return to persistent chat rooms over time to collaborate and participate in the discussion
of a topic in real time.
To initiate a group chat from within your Jabber client, follow these steps:
Step 1.
Click the Add Participants button in the lower right corner of the window.
Step 2.
Type the name of the additional participant. Jabber searches in your contact
list first, then in the corporate directory. Select the additional group member
and click Add.
Step 3.
When you add members, the members appear on the right side of the chat
window, and the group chat icon appears on the left.
205
Group chat can be set to persistent chat where all messages among the users are
archived. This is accomplished by going to Cisco Unified CM IM and Presence
Administration > Messaging > Group Chat and Persistent Chat. For more information
on message logging and external databases, refer to the next section on logging and
compliance.
IM history (client side): Refers to logging of an IM going to and from a Jabber client
The capability of Jabber to log IMs on the client side is controlled via a policy setting
on the system backend (either CUP or WebEx Messenger) depending on which system
an organization has deployed. For on-premises deployment, it is enabled at a global level,
which means it can be either turned on or turned off for the entire organization. For
WebEx Messenger (cloud based), it can be set at the group level or at a global level. The
policy setting for on-premises deployment is set up by browsing to Cisco Unified CM
IM and Presence Administration > Messaging > Settings, as shown in Figure 7-12.
Client-side IM logging is also available in WebEx Messenger and can be enabled or disabled in policy settings as Local Archive. By default, this value is set to TRUE.
206
Figure 7-12
Figure 7-13
After an external database or third-party server has been configured, it can be assigned
as a Message Archiver or a Compliance Server by browsing to Cisco Unified CM IM
and Presence Administration > Messaging > Compliance.
207
In the case of WebEx Messenger compliance, an end user always sees a disclaimer notice:
All instant messages sent in this session to and from this account, as well as the initiation and termination of any other communication modes (e.g. voice call, video call)
will be logged and are subject to archival, monitoring, or review and/or disclosure to
someone other than the recipient. If both participants are logged users, the disclaimer
notice appears once for each user. The same holds true for group chat; each participant
generates their own disclaimer and publishes it to the chat.
Customers archiving endpoints such as compliance servers need to be entered into the
Cisco WebEx Administration tool. The following parameters are required:
Endpoint name
Endpoint type
After endpoints have been configured, users must be assigned for logging by creating users, employing CSV files, directory integration, or Security Assertion Markup
Language (SAML).
Chapter 8
CUCM
Cluster
Cluster View
Daemon
Datastores
CC
CC
Administration
Secondary
UC Manager
Engine
Primary
Cisco Agent
Desktop (CAD)
CTI Manager
CAD Client
Cisco Unified IP
Phone
Figure 8-1
Cisco Voice
Gateway
210
As shown in Figure 8-1, the UCCX server/cluster is the core of the solution, providing
IVR treatment to incoming calls, queuing calls, and delivering calls to the appropriately
skilled agents. Cisco Agent Desktop (CAD) is client software that runs on an agent PC
used in conjunction with a Cisco Unified IP Phone. This allows agents to handle calls
while monitoring the data associated with that call (such as customer name, account
number, and so on). The CUCM cluster provides call-control functionality to UCCX. The
Engine on the UCCX server has a Java Telephony API (JTAPI) client and uses the JTAPI
protocol to connect to the CTI Manager on CUCM. It is able to monitor and control
devices such as agent IP Phones. The UCCX Administration module interacts with UC
Manager on CUCM while creating CTI devices such as triggers and CTI ports on UCCX,
and the Administration process interacts with the CUCM database to create these
devices on CUCM. The voice gateway (which can be MGCP, H.323, or SIP) is managed
by CUCM for all the communication for call setup and teardown. The only exception to
this is the IVR Outbound Dialer, in which case UCCX communicates directly with a SIP
gateway.
UCCX Engine: The UCCX Engine processes and executes applications using the
functionality of the following subsystems:
Script execution
Agent Data Store (ADS): Composed of statistics, logs, and pointers to recordings
Historical Data Store (HDS): Contains Contact Call Detail Records (CCDR)
211
Recording: Allows agent calls to be recorded by the supervisor. If desktop monitoring is being used, CAD sends the RTP streams to the recording component, and
if SPAN port monitoring is employed, the monitoring component sends the RTP
streams to the recording component.
In addition to the listed components, the Cluster View Daemon component is relevant
when a UCCX cluster is installed. It monitors the status of the local services on the other
node in the cluster. It is also responsible for dynamically electing components as master
or standby during failover scenarios.
Functionality
Description
(Basic/Advanced)
Basic
Basic
Basic
212
Functionality
Description
(Basic/Advanced)
Supervisor Desktop
Basic
Basic
Queue Prioritization
Advanced
Advanced
Advanced
Advanced
Outbound Campaigns
Advanced
Advanced
213
Functionality
Description
Enterprise Data
Window in CAD or
IP Phone
Basic
Consists of enterprise data, or data that is connected to the call, being visible on the computer
or phone screen of the agent who is accepting
the call. This data includes information about the
caller and statistics about the call itself.
Enables third-party app integration and automatically populates the information (agent display
data) in other applications.
Advanced
Embedded Web
Browser Integration
Advanced
IVR Function
Functionality
Description
Basic
Collects digits from the caller for account numbers and menu choices.
Basic Call-Control
Basic
Basic
214
IVR Function
Functionality
Description
Database (ODBC)
Integration to Selected
DBMS
Advanced
Connects to external databases for detailed caller information and account transactions.
Outbound Email
Generation
Advanced
Advanced
Advanced
Advanced
Two-server (cluster) model: The most common deployment model that provides
high availability within a data center and can also be split across a WAN (clustering
over WAN).
With local site (LAN) deployment, typically both UCCX servers would be local to the
primary and secondary CUCM servers; thus, they share the same primary and secondary
CUCM server configuration.
For cluster over WAN deployment, usually the local CUCM is different for each UCCX
server, so they need to be configured with a different primary and secondary CUCM
provider server. This reduces traffic over the WAN and ensures that failover works properly. Also, recording monitored calls is load balanced between the two nodes. The actual
215
recording is stored on the node that records the call. However, it is not replicated to the
other server.
PSTN
UCCX
Cluster
(5)
(1)
(4)
CC
CUCM
Cluster
(3)
CC
(2)
Voice
Gateway
(7)
Voice-Enabled
Switch
(6)
Figure 8-2
The PSTN (POTS/SIP) caller dials the number (possibly a toll-free number),
and the call is routed by the service provider to the voice gateway.
216
Step 2.
The voice gateway routes the call to a call-control agent; for example, CUCM
using MGCP, H.323, or SIP.
Step 3.
Step 4.
Upon receiving the request from CUCM, UCCX selects a CTI port and
responds back to CUCM with the directory number/extension so that CUCM
can send a setup message to UCCX corresponding to a specific script/trigger.
The call is answered by the script, and an RTP stream is established between
the designated CTI port on UCCX and the voice gateway.
Step 5.
If the script allows for auto-service menu, the user is prompted for data
(DTMF input) and given the required level of service. A script may also lead
to a caller connecting to an agent, in which case the call is queued in the
Contact Service Queue (CSQ) until an agent becomes available.
Step 6.
When an agent logs in or concludes the previous call, UCCX reserves the
agent and initiates a call transfer to that agents IP Phones extension. CUCM
rings the agents IP Phone and consequently UCCX may signal a CTI screen
pop (CAD) on the agents desktop with call-related information (from the
external user information database).
Step 7.
When the agent answers the call, the call transfer is completed and an RTP
stream is established between the agents IP Phone and the voice gateway.
Step 2.
In the Cisco Unified CM Configuration - Service Provider Configuration window, enter the CUCM IP address/hostname and the AXL Admin User Name
and Password. Click Next.
Step 3.
Enter the required license information by uploading the license file to UCCX.
Click Next.
Step 4.
In the next window, the Component Activation window, ensure all required
components are activated and click Next.
Step 5.
In the Publisher Activation window, select required data stores and click Next.
Step 6.
Figure 8-3
217
Step 7.
Step 8.
In the User Configuration window, select the CUCM users that require
administrative rights on the UCCX server.
Step 9.
Log in to the UCCX server with the username and password defined in Step
8. Go to Subsystems > Cisco Unified CM Telephony > Call Control Group.
Click Add New and provide the required details as shown in Figure 8-4.
Click Add. This creates CTI ports on the CUCM server/cluster with provided
parameters.
At this time, the UCCX integration with CUCM is complete, including the AXL, CTI,
and RMCM subsystems and the creation of CTI ports on CUCM. However, the UCCX
administrator still needs to configure the following:
Skills
Additionally, the UCCX administrator must create scripts and applications to handle
incoming calls from CUCM to UCCX and provide IVR/agent transfer functionality.
218
Figure 8-4
UCCX scripting is accomplished in UCCX Cisco Unified CCX Editor. There are different
panes within Unified CCX Editor that offer various functions, as shown in Figure 8-5.
The toolbar at the top of Figure 8-5 offers various options such as create a script, save
a script, and open a script. The window on the left offers numerous palettes that can be
used to construct or modify a UCCX script. The design window is employed to create
a script, modify a script, set properties of a script, and so on. The variables window is
used to assign variables such as agent extension, ID, and so on to various components of
a script.
Figure 8-5
219
UCCX scripting palettes are the core of a UCCX script. Some palettes are available only
with certain license options, whereas others are common among all UCCX licensing
options. The full set of palettes is as follows:
Trigger: A call or HTTP request the system received that triggered the script.
Available with all license options.
Session: The system automatically associates a contact with a session when the contact is received (inbound) or initiated (outbound). Available with all license options.
Contact: Represents a specific interaction with a customer such as a call, email message, or HTTP request. Available with all license options.
Call Contact: Permits managing call session types. Available with all license options.
eMail Contact: Permits managing email session types. Available with IP-IVR or
Premium license only.
HTTP Contact: Enables managing web session types. Available with IP-IVR or
Premium license only.
220
Media: Processes media interactions with callers. Available with all license options
with the exception of the Voice Browser and Name to User steps, which are available
only with IP-IVR or Premium license options.
User: Manages UCCX users information. Available with all license options.
Prompt: Creates dynamic prompts such as credit card number, date, text, time, currency, and so on. Available with all license options with the exception of the Create
TTS Prompt step, which is available only with IP-IVR or Premium license options.
Grammar: Allows specifying a set of all possible spoken phrases and/or DTMF digits to be recognized by the Cisco Unified CCX solution. Available with all license
options.
Document: Enables managing file access. Available with all license options.
ACD: ACD/ICD functional steps. Except for the Stop Monitor and Start Monitor
steps that are specific to the Premium license option and the Set Priority and Create
CSQ Prompt steps that are specific to the UCCX Enhanced or Premium license
options, all other steps are available.
Java: Allows Java object creation. Available with Enhanced or Premium license only.
Table 8-4 lists steps that are available for the preceding palettes.
Table 8-4
Palette
Step
Description
Availability
General
Start, End
General
If
General
General
Goto, Label
General
Call Subflow
General
Exception
Management
Palette
Step
Description
Availability
General
Set
Sets a variable/value.
Trigger
Trigger
Session
Session Mapping
Session
Get Session
Session
Set Session
Contact
Accept/Reject/
Terminate
Contact
GetContactInfo
Contact
SetContact
Call Contact
Call Consult
Transfer
Call Contact
Call Redirect
Call Contact
Place Call
Call Contact
Call Hold/Unhold
Call Contact
Accesses call-specific
information.
Call Contact
Get/Set Enterprise
Call Info
Adds an attachment to an
email.
221
222
Palette
Step
Description
Availability
Manages contact
information.
Redirects to another
website.
Media
Play Prompt
Media
Extended Play
Prompt
Media
Sends digits.
Media
Menu
Menu management.
Media
Voice Browser
User
Authenticate User
Authenticates a user/caller.
User
Get User
Retrieves user.
User
Gets/changes user
information.
Prompt
Create Container
Prompt
Concatenates prompts.
Prompt
Prompt
Upload Prompt
Grammar
Create Language
Grammar
Palette
Step
Description
Grammar
Create Menu
Grammar
Grammar
Upload to the
UCCX Grammar
repository
Document
Document
Create/Search
XML Files
Document
Transform
Document
Document
Upload File to
UCCX Server
Uploads a document to
UCCX server.
Database
DB Get
Connects to a database.
Database
DB Read/Write
Reads/writes data in a
database.
Database
DB Release
ACD
Select Resource
ACD
Connect/Select
Resource
ACD
Get Reporting
Static
ACD
Dequeue
Dequeues a call.
ACD
Set Priority
Specific to UCCX
Enhanced or Premium
license options
Java
223
Availability
224
Call subflows (in the design window) are similar to a flowchart with procedures or function calls. Data can be passed to and from subflows. Subflows allow you to modularize
logic and package the same into reusable objects.
Several variable types are available, such as Integer, String, Character, Float, Long,
Double, and so on. A variable can be final and is considered as a constant. A variable may
also be an array. It can be a script parameter and changed in the Web Admin Tool as well.
Chapter 9
226
Cisco Unified
IP Phone
Cisco Unified
IP Phone
IP WAN
Cisco Unified
CME
PSTN
Cisco Unified
CME
Cisco Unified
IP Phone
Figure 9-1
Cisco Unified
IP Phone
This command extracts all CUCME files, including ring tones, phone boot files, and so
on, to the routers flash.
For every Cisco Unified CME deployment, DHCP-assigned IP addresses and NTP are
required. The Cisco Unified CME router can by itself act as the DHCP server, have DHCP
addresses assigned from an external DHCP, or relay DHCP addresses. The Cisco Unified
CME router can also act as NTP master or get time from an authoritative time source.
Example 9-1 illustrates DHCP and NTP configuration on Cisco Unified CME router (as
DHCP server and NTP client).
Example 9-1 Cisco Unified CME DHCP and NTP Configuration
CMERouter(config)# ip dhcp excluded-address 10.76.108.70 10.76.108.80
!
CMERouter(config)# ip dhcp pool IP-Phones
CMERouter(dhcp-config)# network 10.76.108.0 255.255.255.0
227
Example 9-2 illustrates the setup of Cisco Unified CME web GUI access and administrative user access to the GUI.
Example 9-2
At this time, the basic Cisco Unified CME setup is complete and the platform is ready to
be configured for SCCP and SIP endpoints.
Configure Cisco Unified CME as a TFTP server (for the phones) pointing to
the firmware files, as shown in the following configuration snippet:
CMERouter(config)# tftp-server flash:/Phones/7945-7965/apps45.9-31ES13.sbn alias apps42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/cnu45.9-31ES13.sbn alias cnu42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/cvm45sccp.9-31ES13.sbn alias cvm42sccp.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/dsp45.9-31ES13.sbn alias dsp42.9-3-1ES13.sbn
CMERouter(config)# tftp-server flash:/Phones/7945-7965/jar45sccp.9-31ES13.sbn alias jar42sccp.9-3-1ES13.sbn
228
Step 2.
Step 3.
Define ephone DNs and ephones. In the following example, two ephone DNs
are defined, one with dual-line capability to support two calls per line and the
other with octo-line capability to support up to eight calls per line. Also, the
ephone definition defines the type of device, button overlay, and the MAC
address of the phone.
CMERouter(config)# ephone-dn 1 dual-line
CMERouter(config-ephone-dn)# number 8001 secondary 42618001
CMERouter(config-ephone-dn)# description 42618001
CMERouter(config-ephone-dn)# label 42618001
!
CMERouter(config)# ephone-dn 2 octo-line
CMERouter(config-ephone-dn)# number 8002 secondary 42618002
CMERouter(config-ephone-dn)# description 42618002
CMERouter(config-ephone-dn)# label 42618002
!
CMERouter(config)# ephone 1
CMERouter(config-ephone)# description 7965 phone
009_9780133845969_ch09.indd 228
6/25/14 11:35 AM
229
Configure Cisco Unified CME as a TFTP server (for the phones) pointing to
the firmware files, as shown in the following configuration snippet:
CMERouter(config)# tftp-server flash:/Phones/9971/
dkern9971.100609R2-9-4-1-9.sebn alias dkern9971.100609R2-9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/kern9971.9-4-1-9.sebn
alias kern9971.9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/rootfs9971.9-4-1-9.
sebn alias rootfs9971.9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/
sboot9971.031610R1-9-4-1-9.sebn alias sboot9971.031610R1-9-4-1-9.sebn
CMERouter(config)# tftp-server flash:/Phones/9971/sip9971.9-4-1-9.loads
alias sip9971.9-4-1-9.loads
CMERouter(config)# tftp-server flash:/Phones/9971/
skern9971.022809R2-9-4-1-9.sebn alias skern9971.022809R2-9-4-1-9.sebn
Step 2.
Allow SIP to SIP calls and specify the interface to bind media and signaling:
CMERouter(config)# voice service voip
CMERouter(conf-voi-serv)# allow-connections sip to sip
CMERouter(conf-voi-serv)# sip
CMERouter(conf-serv-sip)# registrar server
CMERouter(conf-serv-sip)# bind all source-interface GigabitEthernet 0/1
Step 3.
Define the global voice register pool to initiate SIP phone registration. The
mode option cme sets the router to accept SIP registration as CUCME (the
default is SRST, as discussed later in this chapter). The source-address parameter defines the address and SIP port at which phones will try to register. Also
define the maximum number of DNs, pools, and so on. The create profile
command creates a SIP profile.
CMERouter(config)# voice register global
CMERouter(config-register-global)# mode cme
CMERouter(config-register-global)# source-address 10.76.108.76 port
5060
CMERouter(config-register-global)# max-dn 40
CMERouter(config-register-global)# max-pool 10
CMERouter(config-register-global)# load 9971 sip9971.9-4-1-9
009_9780133845969_ch09.indd 229
6/25/14 11:35 AM
230
Step 4.
Create voice register DNs (equivalent to ephone DNs) and define voice register
pools (equivalent to ephones):
CMERouter(config)# voice register dn 1
CMERouter(config-register-dn)# number 8003
CMERouter(config-register-dn)# name Phone 1
CMERouter(config-register-dn)# label 42618003
!
CMERouter(config)# voice register dn 2
CMERouter(config-register-dn)# number 8004
CMERouter(config-register-dn)# name Phone 2
CMERouter(config-register-dn)# label 42618004
!
CMERouter(config)# voice register pool 1
CMERouter(config-register-pool)# id mac 64AE.0CF6.6C0D
CMERouter(config-register-pool)# type 9971
CMERouter(config-register-pool)# dtmf-relay sip-notify
CMERouter(config-register-pool)# username SIP1 password cisco
CMERouter(config-register-pool)# description 42618003
CMERouter(config-register-pool)# number 1 dn 1
CMERouter(config-register-pool)# session transport tcp
!
CMERouter(config)# voice register pool 2
CMERouter(config-register-pool)# id mac 10BD.18DC.97F5
CMERouter(config-register-pool)# type 9971
CMERouter(config-register-pool)# dtmf-relay sip-notify
CMERouter(config-register-pool)# username SIP2 password cisco
CMERouter(config-register-pool)# description 42618004
CMERouter(config-register-pool)# number 1 dn 2
CMERouter(config-register-pool)# session transport tcp
231
In Example 9-3, the Mobility softkey for idle and connected states is added to the ephone
template. The ephone DN is set to enable mobility and define SNR with remote number, delay, timeout, and no-answer parameters. Finally, the ephone DN is assigned to an
ephone.
Example 9-4 illustrates SNR configuration for SIP Cisco Unified IP Phones.
Example 9-4 SNR Configuration for SIP Cisco Unified IP Phones
CMERouter(config)# voice register template 1
CMERouter(config-register-temp)# softkeys idle Redial Cfwdall
CMERouter(config-register-temp)# softkeys connected Confrn Hold Endcall
!
CMERouter(config)# voice register dn 3
CMERouter(config-register-dn)# number 8006
CMERouter(config-register-dn)# mobility
CMERouter(config-register-dn)# snr calling-number local
CMERouter(config-register-dn)# snr 4082220000 delay 1 timeout 10
CMERouter(config-register-dn)# snr ring-stop
!
CMERouter(config)# voice register pool 3
CMERouter(config-register-pool)# template 1
CMERouter(config-register-pool)# number 1 dn 3
In Example 9-4, like the SCCP phone configuration in Example 9-3, the template is
changed to have idle/connected states with the Mobility softkey, followed by assigning
mobility and SNR options to the voice register DN, and assigning template and DN to the
voice register pool.
232
CUCM
Cluster
PSTN
Signaling with
SRST Gateway
Signaling with
CUCM
IP WAN
V
Cisco Unified SRST Router
(MGCP, H.323, SIP Gateway)
PSTN
Figure 9-2
Signaling with
SRST Gateway
Cisco Unified SRST is invoked when a phone loses connectivity to the CUCM server it
is registered with and attempts to register with its configured SRST reference (defined in
CUCM). In case of traditional SRST, the router builds upon the configured application
service. The SRST gateway detects newly registered IP Phones and queries them for their
configuration, and then auto-configures itself. The SRST gateway uses SNAP technology
to auto-configure the router to provide call processing. Cisco Unified SRST is mostly
leveraged with MGCP fallback, as explained in the next section. The following are some
features of Cisco Unified SRST:
233
If the SRST reference defined in CUCM is a Cisco Unified CME router, the router first
looks for an existing configured ephone with the MAC address of the phone trying to
register. If an ephone is found, the stored configuration is used. No phone configuration
settings provided by SNAP are applied, and no ephone template is applied. If an ephone
is not located for the MAC address of the registration phone, the router adds the ephone
and applies an ephone template (similar to configuration using SNAP). Here are some
standout E-SRST features:
Automatic provisioning of remote branch sites since E-SRST router is in-sync with
CUCM that pushes the updates to the branch routers. Automatic sync for moves,
adds, and deletions from CUCM to router.
In Example 9-5, under call-manager-fallback, max-ephones and max-dn are defined for
the number of phones at the remote site. The secondary-dialtone option provides end
users with the usual dialing experience they would have when phones are registered with
CUCM. The specified MoH file allows playing MoH when a remote site is in SRST mode.
Even when the remote site is not in SRST mode, this feature can still be used to locally
provide multicast MoH at the remote site. The time-format and date-format parameters
set the correct time and date format for the phones.
Example 9-6 depicts Cisco Unified CMEbased SRST.
234
In Example 9-6, to enable Cisco Unified CME, under telephony-service the srst commands define the mode for provisioning, the mode for ephone-dns (dual-line), the ephone
template, the DN template, and the description. Other options are similar to regular SRST
configuration, as explained in the previous Example 9-5.
Example 9-7 describes the configuration for Cisco Unified CMEbased SIP SRST.
Example 9-7 Cisco Unified CMEbased SIP SRST Configuration
CMERouter(config)# voice register global
CMERouter(config-register-global)# mode srst
CMERouter(config-register-global)# source-address 10.76.108.76 port 5060
CMERouter(config-register-global)# max-dn 40
CMERouter(config-register-global)# max-pool 10
CMERouter(config-register-global)# system message SRST Mode
<output omitted for brevity>
In Example 9-7, the Cisco Unified CMEbased SIP configuration has been changed from
mode cme to srst.
In both SRST and E-SRST, a dial plan is required so that in the absence of CUCM, the
router can send and receive calls to and from the PSTN. Example 9-8 shows a basic dial
plan for an SRST gateway to accept incoming calls and to enable users to dial NANP
emergency, local, national, and international numbers.
009_9780133845969_ch09.indd 234
6/25/14 11:35 AM
235
Whether using Cisco Unified SRST or Cisco Unified CMEbased SRST, the router has to
be defined as an SRST reference in CUCM. To configure an SRST reference, follow these
steps:
Step 1.
236
Figure 9-3
Step 2.
MGCP Fallback
MGCP fallback (briefly discussed in Chapter 3, Telephony Standards and Protocols) is
used to provide call-control functionality using an alternative application (H.323 operation) when a gateway is configured for MGCP in CUCM and CUCM is unreachable.
An MGCP gateway, like phones, also registers with CUCM. MGCP fallback enables a
gateway to act as a local call-control agent when the CUCM server to which remote site
phones and the gateway register is offline or WAN connectivity is lost. Therefore, Cisco
Unified SRST provides seamless call-control functionality. Figure 9-4 shows MGCP fallback (MGCP application to default application H.323).
To enable MGCP fallback and enable SRST, follow these steps:
Step 1.
Step 2.
Configure the Call Forward Unregistered (CFUR) internal and external destinations on line appearance of remote-site phones to an E.164 number (for
example, a shared line on the main site or voicemail number). This is accomplished by going to Device > Phone, selecting a phone, selecting a line, and
setting CFUR.
CUCM
Cluster
237
MGCP Application
Gateway
Fallback
Default Application
H.323
IP WAN
MGCP Gateway
with SRST
PSTN
Figure 9-4
Step 3.
MGCP Fallback
Configure the MGCP fallback and Cisco Unified SRST on remote site
gateway(s) and implement an SRST dial plan on the remote site gateway(s).
MGCP fallback configuration is shown here:
MGCPRouter(config)# ccm-manager fallback-mgcp
MGCPRouter(config)# application
MGCPRouter(config-app)# global
MGCPRouter(config-app-global)# service alternate default
A single MoH source must be used across all phones for this feature to work.
Non-fallback mode: When the WAN link is up and the phones are controlled by
CUCM. This allows the phones to consult the local MoH file instead of reaching out
to CUCM across the WAN.
Fallback mode: When SRST is active; for example, when the remote site has lost connectivity to the central site CUCM. In this case, the branch router can continue to
provide multicast MoH.
To configure multicast MoH, both the CUCM MoH server and the voice gateway at
the remote site need to be configured. Assuming that multicast routing in the router
238
is enabled and pim dense mode for required interface(s) is configured, CUCM and the
router must be designed to support multicast MoH. To configure CUCM to support multicast MoH, follow these steps in Cisco Unified CM Administration:
Step 1.
Choose Media Resources > Music on Hold Audio Source and select the
audio source you are enabling for multicast. Ensure that the Allow Multicast
check box is checked.
Step 2.
Step 3.
Go to Media Resources > Media Resource Group (MRG) and click Add
New. Add a new MRG and ensure that it has the multicast-enabled MoH
server assigned to it and is multicast enabled.
Step 4.
Step 5.
Configure the SRST router for multicast MoH. The following example shows
SRST multicast MoH configuration:
SRSTRouter(config)# ccm-manager music-on-hold
!
SRSTRouter(config)# interface loopback 10
SRSTRouter(config-if)# ip address 10.86.108.82 255.255.255.255
!
SRSTRouter(config)# call-manager-fallback
SRSTRouter(config-cm-fallback)# ip source-address 10.76.108.78 port
2000
SRSTRouter(config-cm-fallback)# moh music-on-hold.au
SRSTRouter(config-cm-fallback)# multicast moh 239.1.1.1 port 16384
route 10.86.108.82 10.76.108.78
Dial peer: For accepting VoIP or POTS calls coming into voice gateways and for
sending calls to destination devices/trunks. Dial peers can point to or accept calls
from an IP (H.323, SIP, MGCP) endpoint/call-control/ephone or a PBX/PSTN-facing
trunk (T1, E1, E1-R2, BRI).
Digit manipulation: For manipulating digits so that the calling/called number can
be changed and delivered as required to the destination; capabilities include the
following:
Prefixing digits
Forwarding digits
Call pickup/waiting/forwarding
Shared DNs
239
Character
Description
0 to 9,*,#
[09]
In the match pattern, indicates where to slice the number, and in the replacement pattern, indicates where to copy the number to keep.
240
Character
Description
()
Delimiter that marks start and end of both matching and replacement strings.
Examples 9-9 and 9-10 illustrate voice translation rules followed by an expected output
using a test command.
Example 9-9 Voice Translation Rule - Number Expansion (Test Commands)
Router(config)# voice translation-rule 1
Router(cfg-translation-rule)# rule 1 /\(^[2-9].........\)/ /91\1/
Router(cfg-translation-rule)# rule 2 /^8.../ /9222&/
!
Router# test voice translation-rule 1 4082228000
Matched with rule 1
Original number: 4082228000
!
Router# test voice translation-rule 2 8000
Matched with rule 2
Original number: 8000
!
Router# test voice translation-rule 2 .
Matched with rule 2
Original number: .
241
With the rules defined, translation profiles are required to apply the rules at the dial peer
or trunk group level for incoming or outgoing calls as required. The following voice translation profiles can be defined:
called: Defines the translation profile rule for the called number
calling: Defines the translation profile rule for the calling number
redirect-called: Defines the translation profile rule for the redirect-called number
Using the previously defined rules as shown in Examples 9-9 and 9-10, the profiles can be
defined as shown in Example 9-11.
Example 9-11 Voice Translation Profile Configuration
Router(config)# voice translation-profile PSTN-OUT
Router(cfg-translation-profile)# translate calling 1
!
Router(config)# voice translation-profile PSTN-IN
Router(cfg-translation-profile)# translate called 2
!
Router(config)# dial-peer voice 250 POTS
Router(config-dial-peer)# translation-profile outgoing PSTN-OUT
Router(config-dial-peer)# destination-pattern 9T
Router(config-dial-peer)# forward digits all
Router(config-dial-peer)# port 0/0:23
!
Router(config)# dial-peer voice 251 POTS
Router(config-dial-peer)# translation-profile incoming PSTN-IN
Router(config-dial-peer)# incoming called-number .
Router(config-dial-peer)# direct-inward-dial
Router(config-dial-peer)# forward digits all
Router(config-dial-peer)# port 0/0:23
The Example 9-11 translation-rule 1 helps to set the outgoing calls (national) with a prefix
of 91 and the local calls with a prefix of 9. The translation-rule 2 helps strip 9 from calls
coming in with 9 as a prefix; otherwise, for any other match it sets the called number to
2228000. Finally, the translation profiles PSTN-IN and PSTN-OUT apply the rules to dial
peers 250 and 251 for outgoing and incoming calls, respectively.
At times, sending the numbering plan along with the dialed number (to PSTN) is required.
In such a case, the translation rule can be used to append the appropriate numbering plan
to different rules so that ANI (calling number) is understood correctly by the PSTN provider. Example 9-12 describes numbering plan manipulation using translation rules and
profiles.
242
In Example 9-12, translation-rule 11 helps to output the right numbering plan against
local, national, and international calls to the PSTN provider. The test commands in
Example 9-13 verify the output.
Example 9-13 Voice Translation Test Commands
Router# test voice translation-rule 11 2228000 type subscriber
Matched with rule 1
Original number: 2228000
!
Router# test voice translation-rule 11 4082228000 type national plan national
Matched with rule 2
Original number: 4082228000
Voice translation rules can also be used to block certain patterns as per policy or requirements. The following configuration illustrates voice translation rule setup to reject a particular pattern and provide a cause code of invalid number to the call initiator:
Router(config)# voice translation-rule 1
Router(cfg-translation-rule)# rule 1 reject /9011252*/
243
When matching an inbound dial peer, there is a specific order of matching that is based
on the configured parameters on the dial peer. In the case of inbound dial-peer matching,
the following rules apply:
1. Called number matching based on the DNIS is performed; based on the most explicit match. This is configured using the incoming called-number command.
2. If no dial peer is found, calling number matching based on the ANI is performed;
based on the most explicit match. This is configured using the answer-address
command.
3. Calling number matching based on the ANI is performed; based on the most explicit
match port. This is configured using the destination-pattern command.
4. If multiple dial peers have the same port (POTS dial peer), the dial peer added to the
configuration earlier (or in order of addition) is considered. Port-based matching is
configured with the port command.
5. If nothing matches, default dial-peer 0 is used.
When matching an outbound dial peer, the router always uses the destination-pattern
command. In case of outbound dial-peer matching, the following rule applies: called
number based on DNIS matching the outbound dial-peer destination pattern and most
explicit match. Dial-peer routing for POTS is based on the port command and for VoIP is
based on the session target command. In certain cases, two or more dial peers may have
the same destination patternfor instance, VoIP dial peers to CUCM subscribers for call
processing redundancy. In such a case, the preference command can be added to each
dial peer to set a priority, with preference 0 being the default and highest preference.
Multiple dial peers can be defined with the same destination pattern with preference 1,
2, 3, and so on. Example 9-14 illustrates dial-peer preference configuration.
Example 9-14 Cisco IOS Router Dial-Peer Preference Configuration
IOSRouter(config)# dial-peer 100 voice voip
IOSRouter(config-dial-peer)# description Calls to Primary CUCM
IOSRouter(config-dial-peer)# preference 1
IOSRouter(config-dial-peer)# destination-pattern 8...
IOSRouter(config-dial-peer)# session-target ipv4:10.76.108.146
IOSRouter(config-dial-peer)# dtmf-relay h245-alphanumeric
IOSRouter(config-dial-peer)# no vad
!
IOSRouter(config)# dial-peer 101 voice voip
IOSRouter(config-dial-peer)# description Calls to Secondary CUCM
IOSRouter(config-dial-peer)# preference 2
IOSRouter(config-dial-peer)# destination-pattern 8...
IOSRouter(config-dial-peer)# session-target ipv4:10.76.108.147
IOSRouter(config-dial-peer)# dtmf-relay h245-alphanumeric
IOSRouter(config-dial-peer)# no vad
244
Resets DSPs, brings up DSPs, and downloads application images to DSPs during a
DSP upgrade
Discovers the on-board DSP SIMM modules and, based on the user configuration,
determines the type of application image that a DSP uses
Maintains the DSP initialization states and resource states, and manages the DSP
resources
Handles failures such as DSP crashes and session terminations while simultaneously
allowing log/crash dump generation
Provides keepalive mechanism between DSPs and primary and backup CUCM
servers
Performs periodic DSP resource checks and keeps a tab on maximum sessions
configured
Interfaces with the backplane Protocol Control Information (PCI) driver for sending
and receiving DSP control messages
When a request for a media session is received from the signaling layer, DSPRM assigns
the available DSPs from the respective media resource pool, such as transcoding or conferencing, as instructed by CUCMs MRGLs. Following are some useful commands to
monitor DSP resources:
245
In Example 9-15, DSP resources on voice-card 0 (PVDM) are leveraged for the DSP farm.
SCCP is the application that drives the conference bridges on Cisco IOS. It is used to
bind the source interface to the application and set up the CUCM/Cisco Unified CME IP
address(es) that it should be registered with. The CCM group defines the various parameters related to the conference bridge and the name HWCFB with which the conference
resource registers with CUCM/Cisco Unified CME. Finally, the DSP profile defines the
purposes of the applicationfrom conferencing to transcoding to MTPand sets the
maximum participants per session and maximum sessions, sets the codecs acceptable
during conference calls, and associates the SCCP application to the profile. Note that the
same configuration framework is needed for Cisco Unified CME conferencing.
246
In Example 9-16, the SCCP CCM group is used to bind profile 2 (the transcoding profile)
and register it as HWXCD with CUCM/Cisco Unified CME. The DSP profile transcoding
allows SCCP to control the DSP resources and set up transcoding for various code
types. Note that the same configuration framework is needed for Cisco Unified CME
transcoding.
247
248
249
In Example 9-17, under telephony-service, the use of hardware conference prevents use
of Cisco Unified CME CPU resources for software conferences. The sdspfarm commands are used to define conferencing and transcoding services by defining two units
so that two (dspfarms) services can be defined with different sdspfarm tags. The tags are
used to differentiate and define conferencing and transcoding services. Following this,
conferencing mute-on/mute-off (optional) codes and transcoding sessions are defined.
The ephone-template command sets the Idle, Sized, Connected, and Hold softkeys to
include support for ad hoc/Meet-Me conference calls and also to enable the user to display a list of conference participants. Ephone-dn 20 is a special ephone-dn used for ad
hoc conferencing, and ephone-dns 21 and 22 are also special ephone-dns used for MeetMe conference. The Meet-Me ephone-dns have call hunting, as ephone-dn 22 allows
hunting to the next ephone-dn 23 (lower preference) with the same extension. Finally,
the ephone templates and ephone-dns are assigned to the ephones, with the first ephone
assigned conference admin, add-mode creator (adding parties to conference), and dropmode creator (drops conference when creator leaves).
250
Assuming that B-ACD scripts have been downloaded and extracted to Cisco Unified
CME flash, the following steps are required to configure CME B-ACD:
The B-ACD 3.0.0.2 script tar file can be downloaded from http://software.cisco.com/
download/release.html?mdfid=277641082&catid=278875240&softwareid=283451126&
release=8.8&relind=AVAILABLE&rellifecycle=&reltype=latest.
Example 9-18 shows B-ACDbased AA configuration.
Example 9-18 Cisco Unified CMEbased B-ACD Script
CMERouter(config)# application
CMERouter(config-app)# service callqueue flash:/scripts/app-b-acd-3.0.0.2.tcl
CMERouter(config-app-param)# param queue-len 10
CMERouter(config-app-param)# param aa-hunt1 8888
CMERouter(config-app-param)# param aa-hunt2 8889
CMERouter(config-app-param)# param aa-hunt10 8005
CMERouter(config-app-param)# param number-of-hunt-grps 2
CMERouter(config-app-param)# param queue-manager-debugs 1
!
CMERouter(config-app)# service aa-bcd flash:/scripts/app-b-acd-aa-3.0.0.2.tcl
CMERouter(config-app-param)# paramspace english location flash:/prompts/
CMERouter(config-app-param)# paramspace english index 0
CMERouter(config-app-param)# paramspace english language en
CMERouter(config-app-param)# param aa-pilot 8000
CMERouter(config-app-param)# param voice-mail 8100
CMERouter(config-app-param)# param max-time-vm-retry 2
CMERouter(config-app-param)# param second-greeting-time 30
CMERouter(config-app-param)# param call-retry-timer 5
CMERouter(config-app-param)# param max-time-call-retry 30
CMERouter(config-app-param)# param service-name callqueue
CMERouter(config-app-param)# param queue-overflow-extension 8010
CMERouter(config-app-param)# param number-of-hunt-grps 2
CMERouter(config-app-param)# param handoff-string aa-bcd
!
CMERouter(config)# ephone-hunt 1 longest-idle
CMERouter(config-ephone-hunt)# pilot 8888
CMERouter(config-ephone-hunt)# list 8001, 8002
CMERouter(config-ephone-hunt)# timeout 10, 10
!
CMERouter(config)# ephone-hunt 2 longest-idle
CMERouter(config-ephone-hunt)# pilot 8889
251
In Example 9-18, service aa-bcd and callqueue are configured for AA and call queuing,
respectively. Going over application aa-bcd, you first notice the location of scripts, followed by the location of prompts, and finally a description of the language for prompts
as English via paramspace english parameters. Next, aa-pilot is used to define the
B-ACD applications pilot number, which must match the VoIP and/or POTS dial peer
incoming called number (this can be translated to the AA pilot number via translation
profiles). Next, Example 9-18 uses voice-mail to set the voicemail number and max-timevm-retry to set the maximum number of attempts to reach voicemail. Then the parameters for second greeting, call retry, and maximum call retries are defined. Following
these, the queue script is invoked (with hand-off from the AA script) that enables the call
to eventually land into one or more hunt groups, thereby enabling hunting of ephones
assigned to the hunt groups. The queue-overflow-extension sets the extension to send
calls to in case the queue length is exceeded.
Now, looking into the call queuing script, it begins by definition of the queue-len for
the calls that are not answered/answerable by ephones logged in to the hunt group. This
might occur if all logged-in (users) agents are busy or no agents are logged in. Then the
options to dial as per the B-ACD menu option (derived from en_bacd_options_menu.au)
for example, 1, 2, 0 (menu option 0 is hard coded for operator extension and the B-ACD
script assumes that the hunt group with the highest aa-hunt number is the operator
group) are configured with each hunt group associated with a number. Finally, queuemanager-debugs enables debugging for the call queue.
A variation to B-ACD is to have the caller immediately routed to a configured hunt group
so that the caller does not hear any prompt and is not required to provide any DTMF
inputs. This type of B-ACD routing is known as a drop-through option. This is useful in
009_9780133845969_ch09.indd 251
6/25/14 11:35 AM
252
case the caller should be greeted and put into a queue to speak with an agent or wait for
an agent to become available. Example 9-19 shows the configuration of a drop-through
option.
Example 9-19 B-ACD Drop-Through Option
CMERouter(config)# application
CMERouter(config-app)# service callqueue flash:/scripts/app-b-acd-3.0.0.2.tcl
CMERouter(config-app-param)# param queue-len 10
CMERouter(config-app-param)# param aa-hunt1 8888
<output omitted for brevity>
CMERouter(config-app-param)# param number-of-hunt-grps 1
!
CMERouter(config-app)# service aa-bcd flash:/scripts/app-b-acd-aa-3.0.0.2.tcl
<output omitted for brevity>
CMERouter(config-app-param)# param drop-through-option 1
CMERouter(config-app-param)# param drop-through-prompt _bacd_welcome.au
CMERouter(config-app-param)# param number-of-hunt-grps 1
It is important to note that both AA and call queuing applications need to be loaded
(activated). This is accomplished by using the following commands:
CMERouter# call application voice load callqueue
CMERouter# call application voice load aa-acd
The members of a voice hunt group can be SCCP endpoints, SIP endpoints, ds0group, pri-group, FXS port, or SIP trunk.
There are different types of hunting possible within a voice hunt group:
Sequential: Each extension number in the hunt group is tried sequentially, starting
from the first number. If the end of the group is reached without finding an
253
Peer mode: A call is made to hunt extension numbers in a circular list. The starting
point in the list for a new call is set by the last number that answered the preceding
callthat is, n + 1, with n being the last number to answer the call. For example, in
a hunt group with members 8001, 8002, 8003, and 8004, if 8003 answered the last
call, then hunting will begin at 8004.
Longest Idle: As the name suggests, the starting point in the list for a new call is set
by the number that has been on-hook for the longest period of time. The number of
hops can be defined to allow a call to hop to longest-idle number before the call is
sent to final destination.
Parallel: All the numbers in the group rings simultaneously (also known as Call Blast,
covered in the next section).
Call Blast
Call blast, also known as parallel hunt group, allows a user to dial a pilot number that
rings two to ten different extensions simultaneously. Call blast is analogous to the broadcast hunt-group mechanism in CUCM. The first extension to answer the call gets connected to the caller, while other extensions stop ringing. A timeout value can be set so
that if none of the extensions answers before the timer expires, all the extensions stop
ringing and the final destination number rings indefinitely, which can be set to another
hunt group or a voicemail number. Example 9-20 shows the configuration of a call blast/
parallel hunt group that rings extensions 8001, 8002, 8003, 8004, and 8005 when the
pilot number 8700 or secondary E.164 4082228700 is called (from another ephone or a
dial peer).
Example 9-20
254
255
In Example 9-21, the voicemail number defined under telephony-service enables the
users to press the voice messaging (envelope) button and get to voicemail. The MWI On
and Off numbers are defined as a kind of prefix such that these On or Off numbers can
be prefixed to the extension for which MWI must be turned on or off. SIP dial-peer 8100
points to the CUE modules IP address with the VM number as the destination pattern.
SIP dial-peer 8111 enables Cisco Unified CME to accept incoming MWI requests from
CUE and appropriately light up or switch off the MWI on a phone. The CUE interface
(Integrated Service Module [ISM] in this case) is bound with the Cisco Unified CMEs
interface, with the latters interface IP set as the default gateway for CUE, and a static
route points the way to the CUE module via the CLI or GUI.
In addition to the configuration in Example 9-21, CUE should be configured for voicemail application. This is accomplished by logging in to CUE using the command serviceengine ISM 0/0 session. CUE configuration for basic voicemail integration requires
setting up a system for SIP for routing to Cisco Unified CME and enabling it, setting up
the voicemail number and enabling it, and setting up MWI numbers. A list of existing
ccn applications, triggers, and subsystems can be seen by using the command show ccn
<parameter>, as shown in Example 9-22.
Example 9-22 CUE Outcalling MWI Configuration
CUE(config)# ccn subsystem sip
CUE(config-sip)# gateway address 10.76.108.76
CUE(config-sip)# enable
CUE(config-sip)# end
!
CUE(config)# ccn trigger sip phonenumber 8100
Adding new trigger
CUE(config-trigger)# enabled
CUE(config-trigger)# application "voicemail"
CUE(config-trigger)# end
!
CUE(config)# ccn application ciscomwiapplication aa
Modifying existing application
CUE(config-application)# description "ciscomwiapplication"
CUE(config-application)# enabled
CUE(config-application)# maxsessions 2
CUE(config-application)# script "setmwi.aef"
CUE(config-application)# parameter "CallControlGroupID" "0"
CUE(config-application)# parameter "strMWI_OFF_DN" "8111"
256
The CUE web administration GUI can be accessed using the URL http://<IP address of
CUE>/admin/.
Subscribe - Notify
Unsolicited Notify
Figure 9-5 gives an insight to the different MWI mechanisms that can be configured for a
CUE MWI application.
Figure 9-5
Outcalling
The Outcalling option allows CUE to make an outbound call to the Cisco Unified CME
router using a SIP INVITE message. This option was covered in Example 9-22 (Cisco
Unified CME and CUE integration). The Outcalling option works for SCCP phones only.
257
The MWI server must be set up on the Cisco Unified CME so that the CUE IP address
and (optionally) port (as well as other parameters) are specified. SIP-based ephones (SIPUA) and SCCP-based ephone-dns send the SUBSCRIBE message to the MWI server that
is defined. The subscription definition forces the MWI service defined on the CUE and
CUE to notify the ephone-dns with an MWI update when there is a new voicemail message for a voicemail subscriber.
Unsolicited Notify
CUE can be configured to notify MWI to endpoints without SUBSCRIBE. The
Unsolicited Notify option forces CUE to send the NOTIFY message to indicate that
a new message has been received on CUE and the ephone does not need to send the
SUBSCRIBE method to the MWI server. This implies that the voice register DN and
ephone DN no longer need the MWI option configured; the NOTIFY occurs without
subscription. The Unsolicited Notify option cannot be combined with the Outcalling
258
Manage all eight greetings (Standard, Internal, Closed, Busy, Alternate, Meeting,
Vacation, Extended Absence)
CUE Auto-Attendant
Figure 9-6
Step 2.
259
Step 3.
Apply the configuration (create cnf-files for SCCP phones and create profile
for SIP phones) and reset the ephones.
CUE Auto-Attendant
CUE, as described earlier, can act as an auto-attendant (AA) for remote sites or small
business solutions. An AA solution is a logical mapping of greetings, options, and
responses that helps answer incoming calls by providing a menu-based system that offers
callers menu-based options or plays specific greetings. The CUE AA is based on scripts
that provide options or prompts that can be used for self-service options for a caller.
Cisco Unified Communications Express Editor can be employed to create customized
scripts for various AA flows. CUE scripting and Cisco Unified Communications Express
Editor are discussed in the next section.
CUE default installation includes a prebuilt (default) basic AA application. To configure the CUE AA in Cisco Unity Express Administration, choose Voice Mail > Auto
Attendant and click on autoattendant (system default). You can set up the AA parameters as shown in Figure 9-7.
260
009_9780133845969_ch09.indd 260
6/25/14 11:35 AM
CUE Scripting
261
CUE Scripting
In certain cases the standard AA can be too limited. For administrators and organizations that wish to leverage the CUE AA to its fullest potential, CUE offers a script editor
that allows the creation of custom scripts. Custom scripts can be loaded into CUE to
provide a much more complex AA application. CUE offers a built-in script editor and a
stand-alone Windows-based script editor, Cisco Unified Communications Express Editor.
Figure 9-8 shows the CUE built in script editor in action. To access the CUE built-in
script editor in Cisco Unity Express Administration, choose System > Scripts and click
New. The built-in script editor enables administrators to define multistep scripts and add
new elements such as a submenu, dial-by-name, dial-by-extension, and so on to create a
customized AA script.
Figure 9-8 depicts the aacustomized.aef script implementation.
Figure 9-8 shows how to create a customized script titled aacustomized.aef using the
CUE built-in script editor with the following settings and call flow:
Allows dialing by extension anytime during the main menu options. Extensions are
defined to have a four-digit length. Alternate Menu is chosen for Business Closed
hours. Business Schedule follows system schedule.
009_9780133845969_ch09.indd 261
6/25/14 11:35 AM
262
38: Unassigned
9: Dial by Extension
The caller can press 1 to leave a message in operator (general) voicemail (transfer to
voicemail box 8999).
Figure 9-8
Figure 9-9
263
Allows a message that was created on one system to be sent to another system (CUE
to CUE or CUE to CUC, and vice versa)
MIME is employed for voice mail, vCard (phone number, text name, and email
address), and spoken name transport.
Delayed delivery records are generated if a message is not delivered in 1 hour, and
non-delivery records are generated if the message is undeliverable after 6 hours.
264
Least Recently Used (LRU) cache: When a system shares its location information
with a remote system, it allows the remote system to cache the information of the
sender. This cache is known as the LRU cache. The remote system references cached
information to address messages coming from VPIM networked system. Its important to understand that the LRU cache cannot be employed for defined remote users.
However, the local system must receive a message from a user on a remote system
before the LRU cache is populated.
Blind addressing: Used when no entry exists in the LRU cache of the remote system
and no remote user for the destination has been defined. In such case, the remote
users extension and location must be used to address the message.
Step 2.
Create a local location for the local CUE server followed by one or more
remote locations for CUC or CUE servers that will participate in VPIM.
Ensure that the local location is assigned as the local location by clicking the
location, typing the location ID in the Local Location ID field (as shown in
Figure 9-11), and then clicking Apply.
Step 3.
Navigate to Configure > Remote Users and click Add. Provide the required
details such as user ID, first and last name, primary extension, display name,
and remote location.
Step 4.
Figure 9-10
Figure 9-11
265
266
Figure 9-12
Step 5.
Step 2.
Step 3.
If the user is defined as a remote user in CUE, dial the voice mailbox DN of
the VPIM user (for example, 8000) and record and send a message (location
is known to CUE). If the remote user is not defined, enter the location ID followed by the voice mailbox extension.
267
the network can ensure sufficient quality of service. There are three types of CAC mechanisms, as described in this section:
Local CAC
Reservation-based CAC
Measurement-based CAC
Local CAC
Local CAC is based on a devices local determination, such as the state of an outgoing
interface or link. The different mechanisms that are part of local CAC are
Local Voice Busyout (LVBO): Allows PBX trunks connected to a voice gateway to
be taken out of service when WAN conditions are not suitable for voice transport.
LVBO allows a gateway to monitor up to 32 interfaces and provides the ability to
monitor the state of network interfaces, including both LAN and WAN, and thereby
busy out trunks to the PBX if any of the monitored links fails. LVBO can be implemented under voice ports (T1/E1) by using the command busyout monitor <interface type>.
Reservation-Based CAC
Reservation-based CAC is based on the reservation or calculation of required resources
before a call can be admitted. RSVP (discussed in Chapter 4), CUCM locations-based
CAC (LCAC), and gatekeeper zonebased CAC are types of reservation-based CAC.
Example 9-26 shows configuration of a gatekeeper zonebased CAC.
Example 9-26 Gatekeeper ZoneBased CAC
GKRouter(config)# gatekeeper
GKRouter(config-gk)# zone local CUCMGK corp.local 10.10.1.180
GKRouter(config-gk)# zone remote CMEGK corp.local 10.10.2.180
GKRouter(config-gk)# zone prefix CUCMGK 1*
GKRouter(config-gk)# gw-type-prefix 1#* default-technology
GKRouter(config-gk)# bandwidth session zone CUCMGK 256
GKRouter(config-gk)# bandwidth total zone CUCMGK 2048
268
In Example 9-26, bandwidth commands are used to define per-session (call) bandwidth
for calls from the CUCMGK zone, total bandwidth available for the CUCMGK zone,
default interzone bandwidth between CUCMGK and other zones, and the bandwidth
available between CUCMGK and a remote CMEGK zone. It is important to note that
gatekeepers subtract bandwidth from a configured pool of bandwidth twice that of a
codec bit rate (such as a G.711 call that uses 64 Kbps from one endpoint). A gatekeeper
subtracts 128 Kbps (for bidirectional call) and likewise 16 Kbps for a 8-Kbps G.729 call
between two endpoints.
Measurement-Based CAC
Measurement-based CAC techniques look ahead into the network to measure the state
of the network in order to determine whether to allow a new call. This involves the use
of probes such as Cisco Service Level Agreement (SLA) or Service Assurance Agent
(SAA) probes. Measurement-based CAC mechanisms include Advanced Voice Busyout
(AVBO) and PSTN Fallback. AVBO is an advancement of the LVBO feature that adds the
capability to probe destinations using Cisco SLA/SAA and has the ability to busy out a
trunk or voice ports based on network conditions. AVBO uses the Impairment Calculated
Planning Impairment Factor (ICPIF) or specific network delay, or loss values for its operation. PSTN fallback is based on SAA and acts on ICPIF or delay, or loss values as configured. PSTN fallback does not busy out a trunk or voice ports, but instead works on a
per-call basis.
File accounting: CDR information is written into CSV files, and these files can be
transferred to a billing server using FTP.
269
File Accounting
The file accounting method is the simplest to set up and enables you to specify one of
three formats for CDR data:
Compact: Minimal attributes are sent based on options available with the
cdr-format compact command.
A central FTP server or site-specific FTP server (preferred for SRST scenarios) is required
to receive CSV files from the router. Example 9-27 outlines the configuration for the file
accounting method.
Example 9-27 File Accountingbased CDR Accounting
Router(config)# gw-accounting file
Router(config-gw-accounting-file)# primary ftp 10.96.108.100 username cdradmin
password 0 C1sc0123
Router(config-gw-accounting-file)# cdr-format compact
Router(config-gw-accounting-file)# maximum buffer-size 10
Router(config-gw-accounting-file)# maximum retry-count 5
Router(config-gw-accounting-file)# maximum fileclose-timer 30
Router(config-gw-accounting-file)# maximum cdrflush-timer 300
In Example 9-27 the router is set up for file accounting, with the primary FTP server and
credentials defined. The CDR format is kept at compact (regular set of VSAs) with the
CDR buffer size set to 10, the file close timer set to 30 minutes, and the CDR flush timer
set to 300 minutes. The retry interval (keepalive) for the primary server is set to five tries.
270
In Example 9-28 AAA is enabled on the Cisco IOS router, followed by setting up the
router to send H.323 attributes and to communicate with a RADIUS server. VSA attributes are set up to be reported by the RADIUS server. Finally, gw-accounting aaa
enables RADIUS AAA accounting and sets up the router to send all call history VSAs
(equivalent to detailed format in file accounting) with attributes from sessions and
remote h323-id.
271
SAFRouter(config-router-sf-interface)# no split-horizon
SAFRouter(config-router-sf-interface)# hello-interval 10
SAFRouter(config-router-sf-interface)# hold-time 20
!
SAFRouter(config)# service-family external-client listen ipv4 5050
SAFRouter(config-external-client)# external-client CUCM-Cluster1
SAFRouter(config-external-client-mode)# username CUCM-SAF
SAFRouter(config-external-client-mode)# password C1sc0123456
SAFRouter(config-external-client-mode)# keepalive 5000
!
SAFRouter(config)# voice service saf
SAFRouter(conf-voi-serv-saf)# profile trunk-route 1
SAFRouter(conf-voi-serv-saf-tr)# session protocol sip interface loopback 0 transport
udp port 5060
SAFRouter(conf-voi-serv-saf)#profile dn-block 1
SAFRouter(conf-voi-serv-saf-dnblk)#pattern 1 type global 1408222XXXX
SAFRouter(conf-voi-serv-saf-dnblk)#pattern 2 type extension 43611000
SAFRouter(conf-voi-serv-saf)# profile callcontrol 1
SAFRouter(conf-voi-serv-saf-cc)# dn-service
SAFRouter(conf-voi-serv-saf-cc-dn)# trunk-route 1
SAFRouter(conf-voi-serv-saf-cc-dn)# dn-block 1
SAFRouter(conf-voi-serv-saf)# channel 1 vrouter SAF asystem 100
SAFRouter(conf-voi-serv-saf-chan)# subscribe callcontrol wildcarded
SAFRouter(conf-voi-serv-saf-chan)# publish callcontrol 1
CUCM Cluster
(SAF External Client)
CCD
SAF Client
Protocol
SAF Publish/
Advertise
SAF Forwarding
Protocol
SAF Network
SAF Notify
SAF Forwarder
SAF Forwarder
(Adjacent Neighbors)
Figure 9-13
272
SAF leverages EIGRP (virtual router), although the underlying network can use static
routing or any dynamic routing protocol. EIGRP routing instance SAF initiates a SAFassociated configuration on the Cisco IOS router. The service-family and autonomoussystem attributes are required because SAF clients must know them to register with
this forwarder. Neighbors wont form a neighbor relationship unless these values match
between forwarders. The sf-interface command (a default command that allows SAF on
all interfaces) permits a specific interface, thereby limiting SAF to a particular interface.
SAF authorizes multiple service topology databases per service-family, in this case defining SAF client(s). The service-family allows SAF client configuration so that a client
forwarder authentication relationship can be built. A client label is unique across an AS,
and only one client can use a client label. The username and password are implemented
for security validation with a SAF client. Keepalives are used between the SAF client and
forwarder to ensure that the forwarder is available; otherwise, the clients can reroute the
calls out the alternate path (PSTN).
The command voice service saf initiates CCD service on the router. This is followed by
creating a trunk profile to let other devices know with which protocol to contact the SAF
client/forwarder. The dn-block command defines the routes to advertise. A callcontrol
profile ties all these entities together. Finally, the callcontrol profile(s) need to be associated with SAF as, for instance, a channel using the EIGRP process name and AS number.
The publish process advertises the callcontrol profile to the SAF network, whereas the
subscribe process makes the router listen to wildcard (all) advertisements (could be set to
listen to specific advertisements as well).
A security demarcation (border) between the trusted enterprise network and untrusted public network.
Tools such as Cisco IOS Firewall (providing Context-Based Access Control) and
Cisco Intrusion Prevention System (IPS) to manage common vulnerability exploits,
such as preventing denial-of-service (DoS) attacks and detecting malformed packets.
273
CUBE Redundancy
As an important part of the SIP trunking solution, CUBE should be deployed in highavailability (redundant) mode where possible. The following options are available for
CUBE redundancy:
Inbox redundancy: Provides high-availability within the same box (local redundancy) in the same chassis (supported in Cisco ASR 1000 Series only) with stateful
failover. Inbox redundancy can be hardware based or software based. Hardwarebased inbox redundancy leverages a dual-control plane and a dual-forwarding plane
in ASR 1006for example, two route processors (Active/Standby) within the same
chassis. Software-based redundancy is supported with Cisco ASR 1001, 1002, and
1004 Series, wherein two instances of Cisco IOS run on the same route processor.
Box-to-box redundancy (Layer 2): Uses Hot Standby Router Protocol (HSRP) and
the underlying switching infrastructure to form an Active/Standby pair of routers.
Inheriting the HSRP feature, the Active/Standby pair shares the same virtual IP (VIP)
address and persistently exchanges keepalive messages. The two physical chassis can
be placed in the same data center or can be geographically separated (provided Layer
2 SLAs are met). Box-to-box redundancy is available for Cisco ISR G2 and Cisco
ASR 1001, 1002, 1004 and 1006, and supports stateful failover.
Clustering (with load balancing): Offers both high availability and scalability by
spreading calls across different chassis in the same data center or geographically
separated sites. Clustering allows multiple CUBE routers (ASRs and ISRs) to perform
load balancing as a SIP proxy manages call distribution across the cluster.
CUBE box-to-box high availability is covered in this section. Figure 9-14 shows the
CUBE chassis (ISR G2 router) deployed in a box-to-box redundancy configuration
using HSRP.
Inside
Outside
Active CUBE
CUCM
Cluster
HSRP Address
10.76.108.1
GE 0/0
GE 0/1
10.76.108.2
192.168.108.2
Keepalives
Keepalives
HSRP Address
192.168.108.1
SIP SP
Network
HSRP
Group 1
10.76.108.146
Keepalives
10.76.108.3
GE 0/0
Keepalives
HSRP
Group 9
192.168.108.254
192.168.108.3
GE 0/1
Standby CUBE
Figure 9-14
Example 9-30 and Example 9-31 outline the Active and Standby CUBE configurations.
009_9780133845969_ch09.indd 273
6/25/14 11:35 AM
274
275
Example 9-31
276
!
CUBEB(config)# interface GigabitEthernet 0/0
CUBEB(config-if)# ip address 10.76.108.3 255.255.255.0
CUBEB(config-if)# standby version 2
CUBEB(config-if)# standby 1 ip 10.76.108.1
CUBEB(config-if)# standby 1 priority 50
CUBEB(config-if)# standby 1 preempt
CUBEB(config-if)# standby 1 track 1 decrement 10
CUBEB(config-if)# standby 1 name SB-Group
!
CUBEB(config)# interface GigabitEthernet 0/1
CUBEB(config-if)# ip address 192.168.108.3 255.255.255.0
CUBEB(config-if)# standby version 2
CUBEB(config-if)# standby 9 ip 192.168.108.1
CUBEB(config-if)# standby 9 priority 50
CUBEB(config-if)# standby 9 preempt
CUBEB(config-if)# standby 9 track 2 decrement 10
!
CUBEB(config)# dial-peer voice 500 voip
CUBEB(config-dial-peer)# description Calls-To-SIP-SP
CUBEB(config-dial-peer)# destination-pattern 9T
CUBEB(config-dial-peer)# session protocol sipv2
CUBEB(config-dial-peer)# session target ipv4:192.168.108.254
CUBEB(config-dial-peer)# voice-class sip bind control source-interface
GigabitEthernet 0/1
CUBEB(config-dial-peer)# voice-class sip bind media source-interface
GigabitEthernet 0/1
CUBEB(config-dial-peer)# codec g711ulaw
!
CUBEB(config)# dial-peer voice 510 voip
CUBEB(config-dial-peer)# description Calls-To-CUCM
CUBEB(config-dial-peer)# destination-pattern 408222....
CUBEB(config-dial-peer)# session protocol sipv2
CUBEB(config-dial-peer)# session target ipv4:10.76.108.146
CUBEB(config-dial-peer)# voice-class sip bind control source-interface
GigabitEthernet 0/0
CUBEB(config-dial-peer)# voice-class sip bind media source-interface
GigabitEthernet 0/0
CUBEB(config-dial-peer)# codec g711ulaw
!
CUBEB(config)# ip rtcp report interval 3000
!
CUBEB(config)# gateway
CUBEB(config-gateway)# media-inactivity-criteria all
CUBEB(config-gateway)# timer receive-rtp 86400
CUBEB(config-gateway)# timer receive-rtcp 5
277
In Example 9-30 and Example 9-31, under voice service voip (global mode), the mode
is defined as border-element and redundancy is enabled for SIP connections and enables
CUBE checkpointing (a stateful failover mechanism). Next, a redundancy scheme is
defined via the scheme standby command. The track interface command allows the
router to track the line protocol state of the monitored interfaces. The ipczone commands
help define HSRP configuration for keepalive exchange. The standby commands enable
HSRP on the internal CUCM facing and external SIP SP-facing interfaces, respectively.
The dial peers define calls to the SIP SP and CUCM and bind media as well as signaling
to respective interfaces. The ip rtcp and media-inactivity commands configure a media
inactivity feature to clean up any calls that may not disconnect after a failover.
A device sending a value or parameter that must be changed or suppressed or normalized before it leaves or enters the enterprise logical perimeter to comply with an
service providers or organizations policies
SIP SP
Network
CUBE
Figure 9-15
278
Pertinent to Figure 9-15, the following are requirements of the SIP SP:
Condition 1: For call forward and transfer scenarios back to the PSTN, the diversion
header should match the registered DID (E.164 number).
Condition 2: The User-Agent (UA) field in all SIP messages should state the version
of CUCM and CUBE.
The SIP INVITE sent by CUBE needs to be normalized so that the SP network can accept
the incoming SIP INVITE as per the configuration of the SP softswitch. In this case a SIP
profile needs to be defined to help normalize diversion headers to an E.164 number and
set the UA field to the correct CUCM and CUBE version. Example 9-32 illustrates the
CUBE SIP profile that supports both normalization tasks (SIP INVITE and REINVITE
diversion header and SIP UA description).
Example 9-32 CUBE SIP Normalization Profile
CUBE(config)# voice class sip-profiles 1000
CUBE(config-class)# request INVITE sip-header Diversion modify "sip:(.*>)"
"sip:4082228000@sip.crop.local"
CUBE(config-class)# request REINVITE sip-header Diversion modify "sip:(*.>)"
"sip:4082228000@sip.crop.local"
CUBE(config-class)# request ANY sip-header User-Agent modify "User-Agent:(.*)"
"User-Agent: CUCM 9.1/IOS-15.2.3T"
The SIP profile can be applied at a global level under voice service voip or can be applied
to an SP-facing dial peer (dial-peer specific), as shown in Example 9-33.
Example 9-33 CUBE SIP Profile Global and Dial-Peer Specific Application
CUBE(config)# voice service voip
CUBE(conf-voi-serv)# sip
CUBE(conf-serv-sip)# sip profiles 1000
!
CUBE(config)# dial-peer voice 1000 voip
CUBE(config-dial-peer)# description Calls To/From SP
CUBE(config-dial-peer)# voice-class sip profiles 1000
CUBE(config-dial-peer)# codec g711ulaw
279
for the called device to send its capabilities first and then negotiates what it wants (for
example, which codecs).
CUBE also supports EO and DO calls to/from CUCM/SIP SP. More often than not, SIP
SPs require an EO and CUCM to do both DO and EO to CUBE. However, even if CUCM
is sending a DO INVITE, CUBE can reinitiate the call leg out to the SIP SP as an EO
INVITE (with SDP). Delayed Offer to Early Offer (DO-EO) interworking can use CUBE
flow-through or flow-around. Table 9-2 describes the EO and DO relationship with SIP
INVITE (with and without SDP).
Table 9-2
CUBE DO and EO
Early Offer (EO)
Offer
SDP in INVITE
No SDP in INVITE
Answer
SDP in 180/183
SDP in 200
Figure 9-16 gives an overview of a CUCM to CUBE DO and CUBE to SIP SP EO call
setup. Note that not all call signaling events are shown; the emphasis is on CUBE performing DO-EO for SIP INVITE and consequent events.
CUCM
CUBE
SIP SP
Network
INVITE (Without SDP)
RTP
RTP
IP Phone
Figure 9-16
PSTN Phone
280
For example, when an SCCP endpoint registered with CUCM tries to call a toll-free
number in the SIP (PSTN) cloud, the call signaling passes through CUCM to CUBE (via
H.323 trunk to CUBE), from CUBE to the SIP SP (via SIP trunk) softswitch, and finally
to the destination PBX/phone. On the way, there is a requirement for DTMF interworking
between the H.323 incoming dial peer on CUBE from CUCM and the SIP outgoing dial
peer to the SIP SP, and the appropriate DTMF type must be configured at the incoming
and outgoing dial peers as shown in Example 9-34.
Example 9-34 CUBE DTMF Interworking Configuration
CUBE(config)# dial-peer voice 190 voip
CUBE(config-dial-peer)# description Calls to/From CUCM
CUBE(config-dial-peer)# destination-pattern 42618...$
CUBE(config-dial-peer)# session target ipv4:10.76.108.240
CUBE(config-dial-peer)# incoming called-number .
CUBE(config-dial-peer)# dtmf-relay h245-alphanumeric
CUBE(config-dial-peer)# codec g711ulaw
CUBE(config-dial-peer)# no vad
!
CUBE(config)# dial-peer voice 191 voip
CUBE(config-dial-peer)# description Calls to/From
SIP-SP
CUBE(config-dial-peer)# destination-pattern 9T
CUBE(config-dial-peer)# session protocol sipv2
CUBE(config-dial-peer)# session target ipv4:X.X.X.X
CUBE(config-dial-peer)# incoming called-number 4082228...$
CUBE(config-dial-peer)# dtmf-relay rtp-nte
CUBE(config-dial-peer)# codec g711ulaw
CUBE(config-dial-peer)# no vad
SIP
SIP
H323
H.323
NOTIFY
NOTIFY
H.245H.245Alphanumeric Alphanumeric
H.245NOTIFY
Alphanumeric
RFC 2833
NOTIFY
H.245-Signal
H.245-Signal
H.245-Signal
NOTIFY
RFC 2833
RFC 2833
RFC 2833
RFC 2833
RFC 2833
NOTIFY
NOTIFY
KPML
H.245RFC 2833
Alphanumeric
H.245RFC 2833
Alphanumeric
RFC 2833
KPML
H.245-Signal
H.245-Signal
RFC 2833
KPML
KPML
RFC 2833
RFC 2833
RFC 2833
H323
SIP
SIP
SIP
H323
H.323
H323
281
SIP
H.245KPML
Alphanumeric
H.245-Signal
KPML
Its important to note that DSPs are required only for the voice in-band to RFC 2833
DTMF conversion.
Also, CUBE supports DTMF interworking to enable a delay between the dtmf-digit
begin and dtmf-digit end events in the RFC 2833 packets or to generate RFC 4733
compliant rtp-nte packets. The command dtmf-interworking has the following options:
rtp-nte: Used to introduce a delay between the dtmf-digit begin and dtmf-digit end
events in the RFC 2833 packet if the remote system cannot handle RFC 2833 packets sent in a single burst. This option is available under (global) voice service voip
and dial-peer.
Preserve-codec: Helps preserve the established codec and denies any codec (midcall) changes.
282
CUCM
CUBE
SIP SP
Network
Call Is Established
Call Is Established
Mid-Call Signaling
Passthru
IP Phone
Mid-Call RE-INVITE
(with Media Type Change)
PSTN Phone
RE-INVITE (with SDP)
200 OK
200 OK
ACK
ACK
Call Is Established
Call Is Established
Mid-Call Signaling
Block
IP Phone
PSTN Phone
Mid-Call RE-INVITE
200 OK
ACK
Figure 9-17
Example 9-35 shows the configuration of mid-call signaling options at (global) voice service voip and dial-peer level.
Example 9-35 CUBE Mid-Call Signaling Configuration
CUBE(conf)# voice service voip
CUBE(config-voi-serv)# sip
CUBE(config-serv-sip)# midcall-signaling [block | passthru | preserve-codec]
!
CUBE(conf)# dial-peer voice 180 voip
CUBE(config-dial-peer)# voice-class sip midcall-signaling [block | passthru |
preserve-codec]
Chapter 10
Every Cisco Collaboration network requires diligent planning and deployment for an
organization to leverage the many services that it has to offer. However, the ongoing
maintenance and management of a Cisco Collaboration solution is equally important
to ensure that the services provided remain uninterrupted. This chapter covers the
management aspect of a Cisco Collaboration solution.
010_9780133845969_ch10.indd 283
6/25/14 11:39 AM
284
2 Replication is good: Logical connections are established and tables match the
other servers on the cluster.
3 Tables are suspect: Logical connections are established, but tables dont match.
4 Database Setup Failed/dropped: The server no longer has an active logical connection to receive a database table, and no replication takes place in this state.
CUCM Publisher
Full DB Access
(System and User Facing
Features)
CUCM Subscribers
Partial DB Access
(User Facing Features)
Figure 10-1
CUCM Subscribers
Partial DB Access
(User Facing Features)
Feature Service
Description
Cisco CallManager
Cisco IP Voice Media Streaming Provides media services such as Annunciator, MoH, conferApplication
ence bridges, transcoders, MTP, and so on.
Feature Service
Description
Cisco CTIManager
285
Cisco Dialed Number Analyzer Supports the CUCM Dialed Number Analyzer tool.
Cisco DHCP Monitor Service
Cisco Dialed Number Analyzer Supplements DNA service (can be activated on one or more
Server
nodes in a cluster).
Cisco TFTP
Simple Object Access Protocol (SOAP)/HTTPS-based service for third-party Call Detail Record (CDR) solutions.
Cisco Bulk Provisioning Service Responsible for Bulk Administration Tool (BAT) for bulk
administration of users and phones.
Cisco AXL Web Service
286
Feature Service
Description
Cisco DirSync
Table 10-2
Network Service
Description
RIS maintains real-time information including device status, performance counters, alarms, and so on.
Cisco DB
Cisco DB Replicator
MIB2 Agent
Network Service
Description
287
Cisco Certificate Expiry Monitor Enables monitoring for CUCM certificate expiry.
Cisco Certificate Change
Notification
Cisco Tomcat
Cisco SOAP-Performance
Monitoring APIs
Cisco SOAP-Log Collection APIs Allows collection of log files for APIs.
SOAP - Diagnostic Portal
Database Service
288
Network Service
Description
Cisco E911
Cisco CAR DB
CAR DB service.
289
of more than one call. The CDR agent service pushes flat files from call processing
subscriber(s) to the CDR Repository Manager on the publisher node. CUCM also provides a web application known as CDR Analysis and Reporting (CAR) that can be used
to analyze the CDRs. The CAR Scheduler service runs only on the publisher node and
enables reading the contents of the flat files and writes the same into the CAR database.
The CDR Repository Manager keeps the files in the preserve folder at file list activelog /
cm/cdr_repository/preserve/<YYYYMMDD>/.
CDR flat files can be in various states, namely:
car/yyyymmdd: CAR Scheduler service uses soft links to determine what files need
to be processed by the CDR Loader.
destinationx/yyyymmdd: CDR Repository Manager service uses soft links to determine what files need to be transferred to billing server.
To add a CDR billing (an external third-party) server, go to Tools > CDR Management
Configuration and add a new billing server.
CDRs
CMRs
Similarly, Cisco Unity Connection, Cisco UCCX, and Cisco IM and Presence servers also
offer a DRS solution that enables a Cisco Collaboration network administrator to schedule backups and leverage them in case a server needs to be rebuilt.
DRS utilizes Cisco Disaster Recovery Framework (DRF) service and enables administrators to initiate a manual or automatic (scheduled) backup. DRS permits CUCM administrators to schedule backup on all seven days of the week (recommended practice) or
select specific days when backup should take place. It also allows setting the maximum
290
number of backups (minimum 1 and maximum 14) to be stored on a network share. DRS
uses SFTP to store a backup file with a .tar extension on an SFTP repository. DRS can
also store a backup on a tape drive. However, this option is supported only with a physical server, not on a virtual machine. To access CUCM DRS, go to https://<ip address or
hostname of server>/drf.
To set up CUCM DRS for backup, follow these steps.
Step 1.
Go to Disaster Recovery System > Backup > Backup Device and add a new
backup device. Enter the required details for the network share, such as SFTP
server credentials, directory, and so on. Click Save.
Step 2.
Navigate to Backup > Scheduler, provide a name for the schedule, and
choose the backup device created previously. Additionally, select the frequency of the backup. Click Save.
Step 3.
To run a restore login, go to CUCM DRS, choose Restore > Restore Wizard, and follow
the prompts.
While restoring, the important thing to remember is that the CUCM server being restored
has the exact same CUCM version and patch level as the previous server. Moreover,
although not mandatory, it is recommended to back up each server in a CUCM cluster
so that the manually uploaded TFTP files such as ring lists, backgrounds, and so on are
backed up.
User Management
The Cisco Collaboration solution offers users a range of services and facilities that they
can leverage. CUCM has a full-fledged, built-in user management system to assist administrators with user management.
CUCM has two types of users:
End users: Created for actual physical users and support an interactive login. These
users can be associated with endpoints, devices, and applications so that the user
can control IP Phones, personalize some commonly used features, and leverage
Cisco UC features. End users can be created in CUCM or can be synced with an
LDAP server such as Microsoft Active Directory, OpenLDAP, iPlanet, and so on.
User Management
291
LDAP directories are based on the X.500 standard and are a specialized database that
contains information about end users such as username, user department, user phone
number, user password, user email address, and so on. Syncing CUCM with LDAP provides applications the capability to get all user information from a single repository available to several applications, with a remarkable reduction in maintenance costs through the
ease of adds, moves, and changes. By default, all users are provisioned manually in the
publisher database through CUCM Administration User Management > End Users.
CUCM users can be synced with Cisco Unity Connection and Cisco IM and Presence
via an AXL/SOAP interface. Hence, the existing users can be imported into the aforesaid
applications even without having them directly integrated with the LDAP server, making
CUCM a single point of contact with LDAP. Alternatively, Cisco Unity Connection and
Cisco IM and Presence servers can be directly integrated with LDAP.
End users can be further classified into two types:
Core users: End users that have usually one or two devices assigned to them. They
are expected to have a single line and commonality across all devices assigned to
them. In other words, instead of managing devices one by one, core users can add on
one device a feature/service such as speed dial, and it applies to all the devices that
the user has.
Advanced users: Users that have multiple phones with one or more lines on each
device. They are expected to have multiple devices with multiple lines so they can
pick and choose between devices, lines, and Cisco Collaboration services they wish
to leverage.
CUCM 9.x offers the ability to manage both LDAP synced and local users; for example,
administrators can have local users coexist with LDAP synced users. Moreover, CUCM
offers the ability to modify local users and roles assigned to LDAP users and convert an
LDAP user to a local user (by checking the Convert LDAP Synchronized User to Local
User check box on the user page). Figure 10-2 illustrates LDAP and local users coexisting
on a CUCM server.
Figure 10-2
292
Note in the User Status column that the User Status field can be employed to differentiate between local users and LDAP synchronized users.
The CUCM end user web page and associated options can be accessed via https://<IP
address or hostname of CUCM server>/ucmuser. CUCM users can be added or details
can be modified in bulk using Bulk Administration Tool (BAT). BAT provides multiple
options such as Users, Phones and Users, Manager/Assistants, and User Device Profile
for various user-related operations. The Cisco Collaboration networks user management
automation and associated tasks can also be achieved by utilizing Prime Collaboration
Provisioning (part of Cisco Prime Collaboration Suite). User management can be accomplished by browsing to Administration > User Management.
Cisco EnergyWise
Cisco EnergyWise is an energy (power) management solution that enables the IT and
facility managers to administer and monitor energy consumption to manage network and
connected devices, including switches, routers, Power over Ethernet (PoE)-capable endpoints, and so on, using their existing network infrastructure.
The following are characteristics of EnergyWise:
Uses the network to measure, monitor, and manage energy, allowing the network to
be the command and control plane for power management.
Uses the network to aggregate power usage reporting while simultaneously allowing
the network to provide secure, reliable energy management.
Uses the network effect to provide services such as location and presence for energy
management.
Domain: A logical grouping of Cisco devices such as Cisco switches and routers. A
domain is a single unit of energy management. Domain members share neighbor relationships with each other.
Domain members: Switches, routers, and network controllers. They resemble endpoints in that they draw power. However, domain members can work together to
propagate EnergyWise messages across the network, to form an EnergyWise cloud.
For endpoints, Cisco IOS switches and routers act as parents.
Cisco EnergyWise
293
EnergyWise Managers: EnergyWise management can be done via control applications and devices that use Cisco EnergyWise features to measure, monitor, and
manage power consumption. Cisco EnergyWise has two management options:
SNMP-MIB, whereby the MIB provides power information of a domain member and
its attached endpoints, and the Toolkit Management API, which makes use of Cisco
EnergyWise queries to manage and control the entire domain.
EnergyWise Manager
EnergyWise
Cloud
Cisco Switch
(Domain Member)
Parents
Cisco Switch
(Domain Member)
Cisco Router
(Domain Member)
Cisco Switch
(Domain Member)
Children
Cisco Jabber
(Endpoint)
Figure 10-3
Cisco Unified
IP Phone
(Endpoint)
PC
(Endpoint)
Cisco Unified
IP Phone
(Endpoint)
294
Upon configuring an EnergyWise domain on a Cisco IOS device, EnergyWise is activated automatically. Cisco EnergyWise (domain) configuration and parent-child relationships can be discovered by following the commands in Example 10-1.
Example 10-1 EnergyWise CLI Commands
UCSwitch# show energywise
Module/
Interface
Role
Name
Usage
Category
Lvl
Imp
Type
---------
----
----
-----
--------
---
---
----
UCSwitch-1
101.0 (W)
10
WS-C3750E-24PD
consumer
parent
Subtotals: (Consumer: 101.0 (W), Meter: 0.0 (W), Producer: 0.0 (W))
Total: 101.0 (W), Count: 1
: UCSwitch-1
Domain
: CORP.LOCAL
Protocol
: udp
IP
: 10.86.108.254
Port
: 54000
Cisco EnergyWise
Interface
---------
Role
Name
Usage
Category
--------
Lvl
Imp
295
Type
----
----
-----
---
---
----
WS-C3750E-24PD
UCSwitch-1
10
parent
Gi1/0/3
IP Phone 9971
SEP64AE0CF66C0D
7.5 (W)
consumer
10
PoE
Gi1/0/5
IP Phone 9971
SEP10BD18DC97F5
7.1 (W)
consumer
10
PoE
Gi1/0/6
IP Phone 9951
SEPE84040A24BBD
6.0 (W)
consumer
10
PoE
Subtotals: (Consumer: 121.6 (W), Meter: 0.0 (W), Producer: 0.0 (W))
Total: 121.6 (W), Count: 4