Page 1
Cisco TelePresence
Video Communication
Server
Administrator Guide
D14049.10
April 2011
Software version: X6.1
Page 2
Contents
Contents
Contents 2
About the Cisco TelePresence Video Communication Server (VCS) 16
VCS base applications 16
VCS Control 16
VCS Expressway™ 16
Standard features 17
Optional features 17
FindMe™ 18
Device Provisioning 18
Dual Network Interfaces 18
About this guide 19
Typographical conventions 19
Installation and initial configuration 19
Using the web interface 20
Required fields 20
How page navigation is shown in this guide 20
Supported browsers 20
Using the command line interface (CLI) 21
Command types 21
Web page features and layout 22
What’s new in this version? 24
Session management 24
Client certificate-based authentication 24
Automatic updating of CRLs (certificate revocation lists) 24
Cisco AM GW available on VCS Expressway 24
Movi ClearPath provisioning 24
Improved cluster set-up process 24
Presence configuration 24
Overview and status information 25
Status overview 25
System information 26
Cisco VCS Administrator Guide (X6.1) Page 2 of 401
Page 3
Contents
Ethernet status 27
IP status 28
Resource usage 29
Active administrator sessions 29
Active user sessions 29
Registration status 29
Registrations by device 29
Registrations by alias 30
Registration history 31
Registration details 32
Call status 32
Call status 32
Call history 33
Call summary 34
Call details 34
Call media details 34
Search history 35
About searches 35
Search history list 35
Search details 36
Local Zone status 36
Zone status 37
Link status 37
Pipe status 37
Policy service status 38
TURN relays status 38
Presence 39
Presence publishers 39
Presence presentities 39
Presence subscribers 40
OCS Relay status 40
Provisioning status 41
Provisioning server 41
Cisco VCS Administrator Guide (X6.1) Page 3 of 401
Page 4
Contents
Phone book server 41
Warnings 41
Hardware status 42
Event Log 42
Configuration Log 43
VCS unit front panel 44
Network and system settings 45
Configuring IP settings 45
Configuring Ethernet settings 46
Configuring DNS settings 46
Configuring Quality of Service settings 47
Configuring system name and access settings 48
Configuring SNMP settings 51
Configuring time zone and NTP server settings 52
Configuring the Login page 53
Configuring external manager settings 53
Configuring logging levels 54
Event Log levels 54
Remote logging 55
Protocols 56
About H.323 56
Using the VCS as an H.323 gatekeeper 56
H.323 endpoint registration 56
About SIP 56
VCS as a SIP registrar 57
VCS as a SIP proxy server 58
Proxying registration requests 58
VCS as a SIP Presence Server 59
H.323 configuration 59
SIP configuration 60
Configuring SIP domains 62
Configuring SIP and H.323 interworking 62
Searching by protocol 62
Cisco VCS Administrator Guide (X6.1) Page 4 of 401
Page 5
Contents
Enabling SIP endpoints to dial H.323 numbers 63
Registration control 64
About registrations 64
Finding a VCS with which to register 64
Registrations on a VCS Expressway 64
MCU, gateway and Content Server registration 65
Configuring registration restriction policy 65
Registering aliases 66
H.323 66
SIP 67
Attempts to register using an existing alias 67
Blocking registrations 67
Removing existing registrations 67
Re-registrations 67
About Allow and Deny Lists 68
Configuring the registration Allow List 68
Configuring the registration Deny List 69
Device authentication 70
About device authentication 70
Authentication Policy 70
Authentication mechanism 70
Authentication Policy configuration options 71
Zone-level Authentication Policy 71
Subzone-level Authentication Policy 73
SIP authentication trust 74
Device authentication configuration 75
Authentication database 75
Endpoint credentials used for authentication 75
Device authentication using LDAP 75
Authentication process 75
LDAP server settings 76
Device LDAP schemas 77
Authentication using a local database 78
Cisco VCS Administrator Guide (X6.1) Page 5 of 401
Page 6
Contents
Authenticating with external systems 78
Zones and neighbors 79
About your video communications network 79
Example network diagram 79
Structuring your dial plan 80
Flat dial plan 80
Structured dial plan 80
Hierarchical dial plan 80
About the Local Zone and subzones 81
Bandwidth management 81
Local Zone searches 81
About zones 82
Default Zone 82
Zone configuration 82
Configuring neighbor zones 83
Configuring traversal client zones 86
Configuring traversal server zones 88
Configuring ENUM zones 91
Configuring DNS zones 92
Zone configuration: advanced settings 93
Zone configuration: pre-configured profile settings 98
TLS certificate verification of neighbor systems 99
Clustering and peers 100
About clusters 100
About the configuration master 101
Secure communication between peers 101
Alternates 101
Setting up a cluster 101
Maintaining a cluster 102
Cluster name 102
Cluster pre-shared key 102
Setting configuration for the cluster 102
Adding and removing peers from a cluster 102
Cisco VCS Administrator Guide (X6.1) Page 6 of 401
Page 7
Contents
Changing the master peer 102
Monitoring the status of the cluster 103
Configuration that is not replicated across a cluster 103
Troubleshooting cluster replication problems 104
Managing clusters and peers 105
Sharing registrations across peers 105
Sharing bandwidth across peers 105
Cluster upgrades and downgrades 106
Cluster backup and restore 106
Clustering and FindMe 106
Clustering and Presence 107
Clustering and TMS 107
About the Cluster Subzone 107
Neighboring the local VCS to another VCS cluster 108
TMS Agent replication status 109
Dial plan and call processing 110
Call routing process 110
How the VCS determines the destination of a call 110
About the VCS's directory service 112
About hop counts 112
Configuring hop counts 112
About transforms and search rules 112
Transforms 113
Search rules 113
Dial plan configuration 113
About the fallback alias 114
About pre-search transforms 115
Pre-search transform process 115
Configuring pre-search transforms 115
Search and zone transform process 117
Configuring search rules 118
Example searches and transforms 120
Filter queries to a zone without transforming 121
Cisco VCS Administrator Guide (X6.1) Page 7 of 401
Page 8
Contents
Always query a zone with original alias (no transforms) 121
Query a zone for a transformed alias 122
Query a zone for original and transformed alias 123
Query a zone for two or more transformed aliases 124
Stripping @domain for dialing to H.323 numbers 125
Transforms for alphanumeric H.323 ID dial strings 127
Allowing calls to IP addresses only if they come from known zones 129
Configuring policy services 129
About Call Policy 131
Configuring Call Policy 131
Configuring Call Policy rules using the web interface 133
Configuring Call Policy using a CPL script 134
Configuring VCS to use the Cisco TelePresence Advanced Media Gateway 135
Configuring the VCS 135
Usage features and limitations 135
Configuring Cisco AM GW policy rules 136
Dialable address formats 137
Dialing by IP address 138
Dialing by H.323 ID or E.164 alias 138
Dialing by H.323 or SIP URI 138
Dialing by ENUM 138
IP dialing 139
Calls to unknown IP addresses 139
About URI dialing 140
URI dialing without DNS 140
URI dialing via DNS 141
URI resolution process using DNS 141
URI dialing via DNS for outgoing calls 142
URI dialing via DNS for incoming calls 144
URI dialing and firewall traversal 146
About ENUM dialing 146
ENUM dialing process 146
Enabling ENUM dialing 147
Cisco VCS Administrator Guide (X6.1) Page 8 of 401
Page 9
Contents
ENUM dialing for outgoing calls 147
Zone configuration for ENUM dialing 149
ENUM dialing for incoming calls 150
Configuring DNS servers for ENUM and URI dialing 151
Configuring a zone for incoming calls only 151
Call signaling configuration 152
Identifying calls 153
Disconnecting calls 154
Disconnecting a call using the web interface 154
Disconnecting a call using the CLI 154
Limitations when disconnecting SIP calls 154
Bandwidth control 156
About bandwidth control 156
Example network deployment 156
Bandwidth configuration 157
About downspeeding 158
About subzones 158
Default links between subzones 158
About the Traversal Subzone 158
About the Default Subzone 159
Configuring subzones 159
Configuring subzone membership rules 160
Applying bandwidth limitations to subzones 162
Links and pipes 163
Configuring links 163
Default links 164
Configuring pipes 164
Applying pipes to links 165
Bandwidth control examples 166
Firewall traversal 169
About firewall traversal 169
Expressway solution 169
How does it work? 169
Cisco VCS Administrator Guide (X6.1) Page 9 of 401
Page 10
Contents
VCS as a firewall traversal client 170
VCS as a firewall traversal server 170
Configuring traversal server zones 170
Configuring other traversal server features 170
Quick guide to VCS traversal client - server configuration 170
Firewall traversal protocols and ports 172
Expressway process 172
H.323 firewall traversal protocols 172
SIP firewall traversal protocols 172
Ports for initial connections from traversal clients 172
Default port summary 173
TURN ports 173
Ports for connections out to the public internet 174
Firewall traversal and authentication 174
Authentication and NTP 176
Firewall traversal and Dual Network Interfaces 176
Firewall configuration 176
Configuring traversal for endpoints 176
Configuring traversal server ports 177
About ICE and TURN services 178
About ICE 178
About TURN 178
TURNrelay server 178
Configuring TURN services 179
TURN relay status information 180
Applications 181
Conference Factory 181
Conference creation process 181
About Presence 182
Presence Server 183
Presence User Agent (PUA) 183
Configuring Presence 184
OCS Relay 186
Cisco VCS Administrator Guide (X6.1) Page 10 of 401
Page 11
Contents
Configuring a connection between the VCS and the OCS 186
About FindMe™ 187
How are devices specified? 187
FindMe process overview 187
Who must do what before FindMe can be used? 188
Recommendations when deploying FindMe 188
Example 188
Configuring FindMe 188
Searching for FindMe users 190
About provisioning (Starter Pack) 191
Starter Pack 191
Device authentication 191
Phone book support 191
Configuring provisioning 191
Maintenance 193
About upgrading software components 193
VCS software components 193
Prerequisites 193
Backing up before upgrading 194
Upgrading and option keys 194
Installing and rebooting 194
Upgrade procedure 194
Upgrading using secure copy (SCP/PSCP) 195
Option keys 196
Adding option keys using the web interface 196
Adding option keys using the CLI 197
About security certificates 197
Managing security certificates 197
CRL management 198
Certificate-based authentication configuration 199
Client certificate testing 201
Advanced account security 202
Prerequisites 202
Cisco VCS Administrator Guide (X6.1) Page 11 of 401
Page 12
Contents
VCS functionality: changes and limitations 203
Configuring language settings 203
Changing the language 203
Installing language packs 204
About login accounts 204
Account authentication 204
Administrator accounts 204
User accounts 205
Root accounts 205
Configuring login account authentication 205
Account authentication using LDAP 205
Login history 207
Root account 207
Resetting an administratoror root password 208
Resetting user account passwords 208
Configuring administrator accounts 209
Password strength 209
Configuring administrator groups 211
Configuring user accounts 211
Principal devices (StarterPack only) 213
Configuring user groups 214
Backing up and restoring VCS data 215
Limitations 215
Creating a backup 216
Restoring a previous backup 216
Creating a system snapshot 217
Incident reporting 217
Incident reporting warning: privacy-protected personal data 217
Sending incident reports automatically 218
Sending incident reports manually 218
Viewing incident reports 218
Incident report details 219
Checking the effect of a pattern 219
Cisco VCS Administrator Guide (X6.1) Page 12 of 401
Page 13
Contents
Locating an alias 220
Port usage 220
Local VCS inbound ports 221
Local VCS outbound ports 221
Remote listening ports 221
Restarting 222
Restarting using the web interface 222
Rebooting 222
Rebooting using the web interface 223
Shutting down 223
Shutting down using the web interface 223
Shutting down using the CLI 223
Reference material 224
Software version history 225
X6 225
X5.2 226
X5.1 227
X5 230
X4 232
About Event Log levels 234
Event Log format 234
Administrator and FindMe user events 234
Message details field 235
Events and levels 237
CPL reference 244
CPL address-switch node 244
otherwise 246
not-present 246
location 247
rule-switch 247
proxy 248
reject 248
Unsupported CPL elements 248
Cisco VCS Administrator Guide (X6.1) Page 13 of 401
Page 14
Contents
CPL examples 249
LDAP configuration for device authentication 256
Downloading the H.350 schemas 256
Configuring a Microsoft Active Directory LDAP server 256
Configuring an OpenLDAP server 258
DNS configuration examples 261
Verifying the SRV record 261
Microsoft DNS server 261
BIND 8 & 9 261
Changing the default SSH key 262
Default SSH key warnings 262
Standalone VCS 262
Clustered VCS 262
Restoring default configuration 263
Configuration items reset by DefaultValuesSet level 3 263
Configuration items reset by DefaultValuesSet level 2 264
Password encryption 266
Maximum length of passwords 266
Pattern matching variables 267
Port reference 269
Regular expressions 275
Supported characters 277
Case sensitivity 277
TMS Agent 278
FindMe 278
Device Provisioning 278
TMS Agent account passwords 278
TMS Agent passwords 279
TMS Agent LDAP and replication accounts 279
VCSs managed by TMS 279
VCSs not managed by TMS 279
What are traversal calls? 281
Warnings list 282
Cisco VCS Administrator Guide (X6.1) Page 14 of 401
Page 15
Contents
Command reference — xConfiguration 287
xConfiguration commands 287
Command reference — xCommand 351
xCommand commands 351
Command reference — xStatus 372
xStatus elements 372
About policy services 387
Policy service request parameters 387
Policy service responses 388
Bibliography 389
Glossary 392
Legal notices 400
Intellectual property rights 400
Copyright notice 400
Patent information 400
Disclaimers and notices 401
Cisco VCS Administrator Guide (X6.1) Page 15 of 401
Page 16
About the Cisco TelePresence Video Communication Server (VCS)
About the Cisco TelePresence Video
Communication Server (VCS)
The Cisco TelePresence Video Communication Server (VCS) enhances the video experience and
provides seamless communication between SIP and H.323 devices utilizing IETF and ITU standards.
The VCS is the center of the video communication network, and connects all H.323 and SIP
endpoints, infrastructure, and management devices. It provides unrivaled scalability and redundancy
to video communications, and is integral to Cisco interoperability with unified communications and
Voice over IP systems.
The VCS can be deployed with either the Control application or the Expressway™ application, with
various optional packages including FindMe™, Dual Network Interfaces and Device Provisioning.
VCS base applications
The VCS is available with alternative base applications as described below.
VCS Control
The VCS Control provides internal video control and administration for all SIP and H.323 devices. It is
normally deployed within your wide area network with endpoints that are behind the same firewalls or
NAT devices. The VCS Control replaces the need to have separate H.323 gatekeeper, SIP registrar
and H.323 - SIP gateway servers.
VCS Expressway™
The VCS Expressway provides standards-based firewall traversal for SIP and H.323 devices allowing
secure firewall traversal of any firewall or NAT device. As well as all the functionality of a VCS
Control, it also provides registration of traversal-enabled devices and can act as a standards-based
TURN server.
The VCS Expressway is normally deployed outside of your firewall or within the DMZ.
Cisco VCS Administrator Guide (X6.1) Page 16 of 401
Page 17
About the Cisco TelePresence Video Communication Server (VCS)
Standard features
The VCS has the following standard features:
n 2500 endpoint registrations
n H.323 gatekeeper
n SIP Proxy/Registrar
n SIP Presence Server
n SIP Presence User Agent
n SIP and H.323 support, including SIP/H.323 gatewaying
n IPv4 and IPv6 support, including IPv4/IPv6 gatewaying
n QoS tagging
n Bandwidth management on both a per-call and a total usage basis, configurable separately for calls
within the local subzones and to external systems and zones
n Automatic downspeeding option for calls that exceed the available bandwidth
n URI and ENUM dialing via DNS, enabling global connectivity
n Up to 500 non-traversal calls
n Up to 100 traversal calls
n 1000 external zones with up to 2000 matches
n 1000 subzones and supporting up to 3000 membership rules
n Flexible zone configuration with prefix, suffix and regex support
n Can function as a standalone VCS or be neighbored with other systems such as VCSs, Border
Controllers, gatekeepers and SIP proxies
n n+1 redundancy, can be part of a cluster of up to 6 VCSs for increased capacity and redundancy
n Intelligent Route Director for single number dialing and network failover facilities
n Optional endpoint authentication
n Control over which endpoints are allowed to register
n Call Policy (also known as Administrator Policy) including support for CPL
n Can be managed with Cisco TelePresence Management Suite (TMS) 12.5 or later
n AD authentication for administrators of the VCS
n Pre-configured defaults for:
l Cisco Unified Communications Manager neighbor zones
l Cisco TelePresence Advanced Media Gateway
l Microsoft Office Communications Server (OCS) 2007 neighbor zones
l Nortel Communication Serverneighbor zones
n Embedded setup wizard using a serial port for initial configuration
n System administration using a web interface or RS-232, Telnet, SSH, and HTTPS
Optional features
The following features are available on the VCS by the purchase and installation of the appropriate
option key:
Cisco VCS Administrator Guide (X6.1) Page 17 of 401
Page 18
About the Cisco TelePresence Video Communication Server (VCS)
FindMe™
A unique industry solution that gives individual video users a single alias on which they can be
contacted regardless of location. Users have the ability to log on to a Web-based interface and control
where and how they are contacted. The FindMe feature also includes support for Microsoft Office
Communications Server (OCS) 2007, enabling FindMe aliases to register as Microsoft Office
Communicator (MOC) clients, and MOC clients to view the presence status of FindMe aliases.
Device Provisioning
The Device Provisioning option key allows VCS to provision endpoints with configuration information
on request and to supply endpoints with phone book information. (Endpoints including Movi v2.0 or
later, and E20 v2.1 or later can request to be provisioned.) All configuration andphone book
information is managed in TMS, and distributed to the clients through the TMS Agent running on the
VCS. The TMS Agent on the VCS also provides TMS with the provisioned client’s status.
There is no configuration associated with Device Provisioning on the VCS – it is either on or off,
depending on whether or not the option key is installed. See the TMS documentation and the
Provisioning deployment guide [26].
Dual Network Interfaces
Enables the LAN 2 Ethernet port on the VCS Expressway, allowing you to have a secondary IP
address for your VCS.
This option also includes support for deployments where a VCS Expressway is located behind a static
NAT device, allowing it to have separate public and private IP addresses.
This configuration is intended for high-security deployments where the VCS Expressway is located in
a DMZ between two separate firewalls on separate network segments.
Cisco VCS Administrator Guide (X6.1) Page 18 of 401
Page 19
About the Cisco TelePresence Video Communication Server (VCS)
About this guide
This Administrator Guide is provided to help you make the best use of your VCS.
Your approach to this documentation depends on what you want to do and how much you already
know. The Administrator Guide has been divided into several sections, providing conceptual,
configuration and reference information about the various features and capabilities of the VCS.
This Administrator Guide describes a fully equipped version of the VCS. Your version may not have all
the described extensions installed.
Our main objective with this Administrator Guide is to address your goals and needs. Please let us
know how well we succeeded!
Typographical conventions
Most configuration tasks on the VCS can be performed by using eitherthe web interface or a
command line interface (CLI).
This guide mainly describes how to use the web interface. Some VCS features are only available
through the CLI and these are described as appropriate, including the relevant CLI command.
In this guide, instructions for performing a task using the web interface are shown in the format:
n Menu > Submenu
followed by the Name of the page that you will be taken to.
Where command line interface (CLI) commands are included, they are shown in the format:
n
xConfiguration <Element> <SubElement>
n
xCommand <Command>
Installation and initial configuration
Full installation and initial configuration instructions for the VCS are contained in the VCS Getting
Started Guide [28].
Cisco VCS Administrator Guide (X6.1) Page 19 of 401
Page 20
About the Cisco TelePresence Video Communication Server (VCS)
Using the web interface
Configuration of the VCS is normally carried out through the web interface.
To use the web interface:
1. Open a browser window and in the address bar type either:
l the IP address of the system
l the FQDN of the system
2. Click Administrator Login.
3. Enter a valid administrator Username and Password and click Login (see the Login accounts
section for details on setting up administratoraccounts). You are presented with the Overview
page.
Note that when logging in using the VCS web interface, you may receive a warning message regarding
the VCS's security certificate. This can safely be ignored.
A command line interface is also available.
Required fields
All mandatory fields on web pages are indicated by a red star .
How page navigation is shown in this guide
Instructions for navigating the web interface are shown in the format Menu option 1 > Menu option
2 followed by the Name of the page that you are taken to in order to perform a task.
Supported browsers
The VCS web interface is designed for use with Internet Explorer 6 or later, and Firefox 2 or later. It
may work with Opera and Safari, but you could encounter unexpected behavior.
Javascript and cookies must be enabled to use the VCS web interface.
Cisco VCS Administrator Guide (X6.1) Page 20 of 401
Page 21
About the Cisco TelePresence Video Communication Server (VCS)
Using the command line interface (CLI)
The VCS can be configured through a web interface or via a command line interface (CLI).
The CLI is available by default over SSH and through the serial port. Access using Telnet can also be
enabled. These settings are controlled on the System administration page.
To use the CLI:
1. Start an SSH or Telnet session.
2. Enter the IP address or FQDN of the VCS.
3. Log in with a username of admin and your system password.
4. You can now start using the CLI by typing the appropriate commands.
Command types
Commands are divided into the following groups:
n xStatus: these commands return information about the current status of the system. Information
such as current calls and registrations is available through this command group. See Command
reference — xStatus for a full list of xStatus commands.
n xConfiguration: these commands allow you to add and edit single items of data such as IP
address and zones. See Command reference — xConfiguration for a full list of xConfiguration
commands.
n xCommand: these commands allow you to add and configure items and obtain information. See
Command reference — xCommand for a full list of xCommand commands.
n xHistory: these commands provide historical information about calls and registrations.
n xFeedback: these commands provide information about events as they happen, such as calls and
registrations.
Note that:
n Typing an xConfiguration path into the CLI returns a list of values currently configured for that
element (and sub-elements where applicable).
n Typing an xConfiguration path into the CLI followed by a ? returns information about the usage
for that element and sub-elements.
n Typing an xCommand command into the CLI with or without a ? returns information about the usage
of that command.
Cisco VCS Administrator Guide (X6.1) Page 21 of 401
Page 22
About the Cisco TelePresence Video Communication Server (VCS)
Web page features and layout
This section describes the features that can be found on some or all of the web interface pages.
The elements included in the example web pages shown here are described in the table below.
Page
element
Description
Page name
and
location
Every page shows the page name and the menu path to that page. Each part of
the menu path is a link; clicking on any of the higher level menu items takes you
to that page.
System
warning
This icon appears on the top right corner of every page when there is a system
warning in place. Click on this icon to go to the Warnings page which gives
information about the warning and its suggested resolution.
Help This icon appears on the top right corner of every page. Clicking on this icon
opens a new browser window with help specific to the page you are viewing. It
gives an overview of the purpose of the page, and introduces any concepts
configured from the page.
Log out This icon appears on the top right corner of every page. Clicking on this icon
ends your administrator session.
Field level
information
An information box appears on the configuration pages whenever you either
click on the Information icon or click inside a field. This box gives you
information about the particular field, including where applicable the valid ranges
and default value. To close the information box, click on the X at its top right
corner.
Cisco VCS Administrator Guide (X6.1) Page 22 of 401
Page 23
About the Cisco TelePresence Video Communication Server (VCS)
Page
element
Description
Information
bar
The VCS provides you with feedback in certain situations, for example when
settings have been saved or when you need to take further action. This
feedback is given in a yellow information bar at the top of the page.
Sorting
columns
Click on column headings to sort the information in ascending and descending
order.
Select All
and
Unselect
All
Use these buttons to select and unselect all items in the list.
Mandatory
field
Indicates an input field that must be completed.
Status On configuration pages, this section shows you the current status of the items
you are configuring. Note that some configuration changes require a restart to
take effect, so if you have changed the configuration but not yet restarted this
shows the existing (unchanged) status.
System
Information
The name of the user currently logged in and their access privileges, the system
name (or LAN 1 IPv4 address if no system name is configured), local system
time, currently selected language, hardware serial number and VCS software
version are shown at the bottom of the page.
Note that you cannot change configuration settings if your administrator account has read-only
privileges.
Cisco VCS Administrator Guide (X6.1) Page 23 of 401
Page 24
About the Cisco TelePresence Video Communication Server (VCS)
What’s new in this version?
The new features introduced in this release of VCS software are described below.
Session management
Administrator and user session management features have been introduced. You can:
n specify the maximum number of concurrent administrator sessions (on a total and per-account
basis) allowed on each VCS
n display status details of all active administrator and user sessions
Client certificate-based authentication
Support for certificate-based authentication is provided. This can be combined with a smart card (also
referred to as a Common Access Card or CAC) device to provide two-factor authentication for access
to VCS administration tasks.
Automatic updating of CRLs (certificate revocation lists)
You can now configure CRL distribution points and schedule the VCS to perform automatic CRL
updates. This ensures the latest CRLs are available for certificate validation. Previously CRL updates
had to be uploaded manually.
Cisco AM GW available on VCS Expressway
Cisco AM GW features are now available on both VCS Control and VCS Expressway platforms.
Movi ClearPath provisioning
The Cisco VCS Starter Pack now supports the provisioning of ClearPath to Movi.
Improved cluster set-up process
The process for setting-up a cluster has been simplified such that the replication of configuration and
FindMe information is set up automatically when a new peer is added into a cluster via the web
interface.
Presence configuration
The Subscription expiration time and Publication expiration time settings can no longer be
configured on the Presence page. They can still be modified via the CLI.
Cisco VCS Administrator Guide (X6.1) Page 24 of 401
Page 25
Overview and status information
Overview and status information
You can view information about the current status, registrations, current calls and call history, and
configuration of the VCS by using the Status menu options.
Status overview
The Overview page (Status >Overview) provides an overview of the current status of the VCS (or
VCS cluster, if applicable). This page is displayed by default after logging in to the VCSas an
administrator.
The following information is displayed:
Field Description
System information: many of the items in this section are configurable; click on the item name to be
taken to its configuration page.
System name The name that has been assigned to the VCS.
Up time The amount of time that has elapsed since the system last
restarted.
Software version The version of software that is currently installed on the VCS.
IPv4 address The VCS’s IPv4 addresses.
IPv6 address The VCS’s IPv6 addresses.
Options The maximum number of calls and registrations, and the
availability of additional VCS features such as TURN Relays,
FindMe™, Device Provisioning and Dual Network Interfaces, are
controlled through the use of option keys. This section shows all
the options that are currently installed on the VCS.
Resource usage: this shows summary information about the VCS's resources. If the VCS is part of
a cluster, then details for each peer are shown as well as totals for the entire cluster. To view details
of current calls, registrations or TURN relays (VCS Expressway only), click on the relevant item in
the section.
Non-traversal call licenses Current: the number of non-traversal calls going through the
VCS at this moment.
Peak: the highest number of concurrent non-traversal calls
handled by the VCS since it was last restarted.
Since last restart: the total number of non-traversal calls
handled by the VCS since it was last restarted.
License limit: the number of non-traversal call licenses
available on the VCS.
Cisco VCS Administrator Guide (X6.1) Page 25 of 401
Page 26
Overview and status information
Field Description
Traversal call licenses Current: the number of traversal calls going through the VCS at
this moment.
Peak: the highest number of concurrent traversal calls handled
by the VCS since it was last restarted.
Since last restart: the total number of traversal calls handled by
the VCS since it was last restarted.
License limit: the number of traversal call licenses available on
the VCS.
See What are traversal calls? for details on what constitutes a
traversal call.
Registration licenses Current: the number of aliases registered to the VCS at this
moment.
Peak: the highest number of aliases concurrently registered to
the VCS since it was last restarted.
Since last restart: the total number of registrations to the VCS
since it was last restarted.
License limit: the number of registration licenses available on
the VCS.
TURN relay licenses
(VCS Expressway only)
Current: the number of active TURN relays at this moment.
Peak: the highest number of concurrently active TURN relays
since the VCS was last restarted.
Since last restart: the total number of TURN relays allocated on
the VCS since it was last restarted.
License limit: the total numberof TURN relay licenses
available on the VCS.
System information
The System information page (Status > System > Information) provides details of the software,
hardware, and time settings of the VCS.
Many of the items in the System information and Time information sections are configurable; click
on the item name to be taken to its configuration page.
The following information is displayed:
Field Description
System information section:
System
name
The name that has been assigned to the VCS.
Product This identifies the VCS.
Cisco VCS Administrator Guide (X6.1) Page 26 of 401
Page 27
Overview and status information
Field Description
Software
version
The version of software that is currently installed on the VCS.
Software
build
The build number of this software version.
Software
release
date
The date on which this version of the software was released.
Software
name
The internal reference number for this software release.
Software
options
The maximum number of calls, and the availability of additional VCS features such as
FindMe™, Device Provisioning and Dual Network Interfaces, are controlled through the
use of option keys. This section shows all the optional features currently installed on the
VCS.
Hardware
version
The version number of the hardware on which the VCS software is installed.
Hardware
serial
number
The serial number of the hardware on which the VCS software is installed.
Time information section:
Up time The amount of time that has elapsed since the system last restarted.
System
time
(UTC)
The time as determined by the NTP server.
If no NTP server has been configured, this will show Time Not Set.
Time
zone
The time zone that has been configured on the Time page.
Local
time
If an NTP server has been configured, the system time in local time (UTC adjusted
according to the local time zone) is shown.
If no NTP server has been configured, the time according to the VCS’s operating system
is shown.
Ethernet status
The Ethernet page (Status > System > Ethernet) shows the MAC address and Ethernet speed of the
VCS.
The page displays the following information for the LAN 1 port and, if the Dual Network Interfaces
option key has been installed, the LAN 2 port:
Field Description
MAC
address
The MAC address of the VCS’s Ethernet device for that LAN port.
Cisco VCS Administrator Guide (X6.1) Page 27 of 401
Page 28
Overview and status information
Field Description
Speed The speed of the connection between the LAN port on the VCS and the Ethernet
switch.
The Ethernet speed can be configured via the Ethernet page.
IP status
The IP status page (Status > System > IP) shows the current IP settings of the VCS.
The following information is displayed:
Field Description
IP section:
Protocol Indicates the IP protocol supported by the VCS.
IPv4: it only accepts registrations from endpoints using an IPv4 address, and will only
take calls between two endpoints or devices communicating via IPv4. It will
communicate with other systems via IPv4 only.
IPv6: it only accepts registrations from endpoints using an IPv6 address, and will only
take calls between two endpoints communicating via IPv6. It will communicate with
othersystems via IPv6 only.
Both: it accepts registrations from endpoints using either an IPv4 or IPv6 address, and
takes calls using either protocol. If a call is between an IPv4-only and an IPv6-only
endpoint, the VCS will act as an IPv4 to IPv6 gateway (note that this will require a
traversal call license). The VCS can communicate with other systems via either
protocol.
IPv4
gateway
The IPv4 gateway used by VCS.
IPv6
gateway
The IPv6 gateway used by VCS.
Dual
Network
Interfaces
Indicates whether the second LAN port has been enabled. This is done by installing the
Dual Network Interfaces option key.
LAN 1 Shows the IPv4 address and subnet mask, and IPv6 address of the LAN 1 port.
LAN 2 If the Dual Network Interfaces option key has been installed, this shows the IPv4
address and subnet mask, and IPv6 address of the LAN 2 port.
DNS section:
Server
1..5
address
The IP addresses of each of the DNS servers that are queried when resolving domain
names. Up to 5 DNS servers may be configured.
Domain Specifies the name to be appended to the host name before a query to the DNS server is
executed.
Cisco VCS Administrator Guide (X6.1) Page 28 of 401
Page 29
Overview and status information
The IP settings can be configured via the IP page.
The Dual network interfaces option is enabled by the addition of the corresponding option key.
Resource usage
The Resource usage page (Status > System > Resource usage) provides statistics about the
numbers of current and cumulative calls and registrations on the VCS.
If the VCS is part of a cluster, then details for each peer are shown as well as totals for the entire
cluster.
n Current: the number of calls or registrations on the VCS at this particular moment.
n Peak: the highest number of concurrent calls or registrations handled by the VCS since it was last
restarted.
n Since last restart: the total number of calls or registrations handled by the VCS since it was last
restarted.
n License limit: the total number of licenses available on the VCS.
To view details of current calls orregistrations, click on the relevant item in the section. Note that if
your system is a VCS Expressway, TURN relay license information is also displayed.
This page refreshes automatically every 5 seconds.
Active administrator sessions
The Active administrator sessions page (Status > System > Active administrator sessions) lists
all administrator accounts that are currently logged in to this VCS.
It displays details of their session including their login time, session type, IP address and port, and
when they last accessed this VCS.
Active user sessions
The Active user sessions page (Status > System > Active user sessions) lists all user accounts
that are currently logged in to this VCS.
It displays details of their session including their login time, IP address and port, and when they last
accessed this VCS.
Registration status
Registrations by device
The Registrations by device page (Status > Registrations > By device) lists each device currently
registered with the VCS, and allows you to remove a device's registration. If the VCS is part of a
cluster, all registrations across the cluster are shown.
Note that an H.323 device can register with more than one alias; in such cases this page will show
only one alias and (when present) one E.164 number for that device. Note also that a single device can
support both the SIP and H.323 protocols; in such a case the SIP registration and the H.323
registration will appear as separate entries on this page.
The following information is displayed:
Cisco VCS Administrator Guide (X6.1) Page 29 of 401
Page 30
Overview and status information
Field Description
Name For H.323 devices, this is one of its aliases. If the device has registered with more than
one alias, this will be (in order of preference) its H.323 ID, URI or email address. For
MCUs and Gateways this will be its alias or, if it has not registered an alias, one of its
prefixes. For SIP devices, this is its SIP AOR.
E164 For H.323 devices that have registered one or more E.164 numbers, the first will be
shown here. For SIP devices this will always be blank because they cannot register
E.164 numbers.
Type Indicates the nature of the registration. This will most commonly be Endpoint, MCU,
Gateway, or SIP UA.
Protocol Indicates whether the registration is for a SIP orH.323 device.
Creation
time
The date and time at which the registration was accepted.
If an NTP server has not been configured, this will say Time not set.
Address For H.323 devices this is its RAS address, and for SIP UAs it is the Contact address
presented in the REGISTER request.
Peer Identifies the cluster peer to which the device is registered.
Clicking on a device's Name orE164 number takes you to the Registrations details page for that
device.
For a list of all aliases currently registered with the VCS, see the Registrations by alias page.
Unregistering a device
Click Unregister to remove the selected registrations.
Note that:
n if your VCS is part of a cluster you have to be logged into the peer to which the device is registered
to be able to unregister it
n removing a registration does not prevent the same device from automatically re-registering
Filtering the list
To limit the list of registrations, enter one or more characters in the Filter field and click Filter. Only
those registrations that contain (in any of the displayed fields) the string you entered will be shown.
To return to the full list of registrations, click Reset.
Registrations by alias
The Registrations by alias page (Status > Registrations > By alias) lists all the aliases, E.164
numbers and prefixes used by all endpoints and systems currently registered with the VCS. If the
VCS is part of a cluster, all registrations across the cluster are shown.
Note that a single H.323 device can register with more than one alias, and each will appear as a
separate entry on this page.
The following information is displayed:
Cisco VCS Administrator Guide (X6.1) Page 30 of 401
Page 31
Overview and status information
Field Description
Alias The H.323 alias, E.164 number, prefix or SIP AOR registered by a device.
Clicking on any Alias will take you to the Registrations details page for the device that
registered that alias.
Alias
type
Shows whether the alias is an H.323 ID, E.164 number, prefix or SIP AOR.
Device
type
Indicates the nature of the device that registered the alias. This will most commonly be
Endpoint, MCU, Gateway or SIP UA.
Protocol Indicates whether the registration is for a SIP orH.323 device.
Creation
time
The date and time at which the registration was accepted.
If an NTP server has not been configured, this will say Time not set.
Address For H.323 devices, this is the RAS address.
For SIP UAs it is the Contact address presented in the REGISTER request.
Peer Identifies the cluster peer to which the alias is registered.
Clicking on any Alias takes you to the Registrations details page for the device that registered that
alias.
For a list of all devices registered with the VCS, see the Registrations by device page.
Filtering the list
To limit the list of registrations, enter one or more characters in the Filter field and click Filter. Only
those registrations that contain (in any of the displayed fields) the string you entered will be shown.
To return to the full list of registrations, click Reset.
Registration history
The Registration history page (Status > Registrations > History) lists all the registrations that are
no longer current. It contains all historical registrations since the VCS was last restarted. If the VCS is
part of a cluster, the history of all registrations across the cluster is shown.
The following information is displayed:
Field Description
Name The H.323 alias or SIP AOR that the device registered.
Clicking on an individual Name takes you to the Registrations details page for that
registration.
E164 ForH.323 devices that registered one or more E.164 numbers, the first will be shown
here. For SIP devices this will always be blank because they cannot register E.164
numbers.
Type Indicates the nature of the registration. This will most commonly be Endpoint, Gateway,
or SIP UA.
Protocol Indicates whether the registration was for a SIP or H.323 device.
Cisco VCS Administrator Guide (X6.1) Page 31 of 401
Page 32
Overview and status information
Field Description
Creation
time
The date and time at which the registration was accepted.
If an NTP server has not been configured, this will say Time not set.
End
time
The date and time at which the registration was terminated.
Duration The length of time that the registration was in place.
Peer Identifies the cluster peer to which the alias was registered.
Reason The reason why the registration was terminated.
Filtering the list
To limit the list of registrations, enter one or more characters in the Filter field and click Filter. Only
those registrations that contain (in any of the displayed fields) the string you entered will be shown.
To return to the full list of registrations, click Reset.
Registration details
The Registration details page (Status > Registrations > By device, Status > Registrations > By
alias or Status > Registrations > History, then click on the registration name) shows the particulars
of a single registration. The exact details shown here depend on the device's protocol, and whether the
registration is still current.
Unregistering and blocking devices
n Click Unregister to unregister the device. Note that the device may automatically re-register after a
period of time, depending on its configuration. To prevent this, you must also use a registration
restriction policy such as an Allow List or Deny List.
n Click Unregister and block to unregister the device and add the alias to the Deny List page, thus
preventing the device from automatically re-registering. (This option is only available if the
Restriction policy has been set to Deny List.)
Call status
Call status
The Call status page (Status > Calls > Calls) lists all the calls currently taking place to or from
devices registered with the VCS, or that are passing through the VCS. If the VCS is part of a cluster,
all calls taking place through any VCS in the cluster are shown.
The following information is displayed:
Field Description
Start time The date and time when the call was placed.
Source The alias of the device that placed the call.
Destination The alias dialed from the device. This may be different from the alias to which the call
was placed, which may have been transformed (due to pre-search transforms, zone
transforms or User Policy).
Cisco VCS Administrator Guide (X6.1) Page 32 of 401
Page 33
Overview and status information
Field Description
Bandwidth
allocated
Shows the amount of bandwidth assigned to the call by the VCS. This may be different
to the amount of bandwidth originally requested by the endpoint that placed the call.
Route The subzone or zone from which the call was received and the subzone or zone to
which the call was placed. To see the complete route taken by the call within the VCS,
including intermediary subzones, click View.
Protocol Shows whether the call used H.323, SIP, or both protocols.
Peer Identifies the cluster peer through which the call is being made.
Actions Click View to go to the Call summary page, which lists further details of this call.
Disconnecting calls
Click Disconnect to disconnect the selected calls. Note that if your VCS is part of a cluster you have
to be logged into the peer through which the call is associated to be able to disconnect the call.
Call disconnection works differently for H.323 and SIP calls due to differences in the way the
protocols work:
n H.323 calls, and interworked H.323 to SIP calls: the Disconnect command will actually disconnect
the call.
n SIP to SIP calls: the Disconnect command will cause the VCS to release all resources used for the
call and the call will appear on the system as disconnected. However, SIP calls are peer-to-peer
and as a SIP proxy the VCS has no authority over the endpoints. Although releasing the resources
may have the side-effect of disconnecting the SIP call, it is also possible that the call signaling,
media or both may stay up (depending on the type of call being made). The call will not actually
disconnect until the SIP endpoints involved have also cleared their resources.
Filtering the list
To limit the list of calls, enter one or more characters in the Filter field and click Filter. Only those calls
that contain (in any of the displayed fields) the characters you entered are shown.
To return to the full list of calls, click Reset.
Call history
The Call history page (Status > Calls > History) lists all the calls that are no longer active that have
taken place since the VCS was last restarted. If the VCS is part of a cluster, all calls that have taken
place through any VCS in the cluster are shown.
The following information is displayed:
Field Description
Start time The date and time at which the call was placed.
Source The alias of the device that placed the call.
Destination The alias dialed from the device. This may be different from the alias to which the call
was placed, which may have been transformed (due to pre-search transforms, zone
transforms or User Policy).
Protocol Shows whether the call used H.323, SIP, or both protocols.
Cisco VCS Administrator Guide (X6.1) Page 33 of 401
Page 34
Overview and status information
Field Description
Duration Shows the length of time of the call.
Status Shows the reason the call was terminated.
Peer Identifies the cluster peer through which the call was made.
Actions Allows you to click View to go to the Call summary page, which lists overview details
of this call.
Filtering the list
To limit the list of calls, enter one or more characters in the Filter field and click Filter. Only those calls
that contain (in any of the displayed fields) the characters you entered are shown.
To return to the full list of calls, click Reset.
Call summary
The Call summary page (Status > Calls > Calls or Status > Calls > History, then click View for a
particular call) provides overview information about a particular call, including information about the
most relevant legs.
Further detailed information about the call can be viewed via the links in the Related tasks section at
the bottom of the page:
n View media statistics for this call takes you to the Call media page, where you can view
information about the most relevant session for a call. For traversal calls (i.e. where the VCS took
the media), it will also list the individual media channels (audio, video, data, etc) that made up the
call.
n View all details of this call takes you to the Call details page, where you can view full information
about this call.
n View search details for this call takes you to the Search details page, which lists full information
about all the searches associated with this call's Call Tag, including the subzones and zones that
were searched and any transforms that were applied to the alias being searched for.
n View all events associated with this call takes you to the Event Log page, filtered to show only
those events associated with this call's Call Tag.
Call details
The Call details page lists full information about a particular call, including any failed sessions. This
page is reached via the View all details of this call link in the Related tasks section of either of the
following pages:
n the Call summary page (Status > Calls > Calls or Status > Calls > History, then click View)
n the Call details page (Status > Calls > Calls or Status > Calls > History, then click View for a
particular call)
Call media details
The Call media page shows information about the most relevant session for a call. For traversal calls
(where the VCS took the media), it also lists the individual media channels (audio, video, data and so
on) that made up the call.
This page is reached via the View media statistics for this call link in the Related tasks section of
either of the following pages:
Cisco VCS Administrator Guide (X6.1) Page 34 of 401
Page 35
Overview and status information
n the Call summary page (Status > Calls > Calls or Status > Calls > History, then click View)
n the Call details page (Status > Calls > Calls or Status > Calls > History, then click View for a
particular call)
Search history
The Search history page (Status > Search history) lists the most recent 255 searches that have
taken place since the VCS was last restarted.
About searches
Before a call can be placed, the endpoint being called must be located. The VCS sends and receives a
series of messages during its attempt to locate the endpoint being called; these messages are each
known as searches. An individual call can have one or more searches associated with it, and these
searches can be of different types.
The type of search message that is sent depends on whether the call is for SIP or H.323, and whether
the call request was received locally or from an external zone, as follows:
n H.323 calls that are placed locally: two messages are sent - the first is an ARQ which locates the
device being called, and the second is the call Setup which sends a request to the device asking it
to accept the call. Each message shows up as a separate search in the Search history page, but
only the Setup message is associated with a particular call.
n H.323 searches originating from external zones: an LRQ will appear in the Search history page.
n SIP: a single message is sent in order to place a call: this is either a SIP INVITE or a SIP
OPTIONS.
Note that an individual call can have one or more searches associated with it, and these searches can
be of different types. Each search has an individual Search ID; each call has an individual Call Tag
(see Identifying calls).
Search history list
The search history summary list shows the following information:
Field Description
Start time The date and time at which the search was initiated.
Search
type
The type of message being sent.
Source The alias of the endpoint that initiated the call.
Destination The alias that was dialed from the endpoint. This may be different from the alias to
which the call was actually placed, as the original alias may have been transformed
either locally or before the neighbor was queried.
Status Indicates whether or not the search was successful.
Actions Allows you to click View to go to the Search details page, which lists full details of this
search.
Filtering the list
To limit the list of calls, enter one or more characters in the Filter field and click Filter. Only those
calls that contain (in any of the displayed fields) the characters you entered will be shown.
To return to the full list of calls, click Reset.
Cisco VCS Administrator Guide (X6.1) Page 35 of 401
Page 36
Overview and status information
Viewing associated searches
If there were other searches associated with the same call, a View all searches associated with
this call tag link is shown at the bottom of the page; clicking this takes you to a Search details page
showing all searches relating to that particular call.
Search details
The Search details page (Status > Search history, then click View for a particular search) lists full
information about either an individual search, or all searches associated with a single call (depending
on how you reached the page). The information shown includes:
n the subzones and zones that were searched
n the call path and hops
n any transforms that were applied to the alias being searched for
n use of policies such as Admin Policy or User Policy (FindMe)
n any policy services that were used
Other information associated with the search and (if it was successful) the resulting call can be viewed
via the links in the Related tasks section at the bottom of the page:
n View all events associated with this call tag takes you to the Event Log page, filtered to show
only those events associated with the Call Tag relating to this search.
n View call information associated with this call tag takes you to the Call summary page, where
you can view overview information about the call.
n View all searches associated with this call tag is shown if you are viewing details of an
individual search and there are other searches associated with the same call. It takes you to a new
Search details page which lists full information about all the searches associated with the call's
Call Tag.
Local Zone status
The Local Zone status page (Status > Local Zone) lists all of the subzones on the VCS that
together make up the Local Zone. This will always include the Default Subzone and the Traversal
Subzone, plus any other subzones that have been configured.
The following information is displayed:
Field Description
Subzone
name
The names of each subzone currently configured on this VCS.
Clicking on a Subzone name takes you to the configuration page for that subzone.
Registrations The number of devices currently registered within the subzone. Note that devices
cannot be registered to the Traversal Subzone.
Calls The number of calls currently passing through the subzone. Note that a single call
may pass through more than one subzone, depending on the route it takes. For
example, traversal calls from a locally registered endpoint will always pass through
the Traversal Subzone, so they will show up twice; once in the originating subzone
and once in the Traversal Subzone.
Bandwidth
used
The total amount of bandwidth used by all calls passing through the subzone.
Cisco VCS Administrator Guide (X6.1) Page 36 of 401
Page 37
Overview and status information
Zone status
The Zone status page (Status > Zones) lists all of the external zones on the VCS, the number of calls
and amount of bandwidth being used by each, and their current status.
The list of zones always includes the Default Zone, plus any other zones that have been created.
The following information is displayed:
Field Description
Name The names of each zone currently configured on this VCS.
Clicking on a zone Name takes you to the configuration page for that subzone.
Type The type of zone.
Calls The number of calls currently passing out to or received in from each zone.
Bandwidth
used
The total amount of bandwidth used by all calls passing out to or received in from
each zone.
Status The current status of each zone.
Link status
The Link status page (Status > Bandwidth > Links) lists all of the links currently configured on the
VCS, along with the number of calls and the bandwidth being used by each link.
The following information is displayed:
Field Description
Name The name of each link. Clicking on a link Name takes you to the configuration page for
that link.
Calls The total number of calls currently traversing the link. Note that a single call may
traverse more than one link, depending on how your system is configured.
Bandwidth
used
The total bandwidth of all the calls currently traversing the link.
Pipe status
The Pipe status page (Status > Bandwidth > Pipes) lists all of the pipes currently configured on the
VCS, along with the number of calls and the bandwidth being used by each pipe.
The following information is displayed:
Field Description
Name The name of each pipe. Clicking on a pipe Name takes you to the configuration page
for that pipe.
Cisco VCS Administrator Guide (X6.1) Page 37 of 401
Page 38
Overview and status information
Field Description
Calls The total number of calls currently traversing the pipe. Note that a single call may
traverse more than one pipe, depending on how your system is configured.
Bandwidth
used
The total bandwidth of all the calls currently traversing the pipe.
Policy service status
The Policy service status page (Status > Policy services) lists all of the policy services configured
on the VCS and displays their current status.
The set of policy services includes all of the services defined on the Policy services page (VCS
configuration > Dial plan > Policy services), plus if a remote service has been selected for either
Call Policy or for registration restriction policy it will also display a Call Policy or a Registration
restriction service respectively.
The following information is displayed:
Field Description
Name The name of the policy service.
Clicking on a Name takes you to the configuration page for that service.
URL The address of the service. Note that each service can be configured with multiple server
addresses for resiliency. This field displays the server address currently selected for use by
the VCS.
Status The current status of the service.
Last
used
Indicates when the service was last requested by a VCS process.
TURN relays status
The TURN relays page (Status > TURN relays) lists all the currently active TURN Relays on the
VCS. For each relay, it shows the requesting client address and port and the corresponding VCS
address and port.
Note: TURN services are available on VCS Expressways only. They are configured from the TURN
page (VCS configuration > Expressway > TURN).
The following information is displayed:
Field Description
Relay The index number of the relay.
Address The IP address and port on the VCS of the relay resource that has been allocated for
this particular request.
Client The IP address and port on the NAT (or the client if there is no NAT) that requested the
relay.
Cisco VCS Administrator Guide (X6.1) Page 38 of 401
Page 39
Overview and status information
Field Description
Creation
time
The date and time the relay became active.
Expiry
time
The date and time the relay will become inactive.
Viewing TURN relay details
Click View to go to the TURN relay summary page where you can see more information about a relay.
From here further detailed information about the relay can be viewed by using the links in the Related
tasks section at the bottom of the page:
n View permissions for this relay takes you to the TURN relay permissions page, where you can
view information about the permissions that have been defined on the relay.
n View channels for this relay takes you to the TURN relay channels page, where you can view
information about the channel bindings that have been defined on the relay.
n View counters for this relay takes you to the TURN relay counters page, where you can view
TURN request, response and error counters, as well as media counters, for the relay.
Presence
Presence publishers
The Publishers page (Status > Applications > Presence > Publishers) lists each presentity
whose presence information is being managed by (that is, published to) the local presence server.
All presentities are listed here regardless of whether or not anyone is requesting their presence
information. If there are no publishers listed, this could mean that the presence server is not enabled
on this VCS.
Note: FindMe users are not listed here as they do not have their status individually published. The
status of a FindMe user is based on the published status of the endpoints and/or presentities that
make up the FindMe user, and is determined by the presentity manager.
URI
The address of the presentity whose presence information is being published.
Publisher count
The number of sources of information that are being published for this particular presentity. All
endpoints that are registered to the VCS have information published on their behalf by the PUA (as
long as they are registered with an alias in the form of a URI). If an endpoint supports presence, it may
also publish its own presence information. This means that some presentities have more than one
source of information about their presence. It is the job of the presentity manager to aggregate this
information and determine the actual status of the presentity.
Presence presentities
The Presentities page (Status > Applications > Presence > Presentities)lists each presentity
whose presence information is being managed by (that is, published to) the local presence server and
whose presence information has been requested by a subscriber. Presentities are listed here whether
or not there is any information currently available about that presentity. If a presentity has been
subscribed to but there is no information being published about it, then it will be listed here if the local
presence server is authoritative for the presentity’s domain.
Cisco VCS Administrator Guide (X6.1) Page 39 of 401
Page 40
Overview and status information
Presentities are listed here regardless of whether the subscriber that requested the information is
registered locally or to a remote system.
Note: FindMe users are listed here if their presence information has been requested by a subscriber.
URI
The address of the presentity whose presence information has been requested.
Subscriber count
The number of endpoints who have requested information about that particular presentity.
To view the list of all subscribers who are requesting information about a particular presentity, click on
the presentity’s URI.
Presence subscribers
The Subscribers page (Status > Applications > Presence > Subscribers) lists each endpoint that
has requested information about one or more presentities whose information is managed by (that is,
published to) the local Presence Server.
Endpoints requesting this information are listed here regardless of whether they are registered locally
or to a remote server.
Note: FindMe users will not be listed here as a FindMe entity cannot subscribe to presence
information. However, one or more of the endpoints that make up a FindMe user may be requesting
presence information, in which case that endpoint will be listed here.
URI
The address of the endpoint that has requested presence information.
Subscription count
The number of local presentities about whom this endpoint is requesting information.
To view the list of all local presentities whose information is being requested by a particular endpoint,
click on the endpoint’s URI.
OCS Relay status
The OCS Relay status page (Status > Applications > OCS Relay) lists all the FindMe IDs being
handled by the OCS Relay application, and shows the current status of each.
The OCS Relay application is required in deployments that use both Microsoft Office Communicator
(MOC) clients and FindMe, if they both use the same SIP domain. Its purpose is to:
n enable the VCS to share FindMe presence information with MOC clients
n enable the Microsoft Office Communications Server (OCS) to forward calls to FindMe IDs
Note: the OCS Relay application is configured via the OCS Relay page (Applications > OCS
Relay).
The following information is displayed:
Field Description
Alias The FindMe ID being handled by the OCS Relay application.
Cisco VCS Administrator Guide (X6.1) Page 40 of 401
Page 41
Overview and status information
Field Description
Presence
state
Shows the presence information currently being published for the FindMe ID.
Registration
state
Indicates whether the FindMe ID has registered successfully with OCS. Doing so
allows OCS to forward calls to the FindMe ID.
Subscription
state
Indicates whether the OCS Relay application has subscribed successfully to the
FindMe ID's presence information. Doing so allows MOC clients to view the
presence information of FindMe users.
Provisioning status
The Provisioning status page (Status > Applications > Provisioning) shows the status of the
VCS's provisioning server and phone book server.
These servers provide provisioning-related services to provisioned devices, without the need for TMS.
Provisioning server
The provisioning server provides basic device provisioning to provisioned users.
This section displays the server's status and summarizes the subscription requests received by the
server since the VCS was last restarted. It shows counts of:
n the total number of subscription requests received
n how many requests were sent a successful provisioning response
n failed requests because the account requesting provisioning could not be found
n failed requests because the account requesting provisioning had no provisioned devices associated
with it
Phone book server
The phone book server provides phone book directory and lookup facilities to provisioned users.
This section displays the server's status and summarizes the number of phone book search requests
received by the server since the VCS was last restarted.
Note that the VCS's provisioning facilities are only available if the Starter Pack option key is installed.
Warnings
The Warnings page (Status > Warnings, or by clicking on the red warning icon which appears at
the top right of any page when a warning is in place) provides a list of all the warnings currently in place
on your system (and, in the Action column where applicable, their proposed resolution).
You should deal with each warning by clicking each Action hyperlink and making the necessary
configuration changes to resolve the problem.
Warnings occur when an event or configuration change has taken place on the VCS that requires
some manual administrator intervention such as a restart. Warnings may also be raised for hardware
and environmental issues such as faulty disks and fans or high temperatures.
Acknowledging a warning (by selecting a warning and clicking on the Acknowledge button) removes
the warning icon from the web UI, but the warning will still be listed on the Warnings page with a
status of Acknowledged. If a new warning occurs, the warning icon will reappear.
Cisco VCS Administrator Guide (X6.1) Page 41 of 401
Page 42
Overview and status information
You cannot delete warnings from the Warnings page. Warnings are removed by the VCS only after
the required action or configuration change has been made.
After a restart of the VCS, any Acknowledged warnings that are still in place on the VCS will reappear
with a status of New, and must be re-acknowledged.
Refer to the warnings list for further information about the specific warnings that can be raised.
Hardware status
The Hardware page (Status > Hardware ) provides information about the physical status of your
VCS unit.
Information displayed includes:
n fan speeds
n component temperatures
n component voltages
Any appropriate minimum or maximum levels are shown to help identify any components operating
outside of their standard limits.
CAUTION: do not attempt to service the apparatus yourself as opening or removing covers may
expose you to dangerous voltages or other hazards, and will void the warranty. Refer all servicing to
qualified service personnel.
Event Log
The Event Log page (Status > Logs > Event Log) lets you view and search the Event Log, which is
a list of all the events that have occurred on your system since the last upgrade. The Event Log holds
2GB of data; when this size is reached, the oldest entries are overwritten. However only the first 50MB
of event log data can be displayed through the web interface.
Filtering the Event Log
The Filter section lets you filter the Event Log. Enter the words you want to search for and click
Filter.Only those events that contain all the words you entered are shown.
To do more advanced filtering, click more options. This gives you additional filtering methods:
n Contains the string: only includes events containing theexact phrase entered here.
n Contains any of the words: includes any events that contain at least one ofthe words entered
here.
n Not containing any of the words: filters out any events containing any of the words entered here.
Note: use spaces to separate each word you want to filter by.
Click Filter to reapply any modified filter conditions. To return to the complete Event Log listing, click
Reset.
Reconfiguring the log settings
Clicking Reconfigure the log settings takes you to the Logging configuration page. From this page,
you can set the level of events that are recorded in the event log, and also set up a remote server to
which the event log can be copied.
Results section
The Results section shows all the events matching the current filter conditions, with the most recent
being shown first.
Cisco VCS Administrator Guide (X6.1) Page 42 of 401
Page 43
Overview and status information
Most tvcs events contain hyperlinks in one or more of the fields (such fields change color when you
hover over them). You can click on the hyperlink to show only those events that contain the same text
string. For example, clicking on the text that appears after Event= filters the list to show all the events
of that particular type. Likewise, clicking on a particular Call-Id shows just those events that contain a
reference to that particular call.
Event Log color coding
Certain events in the Event Log are color-coded so that you can identify them more easily. These
events are as follows:
Green events:
n System Start
n Installation of <item> succeeded
n Registration Accepted
n Call Connected
n Request Successful
n Beginning System Restore
n Completed System Restore
Orange events:
n System Shutdown
Red events:
n Registration Rejected
n Registration Refresh Rejected
n Call Rejected
n Security Alert
n License Limit Reached
n Decode Error
n TLS Negotiation Error
n External Server Communications Failure
n Application Failed
n Request Failed
n System Backup Error
n System Restore Error
n Authorization Failure
For more information about the format and content of the Event Log see Event Log format and Events
and levels.
Configuration Log
The Configuration Log page (Status > Logs > Configuration Log) provides a list of all changes to
the VCS configuration made using the web or command line interface (CLI).
The configuration log visible using the web interface holds a maximum of 4MB of data; when this size
is reached, the oldest entries are overwritten.
Filtering the Configuration Log
The Filter section lets you filter the Configuration Log. Enter the words you want to search for and
click Filter.Only those events that contain all the words you entered are shown.
To do more advanced filtering, click more options. This gives you additional filtering methods:
Cisco VCS Administrator Guide (X6.1) Page 43 of 401
Page 44
Overview and status information
n Contains the string: only includes events containing the exact phrase entered here.
n Contains any of the words: includes any events that contain at least one of the words entered
here.
n Not containing any of the words: filters out any events containing any of the words entered here.
Note: use spaces to separate each word you want to filter by.
Click Filter to reapply any modified filter conditions. To return to the complete Configuration Log
listing, click Reset.
Results section
The Results section shows all the web-based events, with the most recent being shown first.
Most events contain hyperlinks in one or more of the fields (such fields change color when you hover
over them). You can click on the hyperlink to show only those events that contain the same text string.
For example, clicking on the text that appears after Event= filters the list to show all the events of that
particular type. Likewise, clicking on a particular user shows just those events relating to that
particular administrator account.
All events that appear in the Configuration Log are recorded as Level 1 Events, so any changes to the
logging levels will not affect their presence in the Configuration Log.
Configuration Log events
Changes to the VCS configuration made by administrators using the web interface have an Event field
of System Configuration Changed.
The Detail field of each of these events shows:
n the configuration item that was affected
n what it was changed from and to
n the name of the administrator user who made the change, and their IP address
n the date and time that the change was made
VCS unit front panel
The LCD panel on the front of the VCS hardware unit has a rotating display of the VCS's system
name, IP addresses, warnings, and the number of current traversal calls, non-traversal calls and
registrations.
Cisco VCS Administrator Guide (X6.1) Page 44 of 401
Page 45
Network and system settings
Network and system settings
This section describes all the options that appear under the System menu of the web interface.
These options enable you to configure the VCS in relation to the network in which it is located, for
example its IP settings and the external services used by the VCS (for example DNS, NTP and
SNMP).
Configuring IP settings
The IP page (System > IP) is used to configure the IP protocols and settings of the VCS.
IP protocol configuration
You can configure whether the VCS uses IPv4, IPv6 or Both protocols. The default is Both.
n IPv4: it only accepts registrations from endpoints using an IPv4 address, and only takes calls
between two endpoints communicating via IPv4. It communicates with other systems via IPv4
only.
n IPv6: it only accepts registrations from endpoints using an IPv6 address, and only takes calls
between two endpoints communicating via IPv6. It communicates with other systems via IPv6
only.
n Both: it accepts registrations from endpoints using either an IPv4 or IPv6 address, and takes calls
using either protocol. If a call is between an IPv4-only and an IPv6-only endpoint, the VCS acts as
an IPv4 to IPv6 gateway. It communicates with other systems via either protocol.
Note: some endpoints support both IPv4 and IPv6, however an endpoint can use only one protocol
when registering with the VCS. Which protocol it uses is determined by the format used to specify the
IP address of the VCS on the endpoint. After the endpoint has registered using either IPv4 or IPv6, the
VCS only sends calls to it using this addressing scheme. Calls made to that endpoint from another
device using the other addressing scheme are converted (gatewayed) by the VCS.
IPv4 to IPv6 gatewaying (interworking)
The VCS can act as a gateway for calls between IPv4 and IPv6 devices. To enable this feature, select
an IP protocol of Both. Calls for which the VCS is acting as an IPv4 to IPv6 gateway are traversal
calls and require a traversal call license.
IPgateways and IP routes (static routes)
You can set the default IPv4 gateway and IPv6 gateway used by the VCS. These are the gateways to
which IP requests are sent for IP addresses that do not fall within the VCS’s local subnet.
However, you can also configure additional IP routing information (static routes) on the VCS. This is
sometimes required when using the Dual Network Interfaces option and occasionally required in other
complex network deployments. You can configure routes for up to 50 networks and host
combinations. IP routes can be configured using the CLI only.
LAN configuration
LAN 1 is the primary network port on the VCS.
You can configure the IPv4 address and subnet mask, and IPv6 address for this port.
For VCS Expressway boxes behind a static NAT, you can also configure the NAT's IP address. If you
have Dual Network Interfaces installed, you can also configure these options for the LAN 2 port. The
VCS is shipped with a default IP address of 192.168.0.100 (for both LAN ports). This lets you connect
the VCS to your network and access it via the default address so that you can configure it remotely.
Cisco VCS Administrator Guide (X6.1) Page 45 of 401
Page 46
Network and system settings
The External LAN interface field indicates which LAN port has been connected to your external
network. It also determines the port from which TURN server relay allocations are made.
About Dual Network Interfaces
The Dual Network Interface option key enables the LAN 2 port on the VCS Expressway for both
management and call signaling. This allows you to have a second IP address for your VCS.
This configuration is intended for high-security deployments where the VCS is located in a DMZ
between two separate firewalls on separate network segments. In such deployments, routers prevent
devices on the internal network from being able to route IP traffic to the public internet, and instead the
traffic must pass through an application proxy such as the VCS.
To enable this feature you must purchase and install the appropriate option key. Contact your Cisco
representative for information.
Note: you should configure the LAN 1 port and restart the VCS before configuring the LAN 2 port.
If you have Dual Network Interfaces enabled but only want to configure one of the Ethernet ports, you
must use LAN 1.
About static NAT
It is possible to deploy a VCS Expressway behind a static NAT device, allowing it to have separate
public and private IP addresses. This feature is intended for use in deployments where the VCS
Expressway is located in a DMZ, and has the Dual Network Interfaces feature enabled.
In these deployments, the externally-facing LAN port has static NAT enabled in order to use both a
private and public IPv4 address; the internally facing LAN port does not have static NAT enabled and
uses a single IPv4 (or IPv6) address.
In such a deployment, when configuring traversal clients to use the VCS Expressway as a traversal
server, it is the latter internally-facing IP address of the VCS Expressway that should be used. To
enable the use of a static NAT:
1. Ensure that the Dual Network Interfaces option key is installed.
2. For the externally-facing LAN port:
a. In the IPv4 address field, enter the VCS Expressway's private IP address.
b. Select an IPv4 static NAT mode of On.
c. In the IPv4 static NAT address field, enter the VCS Expressway's public IP address - this is
the IP address of the outside of the NAT.
Configuring Ethernet settings
The Ethernet page (System > Ethernet) is used to configure the speed of the connection between the
VCS and the Ethernet switch to which it is connected. The speed must be set to the same value on
both systems. If you have the Dual network interfaces option enabled, you can configure the
Ethernet speed separately for each LAN port.
The default is Auto, which means that the two systems will auto-negotiate the appropriate speed.
Note: you are recommended to use the default value of Auto unless the switch to which you are
connecting is unable to auto-negotiate. A mismatch in Ethernet speed settings between the VCS and
Ethernet switch will at best result in packet loss; at worst it will make the system inaccessible for
endpoints and system administrators.
Configuring DNS settings
The DNS page (System > DNS) is used to configure the VCS's DNS servers and DNS settings.
Cisco VCS Administrator Guide (X6.1) Page 46 of 401
Page 47
Network and system settings
DNS servers
You must specify at least one DNS server to be queried for address resolution if you want to either:
n use FQDNs (Fully Qualified Domain Names) instead of IP addresses when specifying external
addresses (for example for LDAP and NTP servers, neighbor zones and peers), or
n use features such as URI dialing or ENUM dialing
You can specify up to 5 DNS servers. The VCS sends requests to all configured servers in parallel,
taking the first result received and discounting the rest.
Note: this can lead to confusing behavior should local network administrators, for example, deploy
"split horizon" DNS where records held on an internal, corporate, DNS server use the same domain
names but with different values to those on the public internet - an often used tactic in corporate
intranets.
DNS settings
The Local host name defines the DNS host name that this VCS is known by.
n It must be unique for each peer in a cluster.
n It is used to identify the VCS on a remote log server (a default name of "TANDBERG" is usedif the
Local host name is not specified).
The Domain name is used when attempting to resolve unqualified server addresses (for example
ldap or ldap_server). It is appended to the unqualified server address before the query is sent to
the DNS server. If the server address is fully qualified (for example ldap_server.domain) or is in
the form of an IP address, the domain name is not appended to the server address before querying the
DNS server.
It applies to the following configuration settings in the VCS:
n LDAP server
n NTP server
n External Manager server
n Remote logging server
You are recommended to use an IP address or FQDN (Fully Qualified Domain Name) for all server
addresses.
Tip: the FQDN of the VCS is the Local host name plus the Domain name.
Impact on SIP messaging
The Local host name and Domain name are also used to identify references to this VCS in SIP
messaging, where an endpoint has configured the VCS as its SIP proxy in the form of an FQDN (as
opposed to an IP address, which is not recommended).
In this case the VCS may, for example, reject an INVITE request if the FQDN configured on the
endpoint does not match the Local host name and Domain name configured on the VCS. (Note that
this check occurs because the SIP proxy FQDN is included in the route header of the SIP request sent
by the endpoint to the VCS.)
Configuring Quality of Service settings
The Quality of Service (QoS) page (System > Quality of Service) is used to configure QoS options
for outbound traffic from the VCS.
Cisco VCS Administrator Guide (X6.1) Page 47 of 401
Page 48
Network and system settings
This allows the network administrator to tag all signaling and media packets flowing through the VCS
with one specific QoS tag and hence provide the ability to prioritize video traffic over normal data
traffic. Management traffic, for example SNMP messages, is not tagged.
Supported mechanisms
The VCS supports the DiffServ (Differentiated Services) mechanism which puts the specified Tag
value in the TOS (Type Of Service) field of the IPv4 header or TC (Traffic Class) field of the IPv6
header.
Configuring system name and access settings
The System administration page (System > System) is used to configure the name of the VCS and
the means by which it is accessed by administrators.
Configuring the system name
The System name is used to identify the VCS. It appears in various places in the web interface, and
in the display on the front panel of the unit (so that you can identify it when it is in a rack with other
systems). The System name is also used by TMS.
You are recommended to give the VCS a name that allows you to easily and uniquely identify it.
Administration access
While it is possible to administer the VCS via a PC connected directly to the unit via a serial cable, you
may want to access the system remotely over IP. You can do this using either or both:
n the web interface, via HTTPS
n a command line interface, via SSH or Telnet
The configurable options are:
Field Description Usage tips
Session
time out
The number of
minutes that an
administration
session (serial port,
HTTPS, Telnet or
SSH) may be inactive
before the session is
timed out. Default is
0.
A value of 0 means that session time outs are disabled.
Peraccount
session
limit
The number of
concurrent sessions
that each individual
administrator account
is allowed on each
VCS.
This includes web, SSH, Telnet and serial sessions. Note that
session limits are not enforced on user (FindMe) accounts or
the root account.
A value of 0 turns session limits off.
Cisco VCS Administrator Guide (X6.1) Page 48 of 401
Page 49
Network and system settings
Field Description Usage tips
System
session
limit
The maximum
number of concurrent
administrator
sessions allowed on
each VCS.
This includes web, SSH, Telnet and serial sessions. Note that
session limits are not enforced on user (FindMe) accounts or
the root account; however active root account sessions do
count towards the total number of current administrator
sessions.
A value of 0 turns session limits off.
Telnet
service
Determines whether
the VCS can be
accessed via Telnet.
Default is Off.
SSH
service
Determines whether
the VCS can be
accessed via SSH
and SCP. Default is
On.
Web
interface
(over
HTTPS)
Determines whether
the VCS can be
accessed via the web
interface. Default is
On.
TMS accesses the VCS via the web server. If HTTPS mode is
turned off, TMS will not be able to access it.
Cisco VCS Administrator Guide (X6.1) Page 49 of 401
Page 50
Network and system settings
Field Description Usage tips
Client
certificatebased
security
Controls the level of
security required to
allow client systems
(typically web
browsers) to
communicate with
the VCS over
HTTPS.
Not required: the
client system does
not have to present
any form of
certificate.
Certificate
validation: the client
system must present
a valid certificate
that has been signed
by a trusted
certificate authority
(CA).
Certificate-based
authentication: the
client system must
present a valid
certificate that has
been signed by a
trusted CA and
contains the client's
authentication
credentials.
Default: Not required
Important:
Enabling Certificate validation means that your browser can
use the VCS web interface only if it has a valid client
certificate signed by a CA in the VCS's trusted CA certificate
list.
n Ensure yourbrowser (the client system) hasa valid (in date
and not revoked by a CRL) client certificate before enabling
this feature. The procedure for uploading a certificate to
your browser may vary depending on the browser type and
you mayneed to restart your browser for the certificate to
take effect.
n You can upload trusted CA certificates on the security
certificates page, manage client certificate revocation lists
on the CRL management page, and test client certificates
on the Client certificate testing page.
Enabling Certificate-based authentication means that the
standard login mechanism is no longer available. You can log
in only if your browser certificate — typically provided via a
smart card (also referred to as a Common Access Card or
CAC) — is valid and the credentials it provides have the
appropriate authorization levels. You can configure how the
VCS extracts credentials from the browser certificate on the
Certificate-based authentication configuration page.
Note that this setting does not affect client verification of the
VCS's server certificate.
Redirect
HTTP
requests
to HTTPS
Determines whether
HTTP requests are
redirected to the
HTTPS port. Default
is On.
HTTPS must also be enabled for access via HTTP to function.
Note: by default, access via HTTPS and SSH is enabled; access via Telnet is disabled. To securely
manage the VCS you should disable Telnet, using the encrypted HTTPS and SSH protocols instead.
For further security, disable HTTPS and SSH as well and use the serial port to manage the system.
Because access to the serial port allows the password to be reset, it is recommended that you install
the VCS in a physically secure environment.
Cisco VCS Administrator Guide (X6.1) Page 50 of 401
Page 51
Network and system settings
VCS unit front panel
The LCD panel on the front of the VCS hardware unit has a rotating display of the VCS's system
name, IP addresses, warnings, and the number of current traversal calls, non-traversal calls and
registrations.
You can configure the front panel to hide this identifying information, if required for security reasons for
example, by using the CLI command xConfiguration Administration LCDPanel Mode. If
the mode is set to Off the front panel only displays "Cisco".
Configuring SNMP settings
The SNMP page (System > SNMP) is used to configure the VCS's SNMP settings.
Tools such as TMS or HP OpenView may act as SNMP Network Management Systems (NMS). They
allow you to monitor your network devices, including the VCS, for conditions that might require
administrative attention.
The VCS supports the most basic MIB-II tree (.1.3.6.1.2.1) as defined in RFC 1213 [23].
The information made available by the VCS includes the following:
n system uptime
n system name
n location
n contact
n interfaces
n disk space, memory, and other machine-specific statistics
By default, SNMP is Disabled, therefore to allow the VCS to be monitored by an SNMP NMS
(including TMS), you must select an alternative SNMP mode. Theconfigurable options are:
Field Description Usage tips
SNMPmode Controls the level of SNMP
support.
Disabled: no SNMP support.
SNMPv3 (secure SNMP):
supports authentication and
encryption.
SNMPv3 plus TMS support:
secure SNMPv3 plus non-secure
access to OID 1.3.6.1.2.1.1.2.0
only.
SNMPv2c: non-secure
community-based SNMP.
If you want to use secure SNMPv3 but you
also use TMS as your external manager, you
must select SNMPv3 plus TMS support.
Community
name
The VCS's SNMP community
name. The default is public.
Only applies to SNMPv2c and SNMPv3 plus
TMS support.
System
contact
The name of the person who can
be contacted regarding issues with
the VCS.
The System contact and Location are used
for reference purposes by administrators
when following up on queries.
Location Specifies the physical location of
the VCS.
Cisco VCS Administrator Guide (X6.1) Page 51 of 401
Page 52
Network and system settings
Field Description Usage tips
Username The VCS's SNMP username,
used to identify this SNMP agent
to the SNMP manager.
Only applies when using secure SNMPv3.
Authentication settings (only applicable to SNMPv3)
Authentication
mode
Enables or disables SNMPv3
authentication.
Type The algorithm used to encrypt
authentication credentials.
SHA: Secure Hash Algorithm.
MD5: Message-Digest algorithm
5.
Password The password used to encrypt
authentication credentials.
Must be at least 8 characters.
Privacy settings (only applicable to SNMPv3)
Privacy mode Enables or disables SNMPv3
encryption.
Type The security model used to
encrypt messages.
DES: Data Encryption Standard
56-bit encryption.
AES: Advanced Encryption
Standard 128-bit encryption.
Password The password used to encrypt
messages.
Must be at least 8 characters.
The VCS does not support SNMP traps or SNMP sets, therefore it cannot be managed via SNMP.
Note: SNMP is disabled by default, because of the potentially sensitive nature of the information
involved. Do not enable SNMP on a VCS on the public internet or in any other environment where you
do not want to expose internal system information.
Configuring time zone and NTP server settings
The Time page (System > Time) is used to configure the VCS's NTP server and specify your local
time zone.
NTP server
The NTP server is a remote server with which the VCS synchronizes in order to ensure its time setting
is accurate. The NTP server provides the VCS with UTC time. Accurate timestamps play an
important part in H.323 authentication, helping to guard against replay attacks. For this reason, if you
are using authentication in a deployment that includes H.323, both the VCS and the endpoints must
use an NTP server to synchronize their system time.
Cisco VCS Administrator Guide (X6.1) Page 52 of 401
Page 53
Network and system settings
Accurate time is also necessary for configuration replication to work properly if the VCS is in a cluster,
and to ensure correct timestamps in system logs.
Traversal clients must always authenticate with traversal servers (even if the traversal server is not
using device authentication for endpoint clients). Therefore, for a traversal client and traversal server
to connect to each other, both must be configured with details of an NTP server.
SIP-only deployments do not require the use of NTP for authentication.
To configure the VCS with an NTP server, enter the IP address or FQDN (or server address, if a DNS
Domain name has also been configured) of the NTP server to be used when synchronizing system
time.
n The NTP server field defaults to one of fourNTP servers provided by Cisco, either:
0.ntp.tandberg.com, 1.ntp.tandberg.com, 2.ntp.tandberg.com or 3.ntp.tandberg.com.
n The connection status to the NTP server is shown in the Status section.
VCS time display and time zones
Local time is used throughout the web interface. It is shown in the system information bar at the
bottom of the screen and is used to set the timestamp that appears at the start of each line in the
Event Log and Configuration Log.
Internally, the VCS maintains its system time in UTC. It is based on the VCS's operating system
time, which is synchronized using an NTP server if one is configured. If no NTP server is configured,
the VCS uses its own operating system time to determine the time and date.
Specifying your local Time zone lets the VCS determine the local time where the system is located. It
does this by offsetting UTC time by the number of hours associated with the selected time zone. It
also adjusts the local time to account for summer time (also known as daylight saving time).
The Time page displays both UTC and local time in the Status section. Note that a UTC system
timestamp is included at the end of each entry in the Event Log and Configuration Log.
Configuring the Login page
The Login page configuration page (System > Login page) is used to specify a message and
image to appear on the login page for both users and administrators.
The Welcome message title and text will appear to administrators when attempting to log in using
the CLI, and to FindMe users and administrators when attempting to log in using the web interface.
You can upload an image that will appear on the login page, above the welcome message, to FindMe
users and administrators when attempting to log in using the web interface.
n supported image file formats are JPG, GIF and PNG
n images larger than 200x200 pixels will be scaled down
Note that this feature is not configurable using the CLI.
Configuring external manager settings
The External manager page (System > External manager) allows you to configure the VCS's
external manager settings.
An external manager is a remote system, such as the Cisco TelePresence Management Suite (TMS),
used to monitor events occurring on the VCS, for example call attempts, connections and
disconnections. The use of an external manager is optional.
Cisco VCS Administrator Guide (X6.1) Page 53 of 401
Page 54
Network and system settings
Field Description Usage tips
Address
and path
To use an external
manager, you must
configure the VCS with the
IP address or host name
and path of the external
manager to be used.
If you are using TMS as your external manager, use the
default path of tms/public/external/management/
SystemManagementService.asmx.
Protocol Determines whether
communications with the
external manager are over
HTTP or HTTPS.
Certificate
verification
mode
Controls whether the
certificate presented by
the external manager is
verified.
If you enable verification, you must also add the
certificate of the issuer of the external manager's
certificate to the file containing the VCS's trusted CA
certificates. This is done from the Security certificates
page (Maintenance > Certificate management >
Security certificates).
Configuring logging levels
The VCS provides an event logging facility for troubleshooting and auditing purposes. The Event Log
records information about such things as calls, registrations, and messages sent and received.
The Logging page (System > Logging) lets you:
n Specify the Log level to set the amount of information to record.
n Copy the event log to a remote syslog server.
Event Log levels
All events have an associated level in the range 1-4, with Level 1 Events considered the most
important. The table below gives an overview of the levels assigned to different events.
Level Assigned Events
Level1High-level events such as registration requests and call attempts. Easily human readable.
For example:
n call attempt/connected/disconnected
n registration attempt/accepted/rejected
Level2All Level 1 Events, plus:
n logs of protocol messages sent and received (SIP, H.323, LDAP and so on) excluding
noisy messages such as H.460.18 keepalives and H.245 video fast-updates
Level3All Level 1 and Level 2 Events, plus:
n protocol keepalives
n call-related SIP signaling messages
Level4The most verbose level: all Level 1, Level 2 and Level 3 Events, plus:
n network level SIP messages
Cisco VCS Administrator Guide (X6.1) Page 54 of 401
Page 55
Network and system settings
See the Events and levels section for a complete list of all events that are logged by the VCS, and the
level at which they are logged.
You can control which events are logged by the VCS by setting the Log level. All events with a level
numerically equal to and lower than the specified logging level are recorded in the Event Log. So, at
level 1, only level 1 events are logged; at level 2, both level 1 and level 2 events are logged, and so on.
The default log level is 1.
Note that:
n Logging at level 3 or level 4 is not usually recommended as the Event Log holds a maximum of 2GB
of data and logging at these levels on a busy system could cause the Event Log to be recycled too
quickly.
n Changes to the event log level affect both the Event Log that you can view via the web interface,
and the information that is copied to the remote log server (if any) that you have configured.
n Changes to the event log level are not retrospective. If you change the event log level, it will only
effect what is logged from that point onwards.
Remote logging
The Event Log is always stored locally on the VCS. However, it is often convenient to collect copies
of all event logs from various systems in a single location. A computer running a BSD-style syslog
server, as defined in RFC 3164 [4], may be used as the central log server. Note that:
n A VCS will not act as a central logging server for other systems.
n Events are always logged locally (to the Event Log) regardless of whetheror not remote logging is
enabled.
n The VCS may use any of the 23 available syslog facilities for different messages. Specifically,
LOCAL0..LOCAL7 (facilities 16..23) are used by different components of the application software
on the VCS.
To enable remote logging, you must configure the VCS with the IP addresses or Fully Qualified
Domain Names (FQDNs) of the Remote syslog servers to where the Event Log is written. Up to 4
servers can be specified. Note that these servers cannot be another VCS.
Cisco VCS Administrator Guide (X6.1) Page 55 of 401
Page 56
Protocols
Protocols
This section provides information about the pages that appear under the VCS configuration >
Protocols menu.
It includes the following information:
n an overview of H.323 and the H.323 configuration options available on the VCS
n an overview of SIP and the SIP configuration options available on the VCS
n how to configure the VCS to act as a SIP to H.323 gateway
About H.323
The VCS supports the H.323 protocol: it is an H.323 gatekeeper.
It will also provide interworking between H.323 and SIP, translating between the two protocols to
enable endpoints that only support one of these protocols to call each other. In order to support H.323,
the H.323 mode must be enabled.
Using the VCS as an H.323 gatekeeper
As an H.323 gatekeeper, the VCS accepts registrations from H.323 endpoints and provides call
control functions such as address translation and admission control.
To enable the VCS as an H.323 Gatekeeper, you must ensure that H.323 mode is set to On (VCS
configuration > Protocols > H.323).
Note that this is the default setting, so the VCS will work as an H.323 gatekeeper "out of the box",
without any other special configuration.
H.323 endpoint registration
H.323 endpoints in your network must register with the VCS in orderto use it as their gatekeeper.
There are two ways an H.323 endpoint can locate a VCS with which to register: manually or
automatically. The option is configured on the endpoint itself under the Gatekeeper Discovery setting
(consult your endpoint manual for how to access this setting).
n If the mode is set to automatic, the endpoint will try to register with any VCS it can find. It does this
by sending out a Gatekeeper Discovery Request, to which eligible VCSs will respond.
n If the mode is set to manual, you must specify the IP address of the VCS with which you want your
endpoint to register, and the endpoint will attempt to register with that VCS only.
Preventing automatic H.323 registrations
You can prevent H.323 endpoints being able to register automatically with the VCS by disabling Auto
Discovery on the VCS (VCS configuration > Protocols > H.323).
About SIP
The VCS supports the SIP protocol. It acts as a SIP registrar, SIP proxy and as a SIP Presence
Server.
The VCS can provide interworking between SIP and H.323, translating between the two protocols to
enable endpoints that only support one of these protocols to call each other.
To support SIP:
Cisco VCS Administrator Guide (X6.1) Page 56 of 401
Page 57
Protocols
n SIP mode must be enabled.
n At least one of the SIP transport protocols (UDP, TCP or TLS) must be active. Note that the use of
UDP is not recommended for video as SIP message sizes are frequently larger than a single UDP
packet.
VCS as a SIP registrar
For a SIP endpoint to be contactable via its alias, it must register its Address of Record (AOR) and its
location with a SIP registrar. The SIP registrar maintains a record of the endpoint’s details against the
endpoint’s AOR. When a call is received for that AOR, the SIP registrar refers to the record in order to
find the endpoint to which it corresponds. (Note that the same AOR can be used by more than one SIP
endpoint at the same time, although to ensure that all endpoints are found they must all register with
the same VCS or VCS cluster.)
A SIP registraronly accepts registrations for domains for which it is authoritative. The VCS can act as
a SIP registrar for up to 20 domains.
SIP aliases always take the form username@domain. To make the VCS act as a SIP registrar, you
must configure it with the SIP domains for which it will be authoritative. It will then handle registration
requests for any endpoints attempting to register with an alias that includes that domain.
Whetheror not the VCS accepts a registration request depends on its registration control settings.
SIP endpoint registration
There are two ways a SIP endpoint can locate a registrar with which to register: manually or
automatically. The option is configured on the endpoint itself under the SIP Server Discovery option
(consult your endpoint user guide for how to access this setting; it may also be referred to as Proxy
Discovery).
n If the Server Discovery mode is set to automatic, the endpoint will send a REGISTER message to
the SIP server that is authoritative for the domain with which the endpoint is attempting to register.
For example, if an endpoint is attempting to register with a URI of john.smith@example.com,
the request will be sent to the registrar authoritative for the domain example.com. The endpoint
can discover the appropriate server through a variety of methods including DHCP, DNS or
provisioning, depending upon how the video communications network has been implemented.
n If the Server Discovery mode is set to manual, the user must specify the IP address or FQDN of
the registrar (VCS or VCS cluster) with which they want to register, and the endpoint will attempt to
register with that registrar only.
The VCS is a SIP server and a SIP registrar.
n If an endpoint is registered to the VCS, the VCS will be able to forward inbound calls to that
endpoint.
n If the VCS is not configured with any SIP domains, the VCS will act as a SIP server. It may proxy
registration requests to another registrar, depending upon the SIP registration proxy mode
setting.
SIP registration resiliency
The VCS supports multiple client-initiated connections (also referred to as "SIP outbound") as outlined
in RFC 5626 [41].
This allows SIP endpoints that support RFC 5626 to be simultaneously registered to multiple VCS
cluster peers. This provides extra resiliency: if the endpoint loses its connection to one cluster peer it
will still be able to receive calls via one of its other registration connections.
Cisco VCS Administrator Guide (X6.1) Page 57 of 401
Page 58
Protocols
VCS as a SIP proxy server
The VCS acts as a SIP proxy server when SIP mode is enabled. The role of a proxy server is to
forward requests (such as REGISTER and INVITE) from endpoints or other proxy servers on to further
proxy servers or to the destination endpoint.
The VCS's behavioras a SIP proxy server is determined by:
n the SIP registration proxy mode setting
n the presence of Route Set information in the request header
n whether the proxy server from which the request was received is a neighbor of the VCS
A Route Set specifies the path to take when requests are proxied between an endpoint and its
registrar. For example, when a REGISTER request is proxied by a VCS, the VCS adds a path header
component to the request. This signals that calls to that endpoint should be routed through the VCS.
This is usually required in situations where firewalls exist and the signalling must follow a specified
path to successfully traverse the firewall. Formore information about path headers, see RFC 3327
[10].
When the VCS proxies a request that contains Route Set information, it forwards it directly to the URI
specified in the path. Any call processing rules configured on the VCS are bypassed. This may
present a security risk if the information in the Route Set cannot be trusted. For this reason, you can
configure how the VCS proxies requests that contain Route Sets by setting the SIP registration
proxy mode as follows:
n Off: requests containing Route Sets are rejected. This setting provides the highest level of security.
n Proxy to known only: requests containing Route Sets are proxied only if the request was received
from a known zone.
n Proxy to any: requests containing Route Sets are always proxied.
In all cases, requests that do not have Route Sets are proxied as normal in accordance with existing
call processing rules. This setting only applies to dialog-forming requests, such as INVITE and
SUBSCRIBE. Other requests, such as NOTIFY, are always proxied regardless of this setting.
Proxying registration requests
If the VCS receives a registration request for a domain for which it is not acting as a Registrar (the
VCS does not have that SIP domain configured), then the VCS may proxy the registration request
onwards. This depends on the SIP registration proxy mode setting, as follows:
n Off: the VCS does not proxy any registration requests. They are rejected with a “403 Forbidden”
message.
n Proxy to known only: the VCS proxies the request in accordance with existing call processing rules,
but only to known neighbor, traversal client and traversal server zones.
n Proxy to any: this is the same as Proxy to known only but for all zone types i.e. it also includes
ENUM and DNS zones.
Accepting proxied registration requests
If the VCS receives a proxied registration request, in addition to the VCS's standard registration
controls, you can also control whether the VCS accepts the registration depending upon the zone
through which the request was received. You do this through the Accept proxied registrations
setting when configuring a zone.
Proxied registrations are classified as belonging to the zone they were last proxied from. This is
different from non-proxied registration requests which are assigned to a subzone within the VCS.
Cisco VCS Administrator Guide (X6.1) Page 58 of 401
Page 59
Protocols
VCS as a SIP Presence Server
The VCS supports the SIP-based SIMPLE protocol. It can act as a Presence Server and Presence
User Agent for any of the SIP domains for which it is authoritative. For full information on how to
enable and use the VCS as a SIP Presence server, see the Presence section.
Movi v2.0 (or later) clients
As for any other SIP endpoint, the VCS acts as a SIP registrar and SIP proxy for Movi™ v2.0 (or later)
clients - no other special support or configuration is required on the VCS.
H.323 configuration
The H.323 page (VCS configuration > Protocols > H.323) is used to enable and disable H.323 on
the VCS, and configure H.323-specific ports and settings.
Field Description Usage tips
H.323 mode Enables or disables H.323
on the VCS. H.323 support
is On by default
Registration
UDP port
The listening port for H.323
UDP registrations. Default
is 1719.
The default VCS configuration uses standard port
numbers so you can use H.323 services out of the box
without having to first set these up.
Call
signaling
TCP port
The listening port for H.323
call signaling. Default is
1720.
Call
signaling
port range
start and
end
Specifies the lower port in
the range used by H.323
calls after they are
established. Default is
15000.
The call signaling port range must be great enough to
support all the required concurrent calls.
Registration
conflict
mode
Determines how the
system behaves if an
endpoint attempts to
register an alias currently
registered from another IP
address.
Reject: denies the new
registration. This is the
default.
Overwrite: deletes the
original registration and
replaces it with the new
registration.
An H.323 endpoint may attempt to register with the
VCS using an alias that has already been registered on
the VCS from another IP address. The reasons for this
could include:
n Two endpoints at different IP addresses are
attempting to register using the same alias.
n A single endpoint has previously registered using a
particular alias. The IP address allocated to the
endpoint then changes, and the endpoint attempts to
re-register using the same alias.
Reject is useful if your priority is to prevent two users
registering with the same alias. Overwrite is useful if
your network is such that endpoints are often allocated
new IP addresses, because it will prevent unwanted
registration rejections.
Cisco VCS Administrator Guide (X6.1) Page 59 of 401
Page 60
Protocols
Field Description Usage tips
Time to live The interval (in seconds) at
which an H.323 endpoint
must re-register with the
VCS in order to confirm
that it is still functioning.
Default is 1800.
Some older endpoints do not support the ability to
periodically re-register with the system. In this case,
and in any other situation where the system has not had
a confirmation from the endpoint within the specified
period, it will send an IRQ to the endpoint to verify that it
is still functioning.
Call time to
live
The interval (in seconds) at
which the VCS polls the
endpoints in a call to verify
that they are still in the call.
Default is 120.
If the endpoint does not respond, the call will be
disconnected.
The system polls endpoints in a call regardless of
whether the call type is traversal or non-traversal.
Auto
discover
Determines whether it will
respond to Gatekeeper
Discovery Requests sent
out by endpoints. The
default is On.
To prevent H.323 endpoints being able to register
automatically with the VCS, set Auto discover to Off.
This means that endpoints can only register with the
VCS if their Gatekeeper Discovery setting is Manual
and they have been configured with the VCS’s IP
address.
Caller ID Specifies whether the
prefix of the ISDN gateway
is inserted into the caller's
E.164 number presented
on the destination
endpoint.
Including the prefix allows the recipient to directly return
the call.
SIP configuration
The SIP page (VCS configuration > Protocols > SIP > Configuration) is used to enable and
disable SIP on the VCS, and configure SIP-specific ports and settings.
Field Description Usage tips
SIP mode Enables and disables SIP functionality (SIP
registrar and SIP proxy services) on the VCS.
Default is On.
This mode must be enabled to
use either the Presence Server
or the Presence User Agent.
Registration
expire delta
(seconds)
The period within which a SIP endpoint must reregister with the VCS to prevent its registration
expiring. Default is 60.
This applies only to endpoints
registered with the VCS. It
does not apply to endpoints
whose registrations are
proxied through the VCS.
Cisco VCS Administrator Guide (X6.1) Page 60 of 401
Page 61
Protocols
Field Description Usage tips
SIP
registration
proxy mode
Specifies how proxied registrations and requests
containing Route Sets are handled.
Off: registration requests are not proxied (but are
still permitted locally if the VCS is authoritative for
that domain). Requests with existing Route Sets
are rejected.
Proxy to known only: registration requests are
proxied in accordance with existing call processing
rules, but only to known neighbor, traversal client
and traversal server zones. Requests containing
Route Sets are proxied only if they were received
from a known zone.
Proxy to any: registration requests are proxied in
accordance with existing call processing rules to all
known zones. Requests containing Route Sets are
always proxied.
Default is Off.
SIP
protocols
and ports
The VCS supports SIP over UDP, TCP and TLS
transport protocols. You can configure whether or
not incoming and outgoing connections using each
protocol are supported, and if so, the ports on which
the VCS listens for such connections.
This is done using the Mode and Port settings for
each protocol. The default mode for each protocol
is On; the default ports are:
n UDP port: 5060
n TCP port: 5060
n TLS port: 5061
At least one of the transport
protocols must be set to a
Mode of On for SIP
functionality to be supported.
TCP
outbound
port start /
end
The range of ports the VCS uses when TCP and
TLS connections are established. The default range
is 25000 to 29999.
The range must be sufficient to
support all required concurrent
connections.
Session
refresh
interval
(seconds)
The maximum time allowed between session
refresh requests for SIP calls. Default is 1800.
For further information refer to
the definition of Session-
Expires in RFC 4028 [14].
Minimum
session
refresh
interval
(seconds)
The minimum value the VCS will negotiate for the
session refresh interval for SIP calls. Default is 500.
For further information refer to
the definition of Min-SE header
in RFC 4028 [14].
Cisco VCS Administrator Guide (X6.1) Page 61 of 401
Page 62
Protocols
Field Description Usage tips
Require
UDP BFCP
mode
Controls whether the VCS requires the use of the
com.tandberg.udp.bfcp extension for
endpoints that support it.
The default settings for these
modes are not supported by
some neighbor systems so
make sure you select the
appropriate zone profile when
configuring zones.
Require
Duo Video
mode
Controls whether the VCS requires the use of the
com.tandberg.sdp.duo.enable extension for
endpoints that support it.
Configuring SIP domains
The Domains page (VCS configuration > Protocols > SIP > Domains) lists the SIP domains for
which the VCS is authoritative. The VCS will act as a SIP Registrar and Presence Server for these
domains, and will accept registration requests for any SIP endpoints attempting to register with an
alias that includes these domains.
The domain name can comprise multiple levels. Each level's name can only contain letters, digits and
hyphens, with each level separated by a period (dot). A level name cannot start or end with a hyphen,
and the final level name must start with a letter. An example valid domain name is 100.example-
name.com.
Configuring SIP and H.323 interworking
The Interworking page (VCS configuration > Protocols > Interworking) lets you configure
whether or not the VCS acts as a gateway between SIP and H.323 calls.
The VCS is able to act as a gateway between SIP and H.323, translating calls from one protocol to the
other. This is known as “interworking”.
By default, the VCS acts as a SIP-H.323 and H.323-SIP gateway but only if at least one of the
endpoints that are involved in the call is locally registered. You can change this setting so that the
VCS will act as a SIP-H.323 gateway regardless of whether the endpoints involved are locally
registered. You also have the option to disable interworking completely.
The options for the H.323 <-> SIP interworking mode are:
n Off: the VCS will not act as a SIP-H.323 gateway.
n Registered only: the VCS will act as a SIP-H.323 gateway but only if at least one of the endpoints is
locally registered.
n On: the VCS will act as a SIP-H.323 gateway regardless of whether the endpoints are locally
registered.
You are recommended to leave this setting as Registered only (where calls are interworked only if at
least one of the endpoints is locally registered). Unless yournetwork is correctly configured, setting it
to On (where all calls can be interworked) may result in unnecessary interworking, for example where
a call between two H.323 endpoints is made over SIP, or vice versa.
Searching by protocol
When searching a zone, the VCS will first perform the search using the protocol of the incoming call. If
the search was unsuccessful the VCS may then search the zone again using the alternative protocol,
depending on where the search came from and the Interworking mode.
n If the request has come from a neighboring system and Interworking mode is set to Registered
only, the VCS will search the local zone using both protocols, and all other zones using the native
Cisco VCS Administrator Guide (X6.1) Page 62 of 401
Page 63
Protocols
protocol only (because it will interwork the call only if one of the endpoints is locally registered).
n If Interworking mode is set to On, or the request has come from a locally registered endpoint, the
VCS will search the local zone and all external zones using both protocols.
Note: calls for which the VCS acts as a SIP to H.323 gateway are traversal calls. They will therefore
require a traversal call license.
Enabling SIP endpoints to dial H.323 numbers
SIP endpoints can only make calls in the form of URIs - e.g. name@domain. If the caller does not
specify a domain when placing the call, the SIP endpoint will automatically append its own domain to
the number that is dialed.
So if you dial 123 from a SIP endpoint, the search will be placed for 123@domain. If the H.323
endpoint being dialed is just registered as 123, the VCS won't be able to locate the alias 123@domain
and the call will fail. The solutions are to either:
n Ensure all your endpoints, both H.323 and SIP, register with an alias in the form name@domain.
n Create a pre-search transform on the VCS that strips the @domain portion of the alias for those
URIs that are in the form of number@domain.
Refer to the pre-search transforms section for information about how to configure pre-search
transforms, and to the stripping @domain for dialing to H.323 numbers section for an example of
how to do this.
Cisco VCS Administrator Guide (X6.1) Page 63 of 401
Page 64
Registration control
Registration control
This section provides information about the pages that appear under the VCS configuration >
Registration menu.
It includes the following information:
n an overview of the VCS's registration policies
n how to control registrations using Allow Lists and Deny Lists
About registrations
For an endpoint to use the VCS as its H.323 gatekeeper or SIP registrar, the endpoint must first
register with the VCS. The VCS can be configured to control which devices are allowed to register
with it by using the following mechanisms:
n a device authentication process based on the username and password supplied by the endpoint
n a registration restriction policy that uses either Allow Lists or Deny Lists, the VCS's on-box
directory service or an external policy service to specify which aliases can and cannot register with
the VCS
n restrictions based on IP addresses and subnet ranges through the specification of subzone
membership rules and subzone registration policies
You can use these mechanisms together. For example, you can use authentication to verify an
endpoint’s identity from a corporate directory, and registration restriction to control which of those
authenticated endpoints may register with a particular VCS.
For specific information about how registrations are managed across peers in a cluster, see the
Sharing registrations across peers section.
Finding a VCS with which to register
Before an endpoint can register with a VCS, it must determine which VCS it can or should be
registering with. This setting is configured on the endpoint, and the process is different for SIP and
H.323.
Registrations on a VCS Expressway
If a traversal-enabled endpoint registers directly with a VCS Expressway, the VCS Expressway will
provide the same services to that endpoint as a VCS Control, with the addition of firewall traversal.
Traversal-enabled endpoints include all Cisco TelePresence Expressway™ endpoints and third-party
endpoints which support the ITU H.460.18 and H.460.19 standards.
Endpoints that are not traversal-enabled can still register with a VCS Expressway, but they may not
be able to make or receive calls through the firewall successfully. This will depend on a number of
factors:
n whether the endpoint is using SIP or H.323
n the endpoint’s position in relation to the firewall
n whether there is a NAT in use
n whether the endpoint is using a public IP address
For example, if an endpoint is behind a NAT or firewall, it may not be able to receive incoming calls and
may not be able to receive media for calls it has initiated. SIP endpoints can also work behind a NAT
but can only receive video if they send it as well.
To ensure firewall traversal will work successfully for H.323 endpoints behind a NAT, the endpoint
must be traversal-enabled.
Cisco VCS Administrator Guide (X6.1) Page 64 of 401
Page 65
Registration control
MCU, gateway and Content Server registration
H.323 systems such as gateways, MCUs and Content Servers can also register with a VCS. They
are known as locally registered services. These systems are configured with their own prefix, which
they provide to the VCS when registering. The VCS will then know to route all calls that begin with that
prefix to the gateway, MCU or Content Server as appropriate. These prefixes can also be used to
control registrations.
SIP devices cannot register prefixes. If your dial plan dictates that a SIP device should be reached via
a particular prefix, then you should add the device as a neighbor zone with an associated search rule
using a pattern match equal to the prefix to be used.
Note that the Cisco TelePresence MPS 200 and MPS 800, and the Cisco TelePresence Content
Server both support Expressway. They can therefore register directly with a VCS Expressway for
firewall traversal.
Configuring registration restriction policy
The Registration configuration page (VCS configuration > Registration > Configuration) is
used to control how the VCS manages its registrations.
The Restriction policy option specifies the policy to use when determining which endpoints may
register with the VCS. The options are:
n None: any endpoint may register.
n Allow List: only those endpoints with an alias that matches an entry in the Allow List may register.
n Deny List: all endpoints may register, unless they match an entry on the Deny List.
n Directory: only endpoints that register an alias listed in the directory service may register.
n Policy service: only endpoints that register with details allowed by the external policy service may
register.
The default is None.
If you use an Allow List or Deny List, you must also go to the appropriate Registration Allow List or
Registration Deny List configuration page to create the list.
Policy service
The Policy service option is used if you want to refer all registration restriction policy decisions out to
an external service.
If you select this option an extra set of configuration fields appear so that you can specify the
connection details of the external service:
Field Description Usage tips
Protocol The protocol used to connect to the policy
service.
The VCS automatically supports
HTTP to HTTPS redirection when
communicating with the policy service
server.
Certificate
verification
mode
Controls whether the certificate presented
by the policy service is verified when
connecting over HTTPS.
When enabled, the value specified in
the Server address field must be
contained within the server's X.509
certificate (in either the Subject
Common Name or the Subject
Alternative Name attributes).
Cisco VCS Administrator Guide (X6.1) Page 65 of 401
Page 66
Registration control
Field Description Usage tips
HTTPS
certificate
revocation
list (CRL)
checking
Controls certificate revocation list checking
of the certificate supplied by the policy
service.
When enabled, the server's X.509
certificate is checked against the HTTPS
certificate revocation list.
Use the CRL management page to
configure how the VCS uploads CRL
files.
Server
address 1 3
The IP address or Fully Qualified Domain
Name (FQDN) of the service.
For resiliency, up to three server
addresses can be supplied.
Path The URL of the service.
Status path The path for obtaining the remote service
status.
Username The username used by the VCS to log in
and query the service.
Password The password used by the VCS to log in and
query the service.
The maximum plaintext length is 30
characters (which is subsequently
encrypted).
Default CPL The default CPL used by the VCS if the
policy service is unavailable.
This defaults to <reject
status='403'
reason='Service
Unavailable'/> but you could
change it, for example, to redirect to an
answer service or recorded message.
See About policy services for more information about how the VCS communicates with external policy
services.
Registering aliases
After the device authentication process (if required) has been completed, the endpoint will then
attempt to register its aliases with the VCS.
H.323
When registering, the H.323 endpoint presents the VCS with one or more of the following:
n one or more H.323 IDs
n one or more E.164 aliases
n one or more URIs
Users of other registered endpoints can then call the endpoint by dialing any of these aliases.
n You are recommended to register your H.323 endpoints using a URI. This facilitates interworking
between SIP and H.323, as SIP endpoints register using a URI as standard.
n You are recommended to not use aliases that reveal sensitive information. Due to the nature of
H.323, call setup information is exchanged in an unencrypted form.
Cisco VCS Administrator Guide (X6.1) Page 66 of 401
Page 67
Registration control
SIP
When registering, the SIP endpoint presents the VCS with its contact address (IP address) and logical
address (Address of Record). The logical address is considered to be its alias, and will generally be in
the form of a URI.
Attempts to register using an existing alias
An endpoint may attempt to register with the VCS using an alias that is already registered to the
system. How this is managed depends on how the VCS is configured and whether the endpoint is SIP
or H.323.
n H.323: an H.323 endpoint may attempt to register with the VCS using an alias that has already been
registered on the VCS from another IP address. You can control how the VCS behaves in this
situation by configuring the Registration conflict mode, on the H.323 page (VCS configuration >
Protocols > H.323).
n SIP: a SIP endpoint will always be allowed to register using an alias that is already in use from
another IP address. When a call is received for this alias, all endpoints registered using that alias
will be called simultaneously. This SIP feature is known as “forking”.
Blocking registrations
If you have configured the VCS to use a Deny List, you will have an option to block the registration.
This will add all the aliases used by that endpoint to the Deny List.
Removing existing registrations
After a restriction policy has been activated, it controls all registration requests from that point forward.
However, any existing registrations may remain in place, even if the new list would otherwise block
them. Therefore, you are recommended to manually remove all existing unwanted registrations after
you have implemented a restriction policy.
To manually remove a registration, go to Status > Registrations > By device, select the
registrations you want to remove, and click Unregister.
If the registered device is in an active call and its registration is removed (or expires), the effect on the
call is dependent on the protocol:
n H.323: the call is taken down.
n SIP: the call stays up by default. This SIP behaviorcan be changed but only via the CLI by using
the command xConfiguration SIP Registration Call Remove.
Re-registrations
All endpoints must periodically re-register with the VCS in order to keep their registration active. If you
do not manually delete the registration, the registration could be removed when the endpoint attempts
to re-register, but this depends on the protocol being used by the endpoint:
n H.323 endpoints may use "light" re-registrations which do not contain all the aliases presented in
the initial registration, so the re-registration may not get filtered by the restriction policy. If this is the
case, the registration will not expire at the end of the registration timeout period and must be
removed manually.
n SIP re-registrations contain the same information as the initial registrations so will be filtered by the
restriction policy. This means that, after the list has been activated, all SIP registrations will
disappear at the end of their registration timeout period.
Cisco VCS Administrator Guide (X6.1) Page 67 of 401
Page 68
Registration control
The frequency of re-registrations is determined by the Registration expire delta setting for SIP (VCS
configuration > Protocols > SIP > Configuration) and the Time to live setting for H.323 (VCS
configuration > Protocols > H.323).
About Allow and Deny Lists
When an endpoint attempts to register with the VCS it presents a list of aliases. One of the methods
provided by the VCS to control which endpoints are allowed to register is to set the Restriction policy
(on the Configuring registration restriction policy page) to Allow List or Deny List and then to include
any one of the endpoint’s aliases on the Allow List orthe Deny List as appropriate. Each list can
contain up to 2,500 entries.
When an endpoint attempts to register, each of its aliases is compared with the patterns in the relevant
list to see if it matches. Only one of the aliases needs to appear in the Allow List or the Deny List for
the registration to be allowed or denied.
For example, if the Restriction policy is set to Deny List and an endpoint attempts to register using
three aliases, one of which matches a pattern on the Deny List, that endpoint’s registration will be
denied. Likewise, if the Restriction policy is set to Allow List, only one of the endpoint’s aliases
needs to match a pattern on the Allow List for it to be allowed to register using all its aliases.
Allow Lists and Deny Lists are mutually exclusive: only one may be in use at any given time. You can
also control registrations at the subzone level. Each subzone's registration policy can be configured to
allow or deny registrations assigned to it via the subzone membership rules.
Configuring the registration Allow List
The Registration Allow List page (VCS configuration > Registration > Allow List) shows the
endpoint aliases and alias patterns that are allowed to register with the VCS. Only one of an endpoint's
aliases needs to match an entry in the Allow Listfor the registration to be allowed.
To use the Allow List, you must select a Restriction policy of Allow List on the Registration
configuration page.
The configurable options are:
Field Description Usage tips
Pattern The pattern against which
an alias is compared.
Type The way in which the
Pattern must match the
alias. Options are:
Exact: the alias must
match the Pattern
exactly.
Prefix: the alias must
begin with the Pattern.
Suffix: the alias must end
with the Pattern.
Regex: the Pattern is a
regular expression.
You can test whether a pattern matches a particular alias
by using the Check pattern tool (Maintenance > Tools
> Check pattern).
Cisco VCS Administrator Guide (X6.1) Page 68 of 401
Page 69
Registration control
Field Description Usage tips
Description An optional free-form
description of the entry.
Configuring the registration Deny List
The Registration Deny List page (VCS configuration > Registration > Deny List)shows the
endpoint aliases and alias patterns that are not allowed to register with the VCS. Only one of an
endpoint's aliases needs to match an entry in the Deny Listfor the registration to be denied.
To use the Deny List, you must select a Restriction policy of Deny List on the Registration
configuration page.
The configurable options are:
Field Description Usage tips
Pattern The pattern against which
an alias is compared.
Type The way in which the
Pattern must match the
alias. Options are:
Exact: the alias must
match the Pattern
exactly.
Prefix: the alias must
begin with the Pattern.
Suffix: the alias must end
with the Pattern.
Regex: the Pattern is a
regular expression.
You can test whether a pattern matches a particular alias
by using the Check pattern tool (Maintenance > Tools
> Check pattern).
Description An optional free-form
description of the entry.
Cisco VCS Administrator Guide (X6.1) Page 69 of 401
Page 70
Device authentication
Device authentication
This section provides information about the VCS's Authentication Policy and the pages that appear
under the VCS configuration > Authentication menu.
It includes the following information:
n an overview of device authentication and how to configure the VCS's Authentication Policy
n how to configure the VCS to authenticate endpoints against either the VCS's local database or a
remote LDAP database
n how to configure the username and password that is used by the VCS whenever it is required to
authenticate with external systems
About device authentication
Device authentication controls whether systems attempting to communicate with the VCS must
authenticate with it first.
The VCS can be configured to allow both authenticated and unauthenticated endpoints to register to
the same VCS, but to subsequently control what those endpoints can do based upon their
authentication status.
Authentication Policy
The VCS's Authentication Policy is applied at the zone and subzone levels. It controls how the VCS
authenticates incoming messages from that zone or subzone and whether those messages are
rejected or are subsequently treated as authenticated or unauthenticated within the VCS.
The Authentication Policy settings allow you to:
n control registrations via subzones: when authentication is enabled for a particular subzone,
endpoints must authenticate with the VCS before they can register
n limit the services available to unregistered or unauthenticated endpoints and devices:
search rules and CPL can be restricted to only apply to authenticated requests
n cater for endpoints from third-party suppliers that do not support authentication within
their registration mechanism: assign registrations requests for particular devices into a subzone
that is configured to treat all such trusted endpoints registered within that subzone as authenticated
See Authentication Policy configuration options for a full description of how the policy is applied per
zone and subzone, and how its behavior varies depending on message protocol.
Authentication mechanism
The authentication process uses a username and password-based challenge-response scheme to
check a device's credentials.
The actual mechanism usedby the device to supply its credentials to the VCS depends on the
protocol being used:
n H.323: any necessary credentials are contained within the incoming request.
n SIP: credentials are not contained within the initial request. Instead the VCS sends a challenge
back to the sender that asks for its credentials. However, if a SIPmessage has already been
authenticated (for example by another VCS on a previous hop), that system may insert information
into the SIP message to show that it has been authenticated. You can control whether the VCS
chooses to trust any authentication carried out at an earlier stage by configuring a zone's SIP
authentication trust setting.
Cisco VCS Administrator Guide (X6.1) Page 70 of 401
Page 71
Device authentication
The VCS can check the credentials supplied within the message against either a local database or a
remote LDAP repository. See Device authentication configuration for more information.
Note: accurate timestamps play an important part in authentication, helping to guard against replay
attacks. For this reason, if you are using device authentication, both the VCS and the endpoints must
use an NTP server to synchronize their system time.
Authentication Policy configuration options
The Authentication Policy behavior varies for H.323 messages, SIP messages received from local
domains and SIP messages from non-local domains. The following tables summarize the policy
behavior when applied at the zone and subzone level, and how it varies depending on the message
protocol.
Zone-level Authentication Policy
The VCS's Authentication Policy at the zone level controls how the VCS authenticates incoming
messages from that zone. Note that the Authentication Policy is configurable for the Default Zone but
does not apply to DNS and ENUM zones.
To configure a zone's Authentication policy, go to the Edit zone page (VCS configuration >
Zones, then click View/Edit or the name of the zone). The policy is set to Do not check credentials by
default.
The behavior varies for H.323 and SIP messages as shown in the tables below:
H.323
Authentication
policy
Behavior
Check
credentials
Messages are classified as either authenticated or unauthenticated depending on
whether any credentials in the message can be verified against the authentication
database.
If no credentials are supplied, the message is always classified as
unauthenticated.
Do not check
credentials
Message credentials are not checked and all messages are classified as
unauthenticated.
Treat as
authenticated
Message credentials are not checked and all messages are classified as
authenticated.
SIP
The behavior for SIP messages at the zone level depends upon the SIP authentication trust mode
setting (meaning whether the VCS trusts any pre-existing authenticated indicators - known as PAsserted-Identity headers - within the received message) and whether the message was received
from a local domain (a domain for which the VCS is authoritative) or a non-local domain.
Cisco VCS Administrator Guide (X6.1) Page 71 of 401
Page 72
Device authentication
Authentication
policy
Trust In local domain Outside local domain
Check
credentials
Off Messages are challenged for
authentication.
Messages that fail authentication are
rejected.
Messages that pass authentication
are classified as authenticated and a
P-Asserted-Identity header is inserted
into the message.
Messages are not challenged for
authentication.
All messages are classified as
unauthenticated.
Any existing P-Asserted-Identity
headers are removed.
On Messages with an existing P-
Asserted-Identity header are
classified as authenticated, without
further challenge. The P-AssertedIdentity header is passed on
unchanged (keeping the originator's
asserted ID).
Messages without an existing PAsserted-Identity header are
challenged. If authentication passes,
the message is classified as
authenticated and a P-AssertedIdentity header is inserted into the
message. If authentication fails, the
message is rejected.
Messages are not challenged for
authentication.
Messages with an existing PAsserted-Identity header are
classified as authenticated, and the
header is passed on unchanged.
Messages without an existing PAsserted-Identity header are
classified as unauthenticated.
Do not check
credentials
Off Messages are not challenged for
authentication.
All messages are classified as
unauthenticated.
Any existing P-Asserted-Identity
headers are removed.
Messages are not challenged for
authentication.
All messages are classified as
unauthenticated.
Any existing P-Asserted-Identity
headers are removed.
On Messages are not challenged for
authentication.
Messages with an existing PAsserted-Identity header are
classified as authenticated, and the
header is passed on unchanged.
Messages without an existing PAsserted-Identity header are
classified as unauthenticated.
Messages are not challenged for
authentication.
Messages with an existing PAsserted-Identity header are
classified as authenticated, and the
header is passed on unchanged.
Messages without an existing PAsserted-Identity header are
classified as unauthenticated.
Cisco VCS Administrator Guide (X6.1) Page 72 of 401
Page 73
Device authentication
Authentication
policy
Trust In local domain Outside local domain
Treat as
authenticated
Off Messages are not challenged for
authentication.
All messages are classified as
authenticated.
Any existing P-Asserted-Identity
header is removed and a new one
containing the VCS's originator ID is
inserted into the message.
Messages are not challenged for
authentication.
All messages are classified as
unauthenticated.
Any existing P-Asserted-Identity
headers are removed.
On Messages are not challenged for
authentication.
All messages are classified as
authenticated.
Messages with an existing PAsserted-Identity header are passed
on unchanged. Messages without an
existing P-Asserted-Identity header
have one inserted.
Messages are not challenged for
authentication.
Messages with an existing PAsserted-Identity header are
classified as authenticated, and the
header is passed on unchanged.
Messages without an existing PAsserted-Identity header are
classified as unauthenticated.
Subzone-level Authentication Policy
The VCS's Authentication Policy at the subzone level controls how the VCS authenticates incoming
messages (including registration requests) from that subzone.
To configure a subzone's Authentication policy, go to the Edit subzone page (VCS configuration
> Local Zone >Subzones, then click View/Edit or the name of the subzone). You can also configure
the Default Subzone's Authentication policy. The policy is set to Do not check credentials by
default.
The behavior varies for H.323 and SIP messages as shown in the tables below:
H.323
Authentication
policy
Behavior
Check
credentials
Messages are classified as either authenticated or unauthenticated depending on
whether any credentials in the message can be verified against the authentication
database. Messages that pass authentication are classified as authenticated.
If no credentials are supplied, the message is always classified as
unauthenticated.
Note that unauthenticated registration requests are rejected.
Do not check
credentials
Message credentials are not checked and all messages are classified as
unauthenticated.
Treat as
authenticated
Message credentials are not checked and all messages are classified as
authenticated.
Cisco VCS Administrator Guide (X6.1) Page 73 of 401
Page 74
Device authentication
SIP
The behavior for SIP messages depends upon whether the message was received from a local
domain (a domain for which the VCS is authoritative) or a non-local domain.
Authentication
policy
In local domain Outside local domain
Check
credentials
Messages are challenged for
authentication and those that
pass are classified as
authenticated.
Messages (including
registration requests) that fail
authentication are rejected.
SIP messages received from non-local
domains are all treated in the same manner,
regardless of the subzone's Authentication
policy setting:
Messages are not challenged for
authentication.
All messages are classified as
unauthenticated.
Do not check
credentials
Messages are not challenged
for authentication.
All messages are classified as
unauthenticated.
Treat as
authenticated
Messages are not challenged
for authentication.
All messages are classified as
authenticated.
SIP authentication trust
If a VCS is configured to use device authentication it will authenticate incoming SIP registration and
INVITE requests. If the VCS then forwards the request on to a neighbor zone such as another VCS,
that receiving system will also authenticate the request. In this scenario the message has to be
authenticated at every hop.
To simplify this so that a device’s credentials only have to be authenticated once (at the first hop), and
to reduce the number of SIP messages in your network, you can configure neighbor zones to use the
Authentication trust mode setting.
This is then used in conjunction with the zone's Authentication Policy to control whether preauthenticated SIP messages received from that zone are trusted and are subsequently treated as
authenticated or unauthenticated within the VCS. Pre-authenticated SIP requests are identified by the
presence of a P-Asserted-Identity field in the SIP message header as defined by RFC 3325 [35]
The Authentication trust mode settings are:
n On: pre-authenticated messages are trusted without further challenge and subsequently treated as
authenticated within the VCS. Unauthenticated messages are challenged if the Authentication
Policy is set to Check credentials.
n Off: any existing authenticated indicators (the P-Asserted-Identity header) are removed from the
message. Messages from a local domain are challenged if the Authentication Policy is set to
Check credentials.
Note: you are recommended to enable authentication trust only if the neighbor zone is part of a
network of trusted SIP servers.
Cisco VCS Administrator Guide (X6.1) Page 74 of 401
Page 75
Device authentication
Device authentication configuration
The Device authentication configuration page (VCS configuration > Authentication > Devices
> Configuration) is used to control the type of database used by the VCS to store the authentication
credentials used by systems and devices that attempt to communicate with the VCS.
Authentication database
To verify the identity of a device, the VCS needs access to a database on which all authentication
credential information (usernames, passwords, and other relevant information) is stored. This
database may be located either locally on the VCS, or on an LDAP Directory Server. The VCS looks
up the endpoint’s username in the database and retrieves the authentication credentials for that entry.
If the credentials match those supplied by the endpoint, the registration is allowed to proceed.
The Database type setting determines which database the VCS uses during authentication:
n Local database: the local authentication database is used. You must configure the Local
authentication database to use this option.
n LDAP database: a remote LDAP database is used. You must configure the LDAP server to use this
option.
The default is Local database.
Note that:
n If the VCS is a traversal server, you must ensure that each traversal client’s authentication
credentials are entered into the selected database.
n The VCS supports the ITU H.235 [1] specification for authenticating the identity of H.323 network
devices with which it communicates.
Endpoint credentials used for authentication
An endpoint must supply the VCS with a username and password if it is required to authenticate with
the VCS, for example when attempting to register and the relevant subzone's Authentication Policy
is set to Check credentials.
For Cisco endpoints using H.323, the username is typically the endpoint’s Authentication ID; for
Cisco endpoints using SIP it is typically the endpoint’s Authentication username.
For details of how to configure endpoints with a username and password, please consult the endpoint
manual.
Device authentication using LDAP
The Device LDAP configuration page (VCS configuration > Authentication > Devices > LDAP
configuration) is used to configure a connection to the LDAP database used during device
authentication.
Authentication process
If the VCS is using an LDAP server for authentication, the process is as follows:
1. The endpoint presents its username and authentication credentials (these are generated using its
password) to the VCS, and the aliases with which it wants to register.
2. The VCS looks up the username in the LDAP database and obtains the authentication and alias
information for that entry.
3. If the authentication credentials match those supplied by the endpoint, the registration will
continue.
Cisco VCS Administrator Guide (X6.1) Page 75 of 401
Page 76
Device authentication
The VCS then determines which aliases the endpoint is allowed to attempt to register with, based on
the Alias origin setting. For H.323 endpoints, you can use this setting to override the aliases
presented by the endpoint with those in the H.350 directory, or you can use them in addition to the
endpoint’s aliases. For SIP endpoints, you can use this setting to reject a registration if the endpoint’s
AOR does not match that in the LDAP database.
Configuring the LDAP server directory
The directory on the LDAP server should be configured to implement the ITU H.350 specification [2] to
store credentials for devices with which the VCS communicates. The directory should also be
configured with the aliases of endpoints that will register with the VCS. See LDAP configuration for
device authentication for instructions on configuring LDAP servers.
LDAP server settings
The configurable options are:
Field Description Usage tips
LDAP
server
The IP address or FQDN (or server address, if a
DNS Domain name has also been configured)
of the LDAP server.
Port The IP port of the LDAP server. Typically, non-
secure connections use 389 and secure
connections use 636. The default is 389.
Encryption Determines whether the connection to the
LDAP server is encrypted using Transport
Layer Security (TLS).
n TLS: TLS encryption is used for the
connection to the LDAP server.
n Off: no encryption is used.
The default is Off.
If you are connecting to an LDAP
database using TLS encryption, you
need to upload the trusted CA
certificate for the LDAP server.
Click Upload a CA certificate file
for TLS to go to the Security
certificates page.
User DN The user distinguished name used by the VCS
when binding to the LDAP server.
Password The password used by the VCS when binding to
the LDAP server.
Base DN The area of the directory on the LDAP server to
search for credential information. This should be
specified as the Distinguished Name (DN) in the
LDAP directory under which the H.350 objects
reside.
Cisco VCS Administrator Guide (X6.1) Page 76 of 401
Page 77
Device authentication
Field Description Usage tips
Alias
origin
Determines how aliases are checked and
registered. The options are:
n LDAP: for SIP registrations the AOR
presented by the endpoint is registered
providing it is listed in the LDAP database for
the endpoint's username.
For H.323 registrations:
l At least one of the aliases presented by
the endpoint must be listed in the LDAP
database for that endpoint's username. If
none of the presented aliases are listed it
is not allowed to register.
l The endpoint will register with all of the
aliases (up to a maximum of 20) listed in
the LDAP database. Aliases presented
by the endpoint that are not in the LDAP
database will not be registered.
l If no aliases are listed in the LDAP
database, the endpoint will register with
all the aliases it presented.
l If no aliases are presented by the
endpoint, it will register with all the
aliases listed in the LDAP database for
its username.
n Combined: the aliases presented by the
endpoint are used in addition to any listed in
the LDAP database for the endpoint’s
username. In other words, this is the same
as for LDAP, except that if an endpoint
presents an alias that is not in the LDAP
database, it will be allowed to register with
that alias.
n Endpoint: the aliases presented by the
endpoint are used; any in the LDAP database
are ignored. If no aliases are presented by
the endpoint, it is not allowed to register.
The default is LDAP.
When Alias origin is LDAP,
MCUs are treated as a special
case. They register with the
presented aliases and ignore any
aliases in the LDAP database. (This
is to allow MCUs to additively
register aliases for conferences.)
The current status of the connection to the specified LDAP server is displayed at the bottom of the
page.
Note that if you want to use an LDAP database for device authentication, you must also go to the
Authentication configuration page and select a Database type of LDAP database.
Device LDAP schemas
The Device LDAP schemas page (VCS configuration > Authentication > Devices > LDAP
schemas) provides a set of .ldif files to be downloaded from the VCS and installed on the LDAP
server.
Cisco VCS Administrator Guide (X6.1) Page 77 of 401
Page 78
Device authentication
Click Download to display the required schema in your browser from where you can use the
browser's Save As command to store it on your file system.
See LDAP configuration for device authentication for more information.
Authentication using a local database
The Local authentication database page (VCS configuration > Authentication > Devices >
Local database) page lists and allows you to manage the credentials stored in the local authentication
database.
The local authentication database is included as part of your VCS system. The database can hold up
to 2,500 credentials, each consisting of a name and password. These credentials are used for
device, traversal client and TURN client authentication.
To add new credentials to the database, click New.
The maximum plaintext length for a password is 128 characters, which is then encrypted.
Note that:
n The same credentials can be used by more than one endpoint - you do not need to have a separate
entry in the database for each endpoint.
n To use the local authentication database, you must select a Database type of Local database on
the Device authentication configuration page.
n If the Starter Pack option key is installed the local authentication database will include a pre-
configured set of authentication credentials. To ensure correct operation of the TURN server in
conjunction with the Starter Pack, do not delete or modify the StarterPackTURNUser entry in the
local authentication database.
Authenticating with external systems
The Outbound connection credentials page (VCS configuration > Authentication > Outbound
connection credentials) is used to configure a username and password that the VCS will use
whenever it is required to authenticate with external systems.
For example, when the VCS is forwarding an invite from an endpoint to another VCS, that other
system may have authentication enabled and will therefore require your local VCS to provide it with a
username and password.
Note that these settings are not used by traversal client zones. Traversal clients, which must always
authenticate with traversal servers before they can connect, configure their connection credentials per
traversal client zone.
Cisco VCS Administrator Guide (X6.1) Page 78 of 401
Page 79
Zones and neighbors
Zones and neighbors
This section describes how to configure zones and neighbors on the VCS (VCS configuration >
Zones).
It includes the following information:
n an overview of your video communications network
n ways of structuring a dial plan
n an overview of the Local Zone and its subzones
n how to configure different zone types
About your video communications network
The most basic implementation of a video communications network is a single VCS connected to the
internet with one or more endpoints registered to it. However, depending on the size and complexity of
your enterprise the VCS may be part of a network of endpoints, other VCSs and other network
infrastructure devices, with one or more firewalls between it and the internet. In such situations you
may want to apply restrictions to the amount of bandwidth used by and between different parts of your
network.
This section will give you an overview of the different parts of the video communications network and
the ways in which they can be connected. This information should allow you to configure your VCS to
best suit your own infrastructure.
Example network diagram
The diagram below shows the different components of a VCS (i.e. subzones and zones) and how they
interrelate. Using a VCS Control as the example Local Zone, it shows that it is made up of a numberof
subzones which are all connected by links. The Local Zone is also connected to external VCSs and to
the internet via different types of zones.
All these components are described in more detail in the sections that follow.
Cisco VCS Administrator Guide (X6.1) Page 79 of 401
Page 80
Zones and neighbors
Structuring your dial plan
As you start deploying more than one VCS, it is useful to neighbor the systems together so that they
can query each other about their registered endpoints. Before you start, you should consider how you
will structure your dial plan. This will determine the aliases assigned to the endpoints, and the way in
which the VCSs are neighbored together. The solution you choose will depend on the complexity of
your system. Some possible options are described in the following sections.
Flat dial plan
The simplest approach is to assign each endpoint a unique alias and divide the endpoint registrations
between the VCSs. Each VCS is then configured with all the other VCS as neighbor zones. When one
VCS receives a call for an endpoint which is not registered with it, it will send out a Location Request
to all the other neighbor VCSs.
While conceptually simple, this sort of flat dial plan does not scale very well. Adding or moving a VCS
requires changing the configuration of every VCS, and one call attempt can result in a large number of
location requests. This option is therefore most suitable for a deployment with just one or two VCSs
plus its peers.
Structured dial plan
An alternative deployment would use a structured dial plan where endpoints are assigned an alias
based on the system they are registering with.
If you are using E.164 aliases, each VCS would be assigned an area code. When the VCSs are
neighbored together, each neighbor zone would have an associated search rule configured with its
corresponding area code as a prefix (a Mode of Alias pattern match and a Pattern type of Prefix). That
neighbor would then only be queried for calls to numbers which begin with its prefix.
In a URI based dial plan, similar behavior may be obtained by configuring search rules for each
neighbor with a suffix to match the desired domain name.
It may be desirable to have endpoints register with just the subscriber number — the last part of the
E.164 number. In that case, the search rule could be configured to strip prefixes before sending the
query to that zone.
A structured dial plan minimizes the number of queries issued when a call is attempted. However, it
still requires a fully connected mesh of all VCSs in your deployment. A hierarchical dial plan can
simplify this.
Hierarchical dial plan
In this type of structure one VCS is nominated as the central VCS for the deployment, and all other
VCSs are neighbored with it alone.
The central VCS is configured with:
n each VCS as a neighbor zone
n search rules for each zone that have a Mode of Alias pattern match and the target VCS's prefix (as
with the structured dial plan) as the Pattern string
Each VCS is configured with:
n the central VCS as a neighbor zone
n a search rule with a Mode of Any alias and a Target of the central VCS
There is no need to neighbor the VCSs with each other. Adding a new VCS now only requires
changing configuration on the new VCS and the central VCS.
Cisco VCS Administrator Guide (X6.1) Page 80 of 401
Page 81
Zones and neighbors
However, failure of the central VCS in this situation could cause significant disruption to
communications. Consideration should be given to the use of clustering for increased resilience.
Note: for H.323 calls, if Optimal call routing is enabled you must ensure that all search rules are
configured with a Source of Any. If the Source is configured to All zones, H.323 calls will fail to
connect. This is because the H.323 SETUP message, having followed the optimized route
established by the original LRQ or ARQ, will appear to the target VCS as coming from an unknown
zone. SIP calls, however, are successfully routed if the search rule Source is All zones (because in
SIP the search and call setup is combined into one message).
About the Local Zone and subzones
The collection of all endpoints, gateways, MCUs and Content Servers registered with the VCS makes
up its Local Zone.
The Local Zone is divided into subzones. These include an automatically created Default Subzone
and up to 1000 manually configurable subzones.
When an endpoint registers with the VCS it is allocated to an appropriate subzone based on subzone
membership rules. These rules specify the range of IP addresses or alias pattern matches for each
subzone. If an endpoint’s IP address or alias does not match any of the membership rules, it is
assigned to the Default Subzone.
The Local Zone may be independent of network topology, and may comprise multiple network
segments. The VCS also has two special types of subzones:
n the Traversal Subzone, which is always present
n the Cluster Subzone, which is always present but only used when your VCS is part of a cluster
Bandwidth management
The Local Zone’s subzones are used for bandwidth management. After you have set up your
subzones you can apply bandwidth limits to:
n individual calls between two endpoints within the subzone
n individual calls between an endpoint within the subzone and another endpoint outside of the
subzone
n the total of calls to or from endpoints within the subzone
For full details of how to create and configure subzones, and apply bandwidth limitations to subzones
including the Default Subzone and Traversal Subzone, see the Bandwidth control section.
Local Zone searches
One of the functions of the VCS is to route a call received from a locally registered endpoint or external
zone to its appropriate destination. Calls are routed based on the address or alias of the destination
endpoint.
The VCS searches for a destination endpoint in its Local Zone and its configured external zones. You
can prioritize the order in which these zones are searched, and filter the search requests sent to each
zone, based on the address or alias being searched for. This allows you to reduce the potential number
of search requests sent to the Local Zone and out to external zones, and speed up the search process.
For further information about how to configure search rules for the Local Zone, see the Configuring
search and zone transform rules section.
Cisco VCS Administrator Guide (X6.1) Page 81 of 401
Page 82
Zones and neighbors
About zones
A zone is a collection of endpoints, either all registered to a single system (for example a VCS,
Gatekeeper, or Border Controller), or located in a certain way such as via an ENUM or DNS lookup.
Zones are used to:
n control through links whether calls can be made between your local subzones and these other
zones
n manage the bandwidth of calls between your local subzones and endpoints in other zones
n search for aliases that are not registered locally
n control the services available to endpoints within that zone through the VCS's Authentication Policy
You can configure up to 1000 zones. Each zone is configured as one of the following zone types:
n Neighbor: a connection to a neighbor system of the local VCS.
n Traversal client: the local VCS is a traversal client of the system being connected to, and there is a
firewall between the two.
n Traversal server: the local VCS is a traversal server for the system being connected to, and there is
a firewall between the two.
n ENUM: the zone contains endpoints discoverable by ENUM lookup.
n DNS: the zone contains endpoints discoverable by DNS lookup.
The VCS also has a pre-configured Default Zone.
n See the Zone configuration section for information about the configuration options available for all
zone types.
n See the Configuring search and zone transform rules section for information about including zones
as targets for search rules.
Default Zone
Any incoming calls from endpoints or other devices that are unregistered or not recognized as
belonging to the Local Zone or any of the existing configured zones are deemed to be coming from the
Default Zone.
The VCS comes pre-configured with the Default Zone and default links between it and both the Default
Subzone and the Traversal Subzone. The purpose of the Default Zone is to manage incoming calls
from unrecognized endpoints to the VCS. You can do this by:
n deleting the default links; this prevents any incoming calls from unrecognized endpoints
n applying pipes to the default links; this lets you control the bandwidth consumed by incoming calls
from unrecognized endpoints
n configuring the Default Zone's Authentication Policy
Note that the Default Zone cannot be deleted and its only configurable option is its Authentication
Policy setting.
Zone configuration
The Zones page (VCS configuration > Zones) lists all the zones that have been configured on the
VCS, and lets you create, edit and delete zones.
To neighbor with another system (such as another VCS or gatekeeper), create a connection over a
firewall to a traversal server or traversal client, or discover endpoints via an ENUM or DNS lookup,
you must configure a zone on the local VCS. The VCS also has a pre-configured Default Zone which
cannot be deleted.
When adding a new zone you must specify its Type. The zone type indicates the nature of the
connection and determines which configuration options are available. For traversal server zones,
Cisco VCS Administrator Guide (X6.1) Page 82 of 401
Page 83
Zones and neighbors
traversal client zones and neighbor zones this includes providing information about the neighbor
system such as its IP address and ports.
Note: connections between the VCS and neighbor systems must be configured to use the same SIP
transport type, that is they must both be configured to use TLS or both be configured to use TCP. In
software versions prior to X5.1 a connection could be established if one system was configured to use
TLS and the other used TCP. Any connection failures due to transport type mismatches are recorded
in the Event Log.
After creating a zone you would normally make it a target of at least one of your zone policy search
rules (VCS configuration > Dial plan > Search rules) otherwise search requests will not be sent to
that zone.
Common zone configuration options
The zone configuration options depend upon the zone Type, however the following options apply to
every zone type:
Field Description Usage tips
Name The name acts as a unique identifier, allowing you to
distinguish between zones of the same type.
Type The nature of the specified zone, in relation to the local
VCS:
Neighbor: connects the local VCS to a neighbor system.
Traversal client: connects the local VCS to a traversal
server.
Traversal server: connects the local VCS Expressway to a
traversal client.
ENUM: enables ENUM dialing via the local VCS.
DNS: enables the local VCS to locate endpoints and other
systems by using DNS lookups.
After a zone has been created,
the Type cannot be changed.
Hop
count
The hop count is the number of times a request will be
forwarded to a neighbor gatekeeper or proxy (see the Hop
counts section for more information). This field specifies the
hop count to use when sending a search request to this
particular zone.
If the search request was
received from another zone
and already has a hop count
assigned, the lower of the two
values is used.
Configuring neighbor zones
A neighbor zone could be a collection of endpoints registered to another system (such as a VCS,
Gatekeeper, or Border Controller), or it could be a SIP device (for example Microsoft Office
Communications Server (OCS) 2007). The other system or SIP device is referred to as a neighbor.
Neighbors can be part of your own enterprise network, part of a separate network, or even standalone
systems.
You create a neighbor relationship with the other system by adding it as a neighbor zone on your local
VCS. After you have added it, you can:
n query the neighbor about its endpoints
n apply transforms to any requests before they are sent to the neighbor
Cisco VCS Administrator Guide (X6.1) Page 83 of 401
Page 84
Zones and neighbors
n control the bandwidth used for calls between your local VCS and the neighbor zone
Note that:
n neighbor zone relationship definitions are one-way; adding a system as a neighbor to your VCS
does not automatically make your VCS a neighbor of that system
n inbound calls from any configured neighbor are identified as coming from that neighbor
n systems that are configured as cluster peers (formerly known as Alternates) must not be configured
as neighbors to each other
The configurable options for a neighbor zone are:
Field Description Usage tips
Configuration section:
Name The name acts as a unique identifier, allowing
you to distinguish between zones of the same
type.
Type The nature of the specified zone, in relation to
the local VCS. Select Neighbor.
After a zone has been created, the
Type cannot be changed.
Hop count The hop count is the number of times a
request will be forwarded to a neighbor
gatekeeper or proxy (see the Hop counts
section for more information). This field
specifies the hop count to use when sending
a search request to this particular zone.
If the search request was received
from another zone and already has
a hop count assigned, the lower of
the two values is used.
H.323 section:
Mode Determines whether H.323 calls are allowed
to and from the neighbor system.
Port Specifies the port on the neighbor system
used for H.323 calls from the local VCS.
This must be the same port
number as that configured on the
neighbor system as its H.323
UDP port. If the neighbor is
another VCS, this is the port found
under the VCS configuration >
Protocols > H.323 in the
Registration UDP Port field.
SIP section:
Mode Determines whether SIP calls are allowed to
and from the neighbor system.
Port Specifies the port on the neighbor system
used for SIP connections from the local VCS.
This must be the same port
number as that configured on the
neighbor system as its SIP TCP,
SIP TLS or SIP UDP listening port
(depending on which SIP
Transport mode is in use).
Cisco VCS Administrator Guide (X6.1) Page 84 of 401
Page 85
Zones and neighbors
Field Description Usage tips
Transport Determines which transport type is used for
SIP calls to and from the neighbor system.
The default is TLS.
TLS verify
mode
Controls whether the VCS performs X.509
certificate checking against the neighbor
system when communicating over TLS.
If the neighbor system is another
VCS, both systems can verify
each other's certificate (known as
mutual authentication). See TLS
certificate verification of neighbor
systems for more information.
Accept
proxied
registrations
Controls whether proxied SIP registrations
routed through this zone are accepted.
This setting only applies to
registration requests for a domain
for which the VCS is acting as a
Registrar. For requests for other
domains the SIP registration
proxy mode setting applies. See
Proxying registration requests for
more information.
Authentication section:
Authentication
policy
Controls how the VCS authenticates
incoming messages from this zone and
whether they are subsequently treated as
authenticated, unauthenticated, or are
rejected. The behaviorvaries for H.323
messages, SIP messages that originate from
a local domain and SIP messages that
originate from non-local domains.
See Authentication Policy
configuration options for more
information.
SIP
authentication
trust mode
Controls whether authenticated SIP
messages (ones containing a P-AssertedIdentity header) from this zone are trusted
without further challenge.
See SIP authentication trust for
more information.
Location section:
Location
Peer 1 to Peer
6 address
The IP address or FQDN of the neighbor
system.
If the neighbor is a VCS cluster, this includes
all of the peers in the cluster.
See Neighboring the local VCS to
another VCS cluster for more
information.
Advanced section:
Cisco VCS Administrator Guide (X6.1) Page 85 of 401
Page 86
Zones and neighbors
Field Description Usage tips
Zone profile Determines how the zone's advanced
settings are configured.
Default: uses the factory defaults.
Custom: allows you to configure each
setting individually.
Preconfigured profiles: choose one of the
preconfigured profiles to automatically use
the appropriate settings required for
connections to that type of system.
The default is Default.
See Zone configuration:
advanced settings for details on
the Advanced settings.
Do not use the Custom option or
configure the individual Advanced
settings except on the advice of
Cisco customer support.
Configuring traversal client zones
To traverse a firewall, the VCS must be connected with a traversal server (for example a VCS
Expressway or a TANDBERG Border Controller).
In this situation your local VCS is a traversal client, so you create a connection with the traversal
server by creating a traversal client zone on your local VCS. You then configure the client zone with
details of the corresponding zone on the traversal server. (The traversal server must also be
configured with details of the VCS client zone.)
After you have neighbored with the traversal server you can:
n use the neighbor as a traversal server
n query the traversal server about its endpoints
n apply transforms to any queries before they are sent to the traversal server
n control the bandwidth used for calls between your local VCS and the traversal server
For full details on how traversal client zones and traversal server zones work togetherto achieve
firewall traversal, see About firewall traversal.
An NTP server must be configured for traversal zones to work.
The configurable options for a traversal client zone are:
Field Description Usage tips
Configuration section:
Name The name acts as a unique identifier, allowing
you to distinguish between zones of the same
type.
Type The nature of the specified zone, in relation to
the local VCS. Select Traversal client.
After a zone has been created, the
Type cannot be changed.
Hop count The hop count is the number of times a
request will be forwarded to a neighbor
gatekeeper or proxy (see the Hop counts
section for more information). This field
specifies the hop count to use when sending
a search request to this particular zone.
If the search request was received
from another zone and already has
a hop count assigned, the lower of
the two values is used.
Cisco VCS Administrator Guide (X6.1) Page 86 of 401
Page 87
Zones and neighbors
Field Description Usage tips
Connection credentials section:
Username and
Password
Traversal clients must always authenticate
with traversal servers by providing their
authentication credentials. Each traversal
client zone must specify a Username and
Password to be used for authentication with
the traversal server.
Multiple traversal client zones can
be configured on a VCS, each with
distinct credentials, to connect to
one or more service providers.
H.323 section:
Mode Determines whether H.323 calls are allowed
to and from the traversal server.
Protocol Determines which of the two firewall traversal
protocols (Assent or H.460.18) to use for calls
to the traversal server.
See Firewall traversal protocols
and ports for more information.
Port The port on the traversal server to use for
H.323 calls to and from the local VCS.
For firewall traversal to work via
H.323, the traversal server must
have a traversal server zone
configured on it to represent this
VCS, using this same port
number.
SIP section:
Mode Determines whether SIP calls are allowed to
and from the traversal server.
Port The port on the traversal server to use for
SIP calls to and from the VCS.
This must be different from the listening
ports used for incoming TCP, TLS and UDP
SIP calls (typically 5060 and 5061).
For firewall traversal to work via
SIP, the traversal server must
have a traversal server zone
configured on it to represent this
VCS, using this same transport
type and port number.
Transport Determines which transport type is used for
SIP calls to and from the traversal server. The
default is TLS.
TLS verify
mode
Controls X.509 certificate checking and
mutual authentication between this VCS and
the traversal server when communicating
over TLS.
See TLS certificate verification of
neighbor systems for more
information.
Accept
proxied
registrations
Controls whether proxied SIP registrations
routed through this zone are accepted.
This setting only applies to
registration requests for a domain
for which the VCS is acting as a
Registrar. For requests for other
domains the SIP registration
proxy mode setting applies. See
Proxying registration requests for
more information.
Cisco VCS Administrator Guide (X6.1) Page 87 of 401
Page 88
Zones and neighbors
Field Description Usage tips
Poison mode Determines if SIP requests sent to systems
located via this zone are "poisoned" such that
if they are received by this VCS again they
will be rejected.
Authentication section:
Authentication
policy
Controls how the VCS authenticates
incoming messages from this zone and
whether they are subsequently treated as
authenticated, unauthenticated, or are
rejected. The behaviorvaries for H.323
messages, SIP messages that originate from
a local domain and SIP messages that
originate from non-local domains.
See Authentication Policy
configuration options for more
information.
Client settings section:
Retry interval The interval in seconds with which a failed
attempt to establish a connection to the
traversal server should be retried.
Location section:
Peer 1 to Peer
6 address
The IP address or FQDN of the traversal
server.
n If the traversal server is a VCS
Expressway cluster, this should include
all of its peers.
n If the traversal server is a TANDBERG
Border Controller, this should include all
its Alternates.
See Neighboring the local VCS to
another VCS cluster for more
information.
Configuring traversal server zones
A VCS Expressway is able to act as a traversal server, providing firewall traversal on behalf of
traversal clients (for example, VCS Controls or gatekeepers).
To act as a traversal server, the VCS Expressway must have a special type of two-way relationship
with each traversal client. To create this connection, you create a traversal server zone on your local
VCS Expressway and configure it with the details of the corresponding zone on the traversal client.
(The client must also be configured with details of the VCS Expressway.)
After you have neighbored with the traversal client you can:
n provide firewall traversal services to the traversal client
n query the traversal client about its endpoints
n apply transforms to any queries before they are sent to the traversal client
n control the bandwidth used for calls between your local VCS and the traversal client
Note: traversal client-server zone relationships must be two-way. For firewall traversal to work, the
traversal server and the traversal client must each be configured with the other’s details (see Quick
guide to VCS traversal client - server configuration for more information). The client and server will
then be able to communicate over the firewall and query each other. For full details on how traversal
Cisco VCS Administrator Guide (X6.1) Page 88 of 401
Page 89
Zones and neighbors
client zones and traversal server zones work together to achieve firewall traversal, see About firewall
traversal.
An NTP server must be configured for traversal zones to work.
The configurable options for a traversal server zone are:
Field Description Usage tips
Configuration section:
Name The name acts as a unique identifier,
allowing you to distinguish between zones of
the same type.
Type The nature of the specified zone, in relation to
the local VCS. Select Traversal server.
After a zone has been created, the
Type cannot be changed.
Hop count The hop count is the number of times a
request will be forwarded to a neighbor
gatekeeper or proxy (see the Hop counts
section for more information). This field
specifies the hop count to use when sending
a search request to this particular zone.
If the search request was received
from another zone and already has
a hop count assigned, the lower of
the two values is used.
Connection credentials section:
Username Traversal clients must always authenticate
with traversal servers by providing their
authentication credentials. The
authentication username is the name that
the traversal client must provide to the VCS
Expressway.
n If the traversal client is a VCS, this must
be its connection credentials Username
as configured in its traversal client zone.
n If the traversal client is a TANDBERG
Gatekeeper, this is its System Name.
There must also be an entry in the
VCS Expressway's local
authentication database for the
client’s authentication username
and password. To check the list
of entries and add it if necessary,
go to the Local authentication
database page. Either:
n click on the Add/Edit local
authentication database link
n go to VCS configuration >
Authentication > Local
database
H.323 section:
Mode Determines whether H.323 calls are allowed
to and from the traversal client.
Protocol Determines the protocol (Assent or
H.460.18) to use to traverse the
firewall/NAT.
See Firewall traversal protocols
and ports for more information.
Port The port on the local VCS Expressway to
use for H.323 calls to and from the traversal
client.
Cisco VCS Administrator Guide (X6.1) Page 89 of 401
Page 90
Zones and neighbors
Field Description Usage tips
H.460.19
demultiplexing
mode
Determines whether or not the same two
ports are used for media by two or more
calls.
On: all calls from the traversal client use the
same two ports for media.
Off: each call from the traversal client uses
a separate pair of ports for media.
SIP section:
Mode Determines whether SIP calls are allowed to
and from the traversal client.
Port The port on the local VCS Expressway to
use for SIP calls to and from the traversal
client.
This must be different from the
listening ports used for incoming
TCP, TLS and UDP SIP calls
(typically 5060 and 5061).
Transport Determines which transport type is used for
SIP calls to and from the traversal client. The
default is TLS.
TLS verify
mode and
subject name
Controls X.509 certificate checking and
mutual authentication between this VCS
and the traversal client.
If TLS verify mode is enabled, a TLS
verify subject name must be specified.
This is the certificate holder's name to look
for in the traversal client's X.509 certificate.
See TLS certificate verification of
neighbor systems for more
information.
Accept
proxied
registrations
Controls whether proxied SIP registrations
routed through this zone are accepted.
This setting only applies to
registration requests for a domain
for which the VCS is acting as a
Registrar. For requests for other
domains the SIP Registration
Proxy Mode setting applies. See
Proxying registration requests for
more information.
Poison mode Determines if SIP requests sent to systems
located via this zone are "poisoned" such
that if they are received by this VCS again
they will be rejected.
Authentication section:
Cisco VCS Administrator Guide (X6.1) Page 90 of 401
Page 91
Zones and neighbors
Field Description Usage tips
Authentication
policy
Controls how the VCS authenticates
incoming messages from this zone and
whether they are subsequently treated as
authenticated, unauthenticated, or are
rejected. The behaviorvaries for H.323
messages, SIP messages that originate from
a local domain and SIP messages that
originate from non-local domains.
See Authentication Policy
configuration options for more
information.
UDP / TCP probes section:
UDP retry
interval
The frequency (in seconds) with which the
client sends a UDP probe to the VCS
Expressway if a keep alive confirmation has
not been received.
The default UDP and TCP probe
retry intervals are suitable for most
situations. However, if you
experience problems with NAT
bindings timing out, they may need
to be changed.
UDP retry
count
The number of times the client attempts to
send a UDP probe to the VCS Expressway
during call setup.
UDP keep
alive interval
The interval (in seconds) with which the
client sends a UDP probe to the VCS
Expressway after a call is established, in
order to keep the firewall’s NAT bindings
open.
TCP retry
interval
The interval (in seconds) with which the
traversal client sends a TCP probe to the
VCS Expressway if a keep alive confirmation
has not been received.
TCP retry
count
The number of times the client attempts to
send a TCP probe to the VCS Expressway
during call setup.
TCP keep alive
interval
The interval (in seconds) with which the
traversal client sends a TCP probe to the
VCS Expressway when a call is in place, in
order to maintain the firewall’s NAT bindings.
Configuring ENUM zones
ENUM zones allow you to locate endpoints via an ENUM lookup. You can create one or more search
rules for ENUM zones based on the ENUM DNS suffix used and/or by pattern matching of the
endpoints’ aliases.
After you have configured one or more ENUM zones, you can:
n apply transforms to alias search requests directed to that group of endpoints
n control the bandwidth used for calls between your local VCS and each group of ENUM endpoints
Full details of how to use and configure ENUM zones are given in the About ENUM dialing section.
The configurable options for an ENUM zone are:
Cisco VCS Administrator Guide (X6.1) Page 91 of 401
Page 92
Zones and neighbors
Field Description Usage tips
Name The name acts as a unique identifier, allowing you to
distinguish between zones of the same type.
Type The nature of the specified zone, in relation to the local
VCS. Select ENUM.
After a zone has been created,
the Type cannot be changed.
Hop
count
The hop count is the number of times a request will be
forwarded to a neighbor gatekeeper or proxy (see the Hop
counts section for more information). This field specifies the
hop count to use when sending a search request to this
particular zone.
If the search request was
received from another zone
and already has a hop count
assigned, the lower of the two
values is used.
DNS
suffix
The domain to be appended to the transformed E.164
number to create an ENUM domain for which this zone is
queried.
H.323
mode
Determines whether H.323 records are looked up for this
zone.
SIP
mode
Determines whether SIP records are looked up for this
zone.
Configuring DNS zones
DNS zones allow you to locate endpoints via a DNS lookup. You can create one or more search rules
for DNS zones based on pattern matching of the endpoints’ aliases.
After you have configured one or more DNS zones, you can:
n apply transforms to alias search requests directed to that group of endpoints
n control the bandwidth used for calls between your local VCS and each group of DNS endpoints
See About URI dialing for more information on configuring and using DNS zones.
The configurable options for a DNS zone are:
Field Description Usage tips
Name The name acts as a unique identifier, allowing
you to distinguish between zones of the same
type.
Type The nature of the specified zone, in relation to
the local VCS. Select DNS.
After a zone has been created, the Type
cannot be changed.
Hop
count
The hop count is the number of times a request
will be forwarded to a neighbor gatekeeper or
proxy (see the Hop counts section for more
information). This field specifies the hop count to
use when sending a search request to this
particular zone.
If the search request was received from
another zone and already has a hop
count assigned, the lower of the two
values is used.
H.323
mode
Determines whether H.323 calls are allowed to
systems and endpoints located using DNS
lookups via this zone.
Cisco VCS Administrator Guide (X6.1) Page 92 of 401
Page 93
Zones and neighbors
Field Description Usage tips
SIP
mode
Determines whether SIP calls are allowed to
systems and endpoints located using DNS
lookups via this zone.
TLS
verify
mode
Controls whether the VCS performs X.509
certificate checking against the destination
system server returned by the DNS lookup.
This setting only applies if the DNS
lookup specifies TLS as the required
protocol. If TLS is not required then the
setting is ignored. See TLS certificate
verification of neighbor systems for more
information.
Zone
profile
Determines how the zone's advanced settings
are configured.
Default: uses the factory defaults.
Custom: allows you to configure each setting
individually.
Preconfigured profiles: choose one of the
preconfigured profiles to automatically use the
appropriate settings required for connections to
that type of system.
The default is Default.
See Zone configuration: advanced
settings for details on the Advanced
settings.
Do not use the Custom option or
configure the individual Advanced
settings except on the advice of Cisco
customer support.
Zone configuration: advanced settings
The table below describes the Advanced and Custom zone configuration options. Some of these
settings only apply to specific zone types.
Note: you should only use the Custom zone profile settings on the advice of Cisco customer support.
Cisco VCS Administrator Guide (X6.1) Page 93 of 401
Page 94
Zones and neighbors
Setting Description Default Applicable
to
Zone profile Determines how the zone's advanced settings are
configured.
Default: uses the factory defaults.
Preconfigured profiles: alternatively, choose one of the
preconfigured profiles to automatically use the appropriate
settings required for connections to that type of system. The
options include:
n Microsoft Office Communications Server 2007: (see the
VCS Control interworking with Microsoft OCS deployment
guide [24] for more information)
n Cisco Unified Communications Manager (see the Cisco
Unified Communications Manager with VCS using a SIP
trunk deployment guide [36] for more information)
n Nortel Communication Server 1000
n Cisco Advanced Media Gateway (see the Microsoft OCS
2007, VCS Control and Cisco AM GW deployment guide
[37] for more information)
n Non-registering device (typically used for non-gatekeeper
devices such as an MCU)
Custom: allows you to configure each Advanced setting
individually. These settings are listed in the remainder of this
table below.
Default Neighbor
zones
DNS
zones
Monitor peer
status
Specifies whether the VCS monitors the status of the zone's
peers. If enabled, H.323 LRQs and/or SIP OPTIONS are
periodically sent to the peers. If a peer fails to respond, that
peer is marked as inactive. If all peers fail to respond the zone
is marked as inactive.
Yes Neighbor
zones
Automatically
respond to
H.323
searches
Determines what happens when the VCS receives an H.323
search, destined for this zone.
Off: an LRQ message is sent to the zone.
On: searches are responded to automatically, without being
forwarded to the zone.
Off Neighbor
zones
Cisco VCS Administrator Guide (X6.1) Page 94 of 401
Page 95
Zones and neighbors
Setting Description Default Applicable
to
Automatically
respond to
SIP searches
Determines what happens when the VCS receives a SIP
search that originated as an H.323 search.
Off: a SIP OPTIONS or SIP INFO message is sent.
On: searches are responded to automatically, without being
forwarded.
This option should normally be left as the default Off.
However, some systems such as Microsoft Office
Communications Server (OCS) 2007 do not accept SIP
OPTIONS messages, so for these zones it must be set to
On. If you change this to On, you must also configure pattern
matches to ensure that only those searches that actually
match endpoints in this zone are responded to. If you do not,
the search will not continue to other lower-priority zones, and
the call will be forwarded to this zone even if it cannot support
it.
Off Neighbor
zones
DNS
zones
Empty
INVITE
allowed
Determines whether the VCS generates a SIP INVITE
message with no SDP to send via this zone. INVITES with
no SDP mean that the destination device is asked to initiate
the codec selection, and are used when the call has been
interworked locally from H.323.
On: SIP INVITEs with no SDP are generated.
Off: SIP INVITEs are generated and a pre-configured SDP is
inserted before the INVITEs are sent.
In most cases this option should normally be left as the
default On. However, some systems such as Microsoft OCS
2007 do not accept invites with no SDP, so for these zones
this should be set to Off.
Note that the settings for the pre-configured SDP are
configurable via the CLI using the xConfiguration
Zones Zone [1..1000] DNS Interworking SIP
commands. They should only be changed on the advice of
Cisco customer support.
On Neighbor
zones
DNS
zones
SIP poison
mode
On: SIP requests sent to systems located via this zone are
"poisoned" such that if they are received by this VCS again
they will be rejected.
Off: SIP requests sent out via this zone that are received by
this VCS again will not be rejected; they will be processed as
normal.
Off Neighbor
zones
Traversal
clients
Traversal
servers
DNS
zones
Cisco VCS Administrator Guide (X6.1) Page 95 of 401
Page 96
Zones and neighbors
Setting Description Default Applicable
to
SIP
encryption
mode
Determines whether or not the VCS allows encrypted SIP
calls on this zone.
Auto: SIP calls are encrypted if a secure SIP transport (TLS)
is used.
Microsoft: SIP calls are encrypted using MS-SRTP.
Off: SIP calls are never encrypted.
This option should normally be left as the default Auto.
However, this must be set to Microsoft for Microsoft Office
Communications Server (OCS) 2007 zones.
Auto Neighbor
zones
SIP SDP
attribute line
limit mode
Determines whether requests containing SDP sent out to this
zone have the length of a=fmtp lines restricted.
On: the length is truncated to the maximum length specified
by the SIP SDP attribute line limit length setting.
Off: the length is not truncated.
The SIP SDP attribute line limit option should normally be
left as the default of Off. However, some systems such as
Microsoft OCS 2007 cannot handle attribute lines longer than
130 characters, so it must be set to On for connections to
these systems.
Off Neighbor
zones
DNS
zones
SIP SDP
attribute line
limit length
If SIP SDP attribute line limit mode is set to On, sets the
maximum line length of a=fmtp SDP lines.
130 Neighbor
zones
DNS
zones
SIP multipart
MIME strip
mode
Controls whether or not multipart MIME stripping is performed
on requests from this zone.
This option should normally be left as the default Off.
However, it must be set to On for connections to a Microsoft
OCS 2007 Release 2 system.
Off Neighbor
zones
SIP UPDATE
strip mode
Controls whether or not the VCS strips the UPDATE method
from the Allow header of all requests and responses received
from, and sent to, this zone.
This option should normally be left as the default Off.
However, some systems such as Microsoft OCS 2007 do not
support the UPDATE method in the Allow header, so for
these zones this should be set to On.
Off Neighbor
zones
Cisco VCS Administrator Guide (X6.1) Page 96 of 401
Page 97
Zones and neighbors
Setting Description Default Applicable
to
Interworking
SIP search
strategy
Determines how the VCS searches for SIP endpoints when
interworking an H.323 call.
Options: the VCS sends an OPTIONS request.
Info: the VCS sends an INFO request.
This option should normally be left as the default Options.
However, some endpoints such as Microsoft Office
Communicator (MOC) clients cannot respond to OPTIONS
requests, so this must be set to Info for connections to a
Microsoft OCS 2007 system.
Options Neighbor
zones
SIP
UDP/BFCP
filter mode
Determines whether INVITE requests sent to this zone filter
out UDP/BFCP. This option may be required to enable
interoperability with SIP devices that do not support the
UDP/BFCP protocol, so this must be set to On for
connections to a Cisco Unified Communications Manager.
On: any media line referring to the UDP/BFCP protocol is
replaced with TCP/BFCP and disabled.
Off: INVITE requests are not modified.
Off Neighbor
zones
DNS
zones
SIP Duo
Video filter
mode
Determines whether INVITE requests sent to this zone filter
out Duo Video. This option may be required to enable
interoperability with SIP devices that do not support Duo
Video, so this must be set to On for connections to a Cisco
Unified Communications Manager.
On: the second video line in any outgoing INVITE request is
removed.
Off: INVITE requests are not modified.
Off Neighbor
zones
DNS
zones
SIP record
route address
type
Controls whether the VCS uses its IP address or host name
in the record-route or path headers of outgoing SIP requests
to this zone.
IP: uses the VCS's IP address.
Hostname: uses the VCS's Local host name (if it is blank
the IP address is used instead).
IP Neighbor
zones
DNS
zones
SIP ProxyRequire
header strip
list
A comma-separated list of option tags to search for and
remove from Proxy-Require headers in SIP requests received
from this zone.
None Neighbor
zones
Cisco VCS Administrator Guide (X6.1) Page 97 of 401
Page 98
Zones and neighbors
Setting Description Default Applicable
to
Include
address
record
Determines whether, if no NAPTR (SIP) or SRV (SIP and
H.323) records have been found for the dialed alias via this
zone, the VCS will then query for A and AAAA DNS records
before moving on to query lower priority zones. If A and
AAAA records exist at the same domain for systems other
than those that support SIP or H.323, this may result in the
VCS believing the search was successful and forwarding
calls to this zone, and the call will fail.
On: the VCS queries for A or AAAA records. If any are found,
the VCS will not then query any lower priority zones.
Off: the VCS will not query for A and AAAA records and
instead will continue with the search, querying the remaining
lower priority zones.
Off DNS zones
Zone configuration: pre-configured profile settings
The table below shows the advanced zone configuration option settings that are automatically applied
for each of the pre-configured profiles.
Setting Microsoft Office
Communications
Server 2007
Cisco Unified
Communications
Manager
Nortel
Communication
Server 1000
Cisco
Advanced
Media
Gateway
Nonregistering
device
Monitor peer
status
Yes Yes Yes Yes No
H.323 searches
are
automatically
responded to
Off Off Off Off On
SIP searches
are
automatically
responded to
Off Off Off Off On
Empty INVITE
allowed
Off On On On On
SIP poison
mode
On Off Off Off Off
SIP encryption
mode
Microsoft Auto Auto Auto Auto
SIP SDP
attribute line limit
mode
On Off Off Off Off
Cisco VCS Administrator Guide (X6.1) Page 98 of 401
Page 99
Zones and neighbors
Setting Microsoft Office
Communications
Server 2007
Cisco Unified
Communications
Manager
Nortel
Communication
Server 1000
Cisco
Advanced
Media
Gateway
Nonregistering
device
SIP SDP
attribute line limit
length
130 130 130 130 130
SIP multipart
MIME strip
mode
On Off Off Off Off
SIP UPDATE
strip mode
On On On On Off
Interworking SIP
search strategy
Info Options Options Options Options
SIP UDP/BFCP
filter mode
Off On Off Off Off
SIP Duo Video
filter mode
On Off Off Off Off
SIP record route
address type
Hostname IP IP IP IP
SIP ProxyRequire header
strip list
<blank> <blank> "com.
nortelnetworks.
firewall"
<blank> <blank>
TLS certificate verification of neighbor systems
When a SIP TLS connection is established between a VCS and a neighbor system, the VCS can be
configured to check the X.509 certificate of the neighbor system to verify its identity. You do this by
configuring the zone’s TLS verify mode setting.
If TLS verification is enabled, the neighbor system's FQDN or IP address, as specified in the Peer
address field of the zone’s configuration, is used to verify against the certificate holder’s name
contained within the X.509 certificate presented by that system. (The name has to be contained in
either the Subject Common Name or the Subject Alternative Name attributes of the certificate.) The
certificate itself must also be valid and signed by a trusted certificate authority.
Note that for traversal server zones, the FQDN or IP address of the connecting traversal client is not
configured, so the required certificate holder’s name is specified separately.
If the neighbor system is another VCS, or it is a traversal client / traversal server relationship, the two
systems can be configured to authenticate each other’s certificates. This is known as mutual
authentication and in this case each VCS acts both as a client and as a server and therefore you must
ensure that each VCS’s certificate is valid both as a client and as a server.
See the Managing security certificates section for more information about certificate verification and
for instructions on uploading the VCS’s server certificate and uploading a list of trusted certificate
authorities.
Cisco VCS Administrator Guide (X6.1) Page 99 of 401
Page 100
Clustering and peers
Clustering and peers
This section describes how to set up a cluster of VCS peers. Clustering is used to increase the
capacity of your VCS deployment and to provide resiliency. The section includes:
n an overview of clustering
n guidelines for setting up and maintaining a cluster
n a list of configuration that is not replicated across cluster peers
n a troubleshooting guide for cluster replication problems
n how registrations and bandwidth are shared across peers
n how clustering works with FindMe, Presence and TMS
n the purpose of the cluster subzone
n how to neighbor a local VCS or cluster to a remote VCS cluster
About clusters
A VCS can be part of a cluster of up to six VCSs. Each VCS in the cluster is a peer of every other
VCS in the cluster. When creating a cluster, you define a cluster name and nominate one peer as the
master from which all relevant configuration is replicated to the otherpeers in the cluster. Clusters are
used to:
n increase the capacity of your VCS deployment compared with a single VCS
n provide redundancy in the rare case that a VCS becomes unavailable (for example, due to a
network or power outage)
Peers share information with each other about their use of bandwidth, registrations, and user
accounts. This allows the cluster to act as one large VCS Local Zone as shown in the example below.
Cisco VCS Administrator Guide (X6.1) Page 100 of 401
Loading...