Page 1
Cisco TelePresence
Video Communication
Server
Administrator Guide
Software version: X8.1.1
D14049.16
April 2014
Page 2
Contents
Introduction 11
About the Cisco TelePresence Video Communication Server (VCS) 12
VCS base applications 13
Standard features 13
Optional features 14
Installation and initial configuration 16
About this guide 17
Related documentation 17
Training 17
Glossary 17
Accessibility notice 17
Using the web interface 18
Using the command line interface (CLI) 19
Web page features and layout 20
What’s new in this version? 22
X8.1.1 22
X8.1 22
Network and system settings 28
Network settings 29
Configuring IP settings 29
Configuring Ethernet settings 31
Configuring DNS settings 32
Configuring Quality of Service settings 33
Intrusion protection 34
Configuring firewall rules 34
Current active firewall rules 36
Configuring automated intrusion protection 36
Network services 40
Configuring system name and access settings 40
Configuring SNMP settings 43
Configuring time settings 45
Configuring the Login page 47
Configuring external manager settings 48
Configuring TMS Provisioning Extension services 49
Firewall traversal 52
About firewall traversal 53
The Expressway solution 53
How does it work? 53
Endpoint traversal technology requirements 54
H.323 firewall traversal protocols 54
SIP firewall traversal protocols 54
Media demultiplexing 54
Firewall traversal configuration overview 55
Configuring a traversal client and server 57
Configuring ports for firewall traversal 58
Configuring the firewall 58
Configuring traversal server ports 58
Cisco VCS Administrator Guide (X8.1.1) Page 2of 507
Page 3
Configuring ports for connections from traversal clients 59
Firewall traversal and authentication 61
Authentication and NTP 61
Configuring Expressway and traversal endpoint communications 62
About ICE and TURN services 63
About ICE 63
About TURN 63
Configuring TURN services 64
Unified Communications 66
Mobile and remote access 67
Jabber client connectivity without VPN 68
Configuring mobile and remote access on VCS 69
Setting up the VCS Control 69
Setting up the VCS Expressway 72
Setting up VCS security certificates 72
Setting up secure VCS traversal zones 74
Checking the status of Unified Communications services 75
Additional configuration 75
Protocols 77
About H.323 78
Using the VCS as an H.323 gatekeeper 78
H.323 endpoint registration 78
Configuring H.323 79
About SIP 81
VCS as a SIP registrar 81
VCS as a SIP proxy server 82
Proxying registration requests 83
VCS as a SIP Presence Server 83
Configuring SIP 84
SIP functionality and SIP-specific transport modes and ports 84
Certificate revocation checking modes 84
Registration controls 85
Authentication controls 87
Configuring domains 88
Configuring the supported services for Unified Communications (VCS Control only) 88
Configuring delegated credential checking (VCS Expressway only) 88
Configuring SIP and H.323 interworking 90
Registration control 92
About registrations 93
Finding a VCS with which to register 93
Registrations on a VCS Expressway 93
MCU, gateway and Content Server registration 94
Configuring registration restriction policy 94
Registering aliases 94
About Allow and Deny Lists 97
Configuring the registration Allow List 97
Configuring the registration Deny List 98
Configuring Registration Policy to use an external service 99
Device authentication 101
Cisco VCS Administrator Guide (X8.1.1) Page 3of 507
Page 4
About device authentication 102
Configuring VCS authentication policy 103
Controlling system behavior for authenticated and non-authenticated devices 104
Authentication policy configuration options 105
SIP authentication trust 108
Configuring delegated credential checking (SIP only) 109
Device provisioning and authentication policy 112
Presence and authentication policy 114
Hierarchical dial plans and authentication policy 115
Practical configuration of authentication policy 116
Configuring VCS authentication methods 116
Configuring authentication to use the local database 119
Using an H.350 directory service lookup via LDAP 120
Using Active Directory database (direct) 123
Configuring the connection to Active Directory Service (ADS) 124
Authenticating with external systems 129
Zones and neighbors 130
About your video communications network 131
Structuring your dial plan 132
Flat dial plan 132
Structured dial plan 132
Hierarchical dial plan 132
About zones 134
Configuring media encryption policy 135
Configuring the B2BUA for media encryption 136
Configuring ICE messaging support 137
About the Local Zone and subzones 138
The Default Zone 139
Configuring the Default Zone 139
Configuring Default Zone access rules 140
Configuring zones 141
Configuring neighbor zones 141
Configuring traversal client zones 144
Configuring traversal server zones 146
Configuring ENUM zones 149
Configuring DNS zones 150
Zone configuration: advanced settings 151
Zone configuration: pre-configured profile settings 154
TLS certificate verification of neighbor systems 155
Configuring a zone for incoming calls only 156
Clustering and peers 157
About clusters 158
License usage within a cluster 160
Managing clusters and peers 162
Setting up a cluster 162
Maintaining a cluster 163
Specifying peer-specific items in clustered systems 164
Sharing registrations across peers 166
Sharing bandwidth across peers 166
Cluster upgrades, backup and restore 167
Cisco VCS Administrator Guide (X8.1.1) Page 4of 507
Page 5
Clustering and Presence 167
Clustering and Cisco TMS 167
About the Cluster Subzone 168
Neighboring the local VCS to another VCS cluster 169
Troubleshooting cluster replication problems 170
Dial plan and call processing 171
Call routing process 172
Configuring hop counts 174
Configuring dial plan settings 175
About the fallback alias 175
About transforms and search rules 176
About pre-search transforms 176
Configuring pre-search transforms 177
Search and zone transform process 178
Configuring search rules 179
Example searches and transforms 182
Filter queries to a zone without transforming 182
Always query a zone with original alias (no transforms) 183
Query a zone for a transformed alias 183
Query a zone for original and transformed alias 184
Query a zone for two or more transformed aliases 185
Stripping @domain for dialing to H.323 numbers 186
Transforms for alphanumeric H.323 ID dial strings 188
Allowing calls to IP addresses only if they come from known zones 190
Configuring search rules to use an external service 191
About Call Policy 194
Configuring Call Policy 194
Configuring Call Policy rules using the web interface 195
Configuring Call Policy using a CPL script 195
Configuring Call Policy to use an external service 197
Supported address formats 199
Dialing by IP address 199
Dialing by H.323 ID or E.164 alias 199
Dialing by H.323 or SIP URI 199
Dialing by ENUM 200
Dialing by IP address 201
About URI dialing 203
URI dialing without DNS 203
URI dialing via DNS 204
URI resolution process using DNS 204
URI dialing via DNS for outgoing calls 205
URI dialing via DNS for incoming calls 207
URI dialing and firewall traversal 209
About ENUM dialing 211
ENUM dialing process 211
Enabling ENUM dialing 211
ENUM dialing for outgoing calls 212
Configuring zones and search rules for ENUM dialing 213
ENUM dialing for incoming calls 215
Configuring DNS servers for ENUM and URI dialing 217
Configuring call routing and signaling 218
Cisco VCS Administrator Guide (X8.1.1) Page 5of 507
Page 6
Identifying calls 219
Disconnecting calls 220
Bandwidth control 221
About bandwidth control 222
Configuring bandwidth controls 223
About downspeeding 223
About subzones 224
About the Traversal Subzone 224
Configuring the Default Subzone 225
Configuring subzones 225
Configuring subzone membership rules 226
Applying bandwidth limitations to subzones 228
Links and pipes 230
Configuring links 230
Default links 230
Configuring pipes 231
Applying pipes to links 232
Bandwidth control examples 233
Applications 235
Configuring Conference Factory 236
Presence 238
Presence Server 238
Presence User Agent (PUA) 239
Configuring Presence 240
B2BUA (back-to-back user agent) overview 243
Configuring B2BUA TURN servers 243
Microsoft Lync B2BUA 244
FindMe™ 251
End-user FindMe account configuration 251
How are devices specified? 251
FindMe process overview 252
Recommendations when deploying FindMe 252
Configuring FindMe 252
Cisco TMS provisioning 255
VCS Provisioning Server 256
Starter Pack provisioning 258
Configuring Starter Pack provisioning 258
User accounts 259
About user accounts 260
Account authentication 260
Account types 260
Configuring password security 262
Configuring administrator accounts 263
Viewing active administrator sessions 264
Login history 264
Configuring remote account authentication using LDAP 265
Checking the LDAP server connection status 267
Configuring administrator groups 268
Configuring FindMe groups 270
Cisco VCS Administrator Guide (X8.1.1) Page 6of 507
Page 7
Configuring FindMe accounts 271
Configuring a FindMe account's principal devices 273
Active FindMe sessions 273
Resetting forgotten passwords 274
Resetting your root or admin password via a serial connection 274
Resetting FindMe account passwords 274
Using the root account 275
Changing the root account password 275
Accessing the root account over SSH 275
Maintenance 276
Enabling maintenance mode 277
About upgrading software components 278
Upgrading VCS software 279
Upgrading using secure copy (SCP/PSCP) 280
Configuring logging 281
Event Log levels 281
Remote logging of events 281
Managing option keys 283
About security certificates 285
Managing the trusted CA certificate list 285
Managing the VCS's server certificate 286
Managing certificate revocation lists (CRLs) 288
Configuring certificate-based authentication 290
Testing client certificates 292
Advanced security 295
Configuring advanced account security mode 295
Configuring FIPS140-2 cryptographic mode 296
Configuring language settings 299
Changing the language 299
Installing language packs 299
Removing language packs 300
Backing up and restoring VCS data 301
When to create a backup 301
Content of the backup file 301
Limitations 301
Creating a system backup 301
Restoring a previous backup 302
Diagnostics tools 303
Configuring diagnostic logging 303
Creating a system snapshot 304
Configuring Network Log levels 304
Configuring Support Log levels 305
Incident reporting 306
Incident reporting caution: privacy-protected personal data 306
Enabling automatic incident reporting 306
Sending incident reports manually 307
Viewing incident reports 307
Incident report details 308
Checking the effect of a pattern 309
Locating an alias 310
Port usage 311
Cisco VCS Administrator Guide (X8.1.1) Page 7of 507
Page 8
Local inbound ports 311
Local outbound ports 311
Remote listening ports 312
Network utilities 313
Ping 313
Traceroute 313
Tracepath 314
DNS lookup 314
Restarting, rebooting and shutting down 317
Developer resources 319
Debugging and system administration tools 319
Experimental menu 319
Overview and status information 320
Status overview 321
System information 323
Ethernet status 324
IP status 325
Resource usage 326
Registration status 328
Call status 330
Disconnecting calls 331
B2BUA calls 332
Viewing B2BUA call media details 332
Search history 333
Search details 334
Local Zone status 335
Zone status 336
Bandwidth 337
Link status 337
Pipe status 337
Policy server status and resiliency 338
Viewing policy server status via the VCS 338
TURN relays status 339
Unified Communications status 340
Presence 341
Presence publishers 341
Presence presentities 341
Presence subscribers 342
Lync B2BUA 343
Lync user status 343
Lync B2BUA status 343
TMS Provisioning Extension service status 344
Provisioning Server device requests status (Cisco TMSPE) 344
User records provided by Cisco TMSPE services 345
FindMe records provided by Cisco TMSPE services 346
Phone book records provided by Cisco TMSPE services 346
Provisioned devices 347
Checking provisioned data 347
Starter Pack Provisioning Server status 348
Managing alarms 349
Logs 350
Cisco VCS Administrator Guide (X8.1.1) Page 8of 507
Page 9
Event Log 350
Configuration Log 351
Network Log 352
Hardware status 354
VCS unit front panel 354
Reference material 355
Performance capabilities 356
About Event Log levels 357
Event Log format 357
Administrator and FindMe user events 358
Message details field 358
Events and levels 360
CPL reference 366
CPL address-switch node 366
otherwise 368
not-present 368
location 368
rule-switch 369
proxy 370
reject 370
Unsupported CPL elements 370
CPL examples 371
LDAP server configuration for device authentication 377
Downloading the H.350 schemas 377
Configuring a Microsoft Active Directory LDAP server 377
Configuring an OpenLDAP server 379
DNS configuration examples 383
Verifying the SRV record 383
Microsoft DNS server 383
BIND 8 & 9 383
Changing the default SSH key 385
Restoring default configuration (factory reset) 386
Prerequisite files 386
Performing a reset to default configuration 386
Resetting via USB stick 386
Password encryption 388
Pattern matching variables 389
Port reference 391
Local VCS inbound/outbound ports 391
Remote listening ports 393
Unified Communications port reference 395
Microsoft Lync B2BUA port reference 397
Device authentication port reference 399
H.350 directory service 399
Active Directory (direct) 399
Regular expressions 400
Supported characters 402
Call types and licensing 403
Call types 403
What are traversal calls? 403
Alarms 405
Cisco VCS Administrator Guide (X8.1.1) Page 9of 507
Page 10
Command reference — xConfiguration 422
Command reference — xCommand 469
Command reference — xStatus 488
External policy overview 490
Using an external policy server 490
External policy request parameters 491
Default CPL for policy services 492
Flash status word reference table 493
Supported RFCs 494
Software version history 496
X7.2.1 496
X7.2 496
X7.1 499
X7 500
Related documentation 503
Legal notices 505
Intellectual property rights 505
Copyright notice 505
Patent information 506
Cisco VCS Administrator Guide (X8.1.1) Page 10of 507
Page 11
Introduction
This section provides an overview of the Cisco TelePresence Video Communication Server.
About the Cisco TelePresence Video Communication Server (VCS) 12
About this guide 17
What’s new in this version? 22
Cisco VCS Administrator Guide (X8.1.1) Page 11of 507
Page 12
Introduction
About the Cisco TelePresence Video Communication Server (VCS)
About the Cisco TelePresence Video
Communication Server (VCS)
The Cisco TelePresence Video Communication Server (VCS) software simplifies session management and
control of telepresence conferences. It provides flexible and extensible conferencing applications, enabling
organizations to benefit from increased employee productivity and enhanced communication with partners
and customers.
The VCS delivers exceptional scalability and resiliency, secure communications, and simplified large-scale
provisioning and network administration in conjunction with Cisco TelePresence Management Suite (Cisco
TMS).
The VCS interworks transparently with Cisco Unified Communications Manager (Unified CM), bringing rich
telepresence services to organizations with Unified CM. It also offers interoperability with third-party unified
communications, IP telephony networks, and voice-over-IP (VoIP) systems.
The VCS supports on-premises and cloud applications and is available as a dedicated appliance or as a
virtualized application on VMware, with additional support for Cisco Unified Computing System (Cisco UCS)
platforms.
You can deploy the VCS as the VCS Control for use within an enterprise and as the VCS Expressway for
business-to-business and remote and mobile worker external communication. An alternative solution, suited
to small to medium-sized businesses (SMBs), is the VCS Starter Pack Express.
Optional packages that you can deploy include FindMe, Device Provisioning, and Advanced Networking
(VCS Expressway only).
Cisco VCS Administrator Guide (X8.1.1) Page 12of 507
Page 13
Introduction
About the Cisco TelePresence Video Communication Server (VCS)
VCS base applications
The VCS is available with alternative base applications as described below.
VCS Control
VCS Control delivers any-to-any enterprise wide conference and session management and interworking
capabilities. It extends the reach of telepresence conferences by enabling interworking between Session
Initiation Protocol (SIP)- and H.323-compliant endpoints, interworking with third-party endpoints; it integrates
with Unified CM and supports third-party IP private branch exchange (IP PBX) solutions. VCS Control
implements the tools required for creative session management, including definition of aspects such as
routing, dial plans, and bandwidth usage, while allowing organizations to define call-management
applications, customized to their requirements.
VCS Expressway
The VCS Expressway deployed with the VCS Control enables smooth video communications easily and
securely outside the enterprise. It enables business-to-business video collaboration, improves the
productivity of remote and home-based workers, and enables service providers to provide video
communications to customers. The application performs securely through standards-based and secure
firewall traversal for all SIP and H.323 devices. As a result, organizations benefit from increased employee
productivity and enhanced communication with partners and customers.
It uses an intelligent framework that allows endpoints behind firewalls to discover paths through which they
can pass media, verify peer-to-peer connectivity through each of these paths, and then select the optimum
media connection path, eliminating the need to reconfigure enterprise firewalls.
The VCS Expressway is built for high reliability and scalability, supporting multivendor firewalls, and it can
traverse any number of firewalls regardless of SIP or H.323 protocol.
Standard features
The primary purpose of the VCS is to provides secure firewall traversal and session-based access to Cisco
Unified Communications Manager for remote workers, without the need for a separate VPN client.
The VCS has the following standard features:
n Provides secure firewall traversal and session-based access to Cisco Unified Communications Manager
for remote workers, without the need for a separate VPN client
n 2500 endpoint registrations on a standard appliance and 5000 registrations on Large VM server
deployments
n SIP Proxy/Registrar
n SIP Presence Server
n SIP Presence User Agent
n SIP and H.323 support, including SIP / H.323 interworking
n IPv4 and IPv6 support, including IPv4 / IPv6 interworking
n H.323 gatekeeper
n QoS tagging
Cisco VCS Administrator Guide (X8.1.1) Page 13of 507
Page 14
Introduction
About the Cisco TelePresence Video Communication Server (VCS)
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 on a standard appliance and 500 traversal calls on Large VM server deployments
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 other VCSs, 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 (including AD authentication for Jabber Video clients)
n Control over which endpoints are allowed to register
n Call Policy (also known as Administrator Policy) including support for CPL
n Support for external policy servers
n Can be managed with Cisco TelePresence Management Suite (Cisco TMS) 13.2 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 Nortel Communication Server neighbor zones
n Embedded setup wizard using a serial port for initial configuration
n System administration using a web interface or RS-232, SSH, and HTTPS
n Intrusion protection
Optional features
Some VCS features are available by the purchase and installation of the appropriate option key:
FindMe™
FindMe is 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 Lync 2010/2013, which
enables FindMe aliases to register as Lync clients, and for Lync clients to view the presence status of
FindMe aliases.
Cisco VCS Administrator Guide (X8.1.1) Page 14of 507
Page 15
Introduction
About the Cisco TelePresence Video Communication Server (VCS)
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 Jabber Video, E20, and
the EX and MX Series can request to be provisioned.) All configuration and phone book information is
managed in Cisco TMS. The data is then transferred to the VCS, from where it is distributed to endpoint
clients through the Provisioning Server running on the VCS.
See TMS provisioning and Cisco TMS Provisioning Extension Deployment Guide for more information about
how to configure provisioning.
SIP to Microsoft Lync 2010 / 2013 gatewaying
The Microsoft Lync back-to-back user agent (Lync B2BUA) on the VCS can be used to route SIP calls
between the VCS and a Microsoft Lync Server. It provides interworking between Microsoft ICE (used by
Lync clients) and media for communications with standard video endpoints.
The Microsoft Interoperability option key is required for all types of communication with Lync 2013.
Advanced Networking
The Advanced Networking option 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 the
VCS Expressway is located behind a static NAT device, allowing it to have separate public and private IP
addresses.
This configuration is intended for deployments where the VCS Expressway is located in a DMZ between two
separate firewalls on separate network segments.
Cisco VCS Administrator Guide (X8.1.1) Page 15of 507
Page 16
Introduction
About the Cisco TelePresence Video Communication Server (VCS)
Virtual appliance support
The VCS can run on VMware on a range of Cisco UCS servers. See VCS on Virtual Machine Installation
Guide for more information.
Installation and initial configuration
Full installation and initial configuration instructions for the VCS are contained in VCS Getting Started Guide.
Cisco VCS Administrator Guide (X8.1.1) Page 16of 507
Page 17
Introduction
About this guide
About this guide
This guide has been divided into several sections, providing conceptual, configuration and reference
information about the various features and capabilities of the VCS. It describes a fully equipped version of the
VCS. Your version may not have all the described extensions installed.
Most configuration tasks on the VCS can be performed by using either the 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 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:
xConfiguration <Element> <SubElement>
xCommand <Command>
Related documentation
See Related documentation [p.503] for a full list of documents and web sites referenced in this guide.
Training
Training is available online and at our training locations. For more information on all the training we provide
and where our training offices are located, visit www.cisco.com/go/telepresencetraining.
Glossary
A glossary of TelePresence terms is available at: https://tp-tools-web01.cisco.com/start/glossary/.
Accessibility notice
Cisco is committed to designing and delivering accessible products and technologies.
The Voluntary Product Accessibility Template (VPAT) for Cisco TelePresence Video Communication Server
is available here:
http://www.cisco.com/web/about/responsibility/accessibility/legal_regulatory/vpats.html#telepresence
You can find more information about accessibility here:
http://www.cisco.com/web/about/responsibility/accessibility/index.html
Cisco VCS Administrator Guide (X8.1.1) Page 17of 507
Page 18
Introduction
About this guide
Using the web interface
System configuration 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.
(This step only applies if you are using "standalone FindMe" i.e. FindMe without Cisco TMSPE.)
3. Enter a valid administrator Username and Password and click Login (see the user accounts section for
details on setting up administrator accounts). 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 .
Supported browsers
The VCS web interface is designed for use with Internet Explorer 8 or 9 (not in compatibility mode), Firefox 3
or later, or Chrome. Later versions of Internet Explorer may also work, but are not officially supported. 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 (X8.1.1) Page 18of 507
Page 19
Introduction
About this guide
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. These settings are controlled on the
System administration page.
To use the CLI:
1. Start an SSH 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 [p.488] 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 [p.422] 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 [p.469] 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 (X8.1.1) Page 19of 507
Page 20
Introduction
Web page features and layout
This section describes the features that can be found on the VCS web interface pages.
Figure 1: Example list page
Figure 2: Example configuration page
About this guide
The elements included in the example web pages shown here are described in the table below.
Page
element
Page name
and location
System
alarm
Help This icon appears on the top right corner of every page. Clicking on this icon opens a new
Log out This icon appears on the top right corner of every page. Clicking on this icon ends your
Cisco VCS Administrator Guide (X8.1.1) Page 20of 507
Description
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.
This icon appears on the top right corner of every page when there is a system alarm in
place. Click on this icon to go to the Alarms page which gives information about the alarm
and its suggested resolution.
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.
administrator session.
Page 21
Introduction
About this guide
Page
element
Field level
information
Information
bar
Sorting
columns
Select All
and
Unselect All
Mandatory
field
Peer-specific
configuration
item
System
Information
Description
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.
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.
Click on column headings to sort the information in ascending and descending order.
Use these buttons to select and unselect all items in the list.
Indicates an input field that must be completed.
† When a VCS is part of a cluster, most items of configuration are applied to all peers in a
cluster. However, items indicated with a † must be specified separately on each cluster
peer.
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, 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 (X8.1.1) Page 21of 507
Page 22
Introduction
What’s new in this version?
What’s new in this version?
The new features introduced in this release of VCS software are described below.
X8.1.1
Unified Communications: mobile and remote access
Cisco Unified Communications mobile and remote access is a core part of the Cisco Collaboration Edge
Architecture. It allows endpoints such as Cisco Jabber to have their registration, call control, provisioning,
messaging and presence services provided by Cisco Unified Communications Manager (Unified CM) when
the endpoint is not within the enterprise network. The VCS provides secure firewall traversal and line-side
support for Unified CM registrations.
For more information including configuration recommendations and troubleshooting details, see Unified
Communications: Mobile and Remote Access via VCS Deployment Guide.
Support to modify Maximum transmission unit (MTU) size
You can configure the maximum transmission unit (MTU) for each network interface on the System > IP
page.
Changed functionality
The tcpdump facility has been removed from the Diagnostic logging tool.
Jabber Guest
Jabber Guest support has been removed (it was previously provided as a feature preview in X8.1). It will be
reintroduced in a future release of VCS software.
X8.1
Microsoft Lync 2013 / H.264 SVC support
The Microsoft Lync B2BUA now supports calls to and from Microsoft Lync 2013 clients. It provides
interworking between standard H.264 AVC and Lync 2013's H.264UC SVC codec. To use Lync 2013 you
must install the Microsoft Interoperability option key (formerly known as the Enhanced OCS
Collaboration option key). Note that for Lync 2010, the Microsoft Interoperability option key requirements
remain as per previous releases (i.e. it is required for encrypted calls to and from Microsoft Lync Server and
for establishing ICE calls to Lync clients).
Presentation sharing via Lync 2013 is supported but only from VCS to Lync.
Support for standards-based H.264 SVC codecs
The B2BUA now supports calls to standards-based H.264 SVC codecs.
Improved performance and scalability
n VCS X8.1 software can take advantage of the improved performance and scalability capabilities that are
available when running on Large VM server deployments. It can support up to 500 traversal calls, 750 nontraversal calls and 5000 registrations. Note that standard VCS appliances or equivalent VM hardware still
provides support for up to 150 traversal calls, 750 non-traversal calls and 2500 registrations.
n The number of concurrent searches has increased from 100 to 500.
Cisco VCS Administrator Guide (X8.1.1) Page 22of 507
Page 23
Introduction
What’s new in this version?
New traversal media port framework
n For new installations of X8.1 or later, the default range for traversal media ports is 36000 – 59999. The
previous default range of 50000 - 54999 still applies to earlier releases that have upgraded to X8.1. The
larger range is required to support the improved scalability features.
n The media demultiplexing ports on the VCS Expressway now use the first set of ports from the general
range of traversal media ports instead of 2776 and 2777.
l On existing systems that have been upgraded to X8.1, this will be 50000 and 50001 by default.
l On new installations of X8.1, this will be 36000 and 36001 by default.
l On large VM deployments, the first 12 ports in the traversal media port range are used (50000 - 50011 or
36000 - 36011 as appropriate).
This applies to all RTP/RTCP media, regardless of whether it is H.323 or SIP. Thus, the previously used
Media demultiplexing RTP port and RTCP port settings (Configuration > Traversal > Ports) and
associated xConfiguration Traversal Server CLI commands have been removed.
Administrators will need to adjust their firewall settings accordingly.
New TURN server port framework
On Large VM server deployments you can configure a range of TURN request listening ports. The default
range is 3478 – 3483.
For new installations of X8.1 or later, the default range for TURN relay media ports is 24000 – 29999. The
previous default range of 60000 – 61799 still applies to earlier releases that have upgraded to X8.1.
Delegated credential checking for device authentication (SIP only)
By default, the VCS uses the relevant credential checking mechanisms (local database, Active Directory
Service or H.350 directory via LDAP) on the VCS performing the authentication challenge.
Alternatively you can now configure the VCS so that the credential checking of SIP messages is delegated,
via a traversal zone, to another VCS. Delegated credential checking is useful in deployments where you
want to allow devices to register on a VCS Expressway, but for security you want all communications with
authentication systems (such as an Active Directory server) to be performed inside the enterprise.
Credential checking for both Digest and NTLM messages may be delegated.
Automated protection
An automated intrusion protection feature has been added. It can be used to detect and block malicious
traffic and to help protect the VCS from dictionary-based attempts to breach login security.
It works by parsing the system's log files to look for repeated failures to access specific service categories,
such as SIP, SSH and web/HTTPS access. When the number of failures within a specified time window
reaches the configured threshold, the source host address (the intruder) is blocked for a period of time. You
can configure sets of addresses that are exempted always from one or more categories.
Automated protection should be used in combination with the existing firewall rules feature - use automated
protection to temporarily block specific threats and use firewall rules to block permanently a range of known
host addresses.
Licensing of audio-only SIP traversal calls
Audio-only SIP traversal calls are now treated distinctly from video SIP traversal calls. Each traversal call
license allows either 1 video call or 2 audio-only SIP calls. Hence, a 100 traversal call license would allow, for
example, 90 video and 20 SIP audio-only simultaneous calls. Any other audio-only call (non-traversal, H.323
or interworked) will consume a standard video call license (traversal or non-traversal as appropriate).
Cisco VCS Administrator Guide (X8.1.1) Page 23of 507
Page 24
Introduction
What’s new in this version?
The Overview and Resource usage pages show separate counts for video and audio-only SIP traversal
calls.
Note that:
n VCS defines an "audio-only" SIP call as one that was negotiated with a single “m=” line in the SDP. Thus,
for example, if a person makes a “telephone” call but the SIP UA includes an additional m= line in the SDP,
the call will consume a video call license.
n While an "audio-only" SIP call is being established, it is treated (licensed) as a video call. It only becomes
licensed as "audio-only" when the call setup has completed. This means that if your system approaches its
maximum licensed limit, you may be unable to connect some "audio-only" calls if they are made
simultaneously.
TMS Agent functionality removed
TMS Agent (legacy mode) functionality has been removed. Instead, if you use TMS provisioning, you must
use TMS Provisioning Extension services.
Java application removed
The Java application has been removed. This removes the threat of Java security vulnerabilities.
OCS Relay functionality and Microsoft OCS 2007 zone profile removed
OCS Relay functionality and the Microsoft Office Communications Server 2007 zone profile have been
removed. The Cisco AM GW configuration options previously under the VCS configuration menu, and the
Cisco Advanced Media Gateway zone profile have also been removed.
Instead, we recommend that you use the Microsoft Lync B2BUA to route SIP calls between the VCS and a
Microsoft Lync Server, and to configure your Cisco AM GWs as B2BUA transcoders. Note that B2BUA
connections to Microsoft OCS are no longer supported from X8.1.
Support for Active Control
VCS supports Active Control (iX Channel passthrough) as supported by Cisco TelePresence Server 3.1 or
later and endpoints running TC6.2 or later. It can be configured on a per-zone basis.
FIPS140-2 cryptographic mode
VCS has implemented FIPS140-2 compliant features.
New VMware installations
New VMware installations have a choice of 3 .ova files: Small (for Cisco Business Edition 6000
deployments), Medium (for typical deployments) or Large (for large-scale deployments). Note that the VM
.ova files are used for new installations only. Do not use them to upgrade your existing VM installation.
See VCS on Virtual Machine Installation Guide for information about deploying on UCS tested reference
configurations and their associated memory and CPU resource reservation requirements.
ICE messaging support
ICE messaging support is now configurable at the zone and subzone level.
Certificate management
The certificate management pages are now located under Maintenance > Security certificates:
n The management of CA certificates has been improved, allowing you to view, upload and delete individual
CA certificates.
Cisco VCS Administrator Guide (X8.1.1) Page 24of 507
Page 25
Introduction
What’s new in this version?
n The VCS's server and trusted CA certificates can be viewed in either a human-readable, decoded format,
or in their raw, PEM format.
Other enhancements and usability improvements
n The online help has a new skin and an improved search capability.
n There is a new Cisco Unified Communications Manager (8.6.1 or later) zone profile. This profile supports
BFCP and should be used in SIP trunk neighbor zones to Unified CM running version 8.6.1 or later.
n The ephemeral port range can be configured via the web interface (System > Administration).
n Maintenance mode can be configured via the web interface (Maintenance > Maintenance mode).
n The Microsoft Lync B2BUA supports multiple TURN servers.
n The Lync B2BUA status page now shows the number of active calls, and resource usage as a percentage
of the number of allowed Lync B2BUA calls.
n A B2BUA service restart is no longer required to enable changes to the list of trusted hosts to take effect.
n A contact email address and a proxy server can be specified when configuring the incident reporting server.
n The DNS cache is flushed automatically whenever any DNS configuration is changed (System > DNS).
The DNS page also contains a manual option to flush the DNS cache.
n When logging in, you now have to choose the administrator login option only if you are using "standalone
FindMe" i.e. FindMe without Cisco TMSPE.
n CPL location node supports regex-based source alias rewriting.
n Active Directory Service configuration: you can specify an override value for the NetBIOS machine name if
the System host name, which is used as the default name, exceeds 15 characters.
n Previously-installed language packs can be deleted.
n The VCS Starter Pack Express supports device provisioning for SX20 endpoints. Note: this is a preview
feature.
n You have the option to take a tcpdump while diagnostic logging is in progress.
n SIP network logging at the DEBUG level now includes the local address and port (as well as the
destination/source information).
n You can specify the transport type to use for SIP calls from a DNS zone, when DNS NAPTR records and
SIP URI parameters do not provide the preferred transport information.
n The VCS supports time-limited option keys. The options keys page displays the validity period of each key.
All pre-existing option keys have an Unlimited validity period.
n Filtering options are only displayed on status and list pages if there is more than one page of information to
display. Status and list pages show 200 records per page, except for Log pages which show 1000 records
per page.
n When configuring firewall rules:
l You can choose whether to drop or reject denied traffic. Note that on upgrade to X8.1, any existing
"deny" rules will now drop the traffic; prior to X8.1 the traffic would have been rejected.
l If you have made several changes there is now an option to revert all changes. This discards all pending
changes and resets the working copy of the rules to match the current active rules.
l You can more easily change the order of the rules by using up/down arrow buttons to swap the priorities
of adjacent rules.
l Rules can be configured for XMPP traffic.
n The Search rules page now indicates if the target zone of a rule is unavailable.
n Port conflict alarms now indicate the exact features and ports that are in conflict.
n When performing a system backup, the backup filename is now prefixed by the software version number.
Cisco VCS Administrator Guide (X8.1.1) Page 25of 507
Page 26
Introduction
What’s new in this version?
n The application now uses CiscoSSL (instead of OpenSSL).
n The xConfiguration and xCommand CLI command sets removed in version X7.2 have been reinstated.
n When using CPL to modify the source URL of a From header, any corresponding display name is also
modified to match the username part of the modified source URL.
n Improved web interface usability when switching between SRV and address record resolution modes when
configuring the address of an LDAP server for remote user account authentication.
Changed functionality
n For new installations of X8.1 or later, the default range for ephemeral ports is 30000 – 35999. Prior to
X8.1, the default range was 40000 – 49999. Existing systems upgraded to X8.1 or later will preserve their
previous port ranges.
n The Dual Network Interfaces option key is now called Advanced Networking. When the key is installed
you can now configure the use of dual network interfaces separately from the use of static NAT.
n Most system configuration items are now peer-specific (they are not replicated across peers when the VCS
is part of a cluster). See Specifying peer-specific items in clustered systems [p.164] for more information.
n New installations of VCS software now ship with a temporary trusted CA, and a server certificate issued
by that temporary CA. We strongly recommend that you replace the server certificate with one generated
by a trusted certificate authority, and that you install CA certificates for the authorities that you trust. If you
upgrade to this release from an earlier installation of VCS software, your existing server and trusted CA
certificates will not be affected.
n When configuring the sources for administrator account authentication, the Remote option is now labeled
as Remote only.
This also means you can no longer access the VCS via the default admin account if a Remote only
authentication source is in use. The Local option has also been renamed to Local only. Note: do not use
Remote only if VCS is managed by Cisco TMS.
n The Reboot, Restart and Shutdown maintenance options have been combined into one Restart options
page.
n When starting a diagnostic log, the relevant system modules now have their log levels automatically set to
"debug" and are automatically reset to their original values when logging is stopped.
n You can no longer access the system over Telnet.
n The Expressway option key is now called Traversal Server.
n The DNS Local host name is now referred to as the System host name.
n Auditor access level now includes the Alarms page.
n The login account configuration pages are now accessed under a new top-level Users menu (previously
under Maintenance > Login accounts).
n The Clustering page is now accessed under the System menu.
n The System administration page is now accessed under System > Administration.
n The Firewall rules configuration pages are now accessed under System > Protection.
n The VCS configuration menu is now called just Configuration.
n The SIP page is now accessed directly via Configuration > Protocols > SIP and the Domains page is
now accessed via Configuration > Domains.
n The Calls page and menu is now called Call routing. Call routed mode is now called Call signaling
optimization and the options are On and Off.
n On the VCS Expressway, the VCS configuration > Expressway menu is now Configuration >
Traversal.
Cisco VCS Administrator Guide (X8.1.1) Page 26of 507
Page 27
Introduction
What’s new in this version?
n All references to OCS/Lync B2BUA have been renamed to refer to Lync B2BUA. The Enhanced OCS
Collaboration option key is now called Microsoft Interoperability.
n References to 'Movi' have been changed to 'Jabber Video'.
n The FindMe configuration page is now accessed directly under Applications > FindMe.
n On the Upgrade page, the VCS platform component is now referred to as System platform.
n The Advanced account security page is now called Advanced security and is accessed via
Maintenance > Advanced security.
n The Local VCS inbound ports page is now called Local inbound ports, and the Local VCS outbound
ports page is now called Local outbound ports.
n The advanced zone configuration Empty INVITE allowed setting is now referred to as Send empty
INVITE for interworked calls.
n The following settings have been removed from the SIP configuration page: Require UDP BFCP mode
and Require Duo Video mode. They existed to provide support for interoperability issues with old
versions of Cisco TelePresence MXP endpoints. These settings can still be configured via the CLI if
necessary.
n The Login account authentication configuration page has been removed, and the Administrator
authentication source and FindMe authentication source settings are now on the Login account
LDAP configuration page.
n The xConfiguration Interworking Require Invite Header Mode is now Off by default.
n The Directory option has been removed from the list of restriction policies on the Registration
configuration page and the list of Call Policy modes on the Call Policy configuration page.
n The DNS lookup tool includes Unified Communications SRV services.
Cisco VCS Administrator Guide (X8.1.1) Page 27of 507
Page 28
Network and system settings
This section describes network services and settings related 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, firewall rules, intrusion protection and the external services used by the
VCS (for example DNS, NTP and SNMP).
Network settings 29
Intrusion protection 34
Network services 40
Configuring external manager settings 48
Configuring TMS Provisioning Extension services 49
Cisco VCS Administrator Guide (X8.1.1) Page 28of 507
Page 29
Network and system settings
Network settings
Network settings
Configuring IP settings
The IP page (System > IP) is used to configure the IP protocols and network interface 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.
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.
All IPv6 addresses configured on the VCS are treated as having a /64 network prefix length.
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.
IP gateways 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.
n The default IPv4 gateway is 127.0.0.1, which should be changed during the commissioning process.
n The IPv6 gateway, if entered, must be a static global IPv6 address. It cannot be a link-local or a stateless
auto-configuration (SLAAC) IPv6 address.
You can also configure additional IP routing information (static routes) on the VCS. This is sometimes
required when using the Advanced Networking option and deploying the VCS in a DMZ. They may also be
required occasionally in other complex network deployments.
n IP routes can be configured using the CLI only: routes can be added by using the xCommand RouteAdd
command and can be modified by using the xConfiguration IP Route commands.
n You can configure routes for up to 50 network and host combinations.
n Do not configure IP routes by logging into the system as root and using "ip route" statements.
Cisco VCS Administrator Guide (X8.1.1) Page 29of 507
Page 30
Network and system settings
Network settings
LAN configuration
LAN 1 is the primary network port on the VCS. You can configure the IPv4 address and subnet mask, the
IPv6 address and the Maximum transmission unit (MTU) for this port.
n 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.
n The IPv6 address, if entered, must be a static global IPv6 address. It cannot be a link-local or a stateless
auto-configuration (SLAAC) IPv6 address.
n If you have Advanced Networking installed, you can also configure these options for the LAN 2 port.
n The Maximum transmission unit (MTU) defaults to 1500 bytes.
About Advanced Networking
The Advanced Networking option key enables the LAN 2 port on a VCS for both management and call
signaling. This allows you to have a second IP address for your VCS. The option key also enables static
NAT functionality on a VCS Expressway.
Configuring dual network interfaces
Dual network interfaces are intended for deployments where the VCS Expressway 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 Expressway.
To enable the use of dual network interfaces:
1. Ensure that the Advanced Networking option key is installed on the VCS Expressway.
2. Set Use dual network interfaces to Yes.
3. Set External LAN interface to LAN2.
LAN 2 should be used as the public interface of the VCS Expressway (if the VCS Expressway is ever
clustered, LAN 1 must be used for clustering, and the clustering interface must not be mapped through a
NAT).
This setting also determines the port from which TURN server relay allocations are made.
Note that:
n You should configure the LAN 1 port and restart the VCS before configuring the LAN 2 port.
n The LAN 1 and LAN 2 interfaces must be on different, non-overlapping subnets.
n If you have Advanced Networking enabled but only want to configure one of the Ethernet ports, you must
use LAN 1.
n If the VCS Expressway is in the DMZ, the outside IP address of the VCS Expressway must be a public IP
address, or if static NAT mode is enabled, the static NAT address must be publicly accessible.
n The VCS Expressway may also be used to traverse internal firewalls within an enterprise. In this case the
"public" IP address may not be publicly accessible, but is an IP address accessible to other parts of the
enterprise.
Cisco VCS Administrator Guide (X8.1.1) Page 30of 507
Page 31
Network and system settings
Network settings
Configuring static NAT
You can deploy the 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 Advanced Networking 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, traversal clients should be configured to use the internally-facing IP address of the
VCS Expressway.
To enable the use of a static NAT:
1. Ensure that the Advanced Networking 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. Set IPv4 static NAT mode to 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.
Static NAT restrictions when using SIP media encryption
You should not configure a VCS for SIP media encryption if that same VCS is also configured for static NAT.
If you do so, the private IP address will be sent in the SDP rather than the static NAT address and this will
cause calls to fail.
Note that the recommended configuration for VCS Control with VCS Expressway deployments is to:
n configure the same media encryption policy setting on the traversal client zone on VCS Control, the
traversal server zone on VCS Expressway, and every zone and subzone on VCS Expressway
n use static NAT on the VCS Expressway only
With this configuration the encryption B2BUA will be enabled on the VCS Control only.
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 Advanced Networking 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: we recommend that you 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.
Cisco VCS Administrator Guide (X8.1.1) Page 31of 507
Page 32
Network and system settings
Network settings
Configuring DNS settings
The DNS page (System > DNS) is used to configure the VCS's DNS servers and DNS settings.
Configuring the system host and domain name
The System 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 used if the
System host name is not specified).
The Domain name is used when attempting to resolve unqualified server addresses (for example
ldapserver). 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 ldapserver.mydomain.com) 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.
Note that the FQDN of the VCS is the System host name plus the Domain name.
Impact on SIP messaging
The System 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 System 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.)
DNS requests
By default, DNS requests use a random port from within the system's ephemeral port range.
If required, you can specify a custom port range instead by setting DNS requests port range to Use a
custom port range and then defining the DNS requests port range start and DNS requests port range
end fields. Note that setting a small source port range will increase your vulnerability to DNS spoofing
attacks.
Configuring DNS server addresses
You must specify at least one DNS server to be queried for address resolution if you want to:
Cisco VCS Administrator Guide (X8.1.1) Page 32of 507
Page 33
Network and system settings
Network settings
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).
n Use features such as URI dialing or ENUM dialing.
Default DNS servers
You can specify up to 5 default DNS servers.
n The VCS only queries one server at a time; if that server is not available the VCS will try another server
from the list.
n The order that the servers are specified is not significant; the VCS attempts to favor servers that were last
known to be available.
Per-domain DNS servers
In addition to the 5 default DNS servers, you can specify 5 additional explicit DNS servers for specified
domains. This can be useful in deployments where specific domain hierarchies need to be routed to their
explicit authorities.
For each additional per-domain DNS server address you can specify up to 2 Domain names. Any DNS
queries under those domains are forwarded to the specified DNS server instead of the default DNS servers.
You can specify redundant per-domain servers by adding an additional per-domain DNS server address and
associating it with the same Domain names. In this scenario, DNS requests for those domains will be sent
in parallel to both DNS servers.
Tip: you can also use the DNS lookup tool (Maintenance > Tools > Network utilities > DNS lookup) to
check which domain name server (DNS server) is responding to a request for a particular hostname.
Caching DNS records
To improve performance, DNS lookups may be cached. This cache is flushed automatically whenever the
DNS configuration is changed.
You can also force the cache to be flushed by clicking Flush DNS cache.
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.
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.
Cisco VCS Administrator Guide (X8.1.1) Page 33of 507
Page 34
Network and system settings
Intrusion protection
Intrusion protection
Configuring firewall rules
Firewall rules provide the ability to configure IP table rules to control access to the VCS at the IP level. On
the VCS, these rules have been classified into groups and are applied in the following order:
n Dynamic system rules: these rules ensure that all established connections/sessions are maintained. They
also include any rules that have been inserted by the automated detection feature as it blocks specific
addresses. Finally, it includes a rule to allow access from the loopback interface.
n Non-configurable application rules: this incorporates all necessary application-specific rules, for example to
allow SNMP traffic and H.323 gatekeeper discovery.
n User-configurable rules: this incorporates all of the manually configured firewall rules (as described in this
section) that refine — and typically restrict — what can access the VCS. There is a final rule in this group
that allows all traffic destined for the VCS LAN1 interface (and the LAN 2 interface if the Advanced
Networking option key is installed).
There is also a final, non-configurable rule that drops any broadcast or multicast traffic that has not already
been specifically allowed or denied by the previous rules.
By default any traffic that is destined for the specific IP address of the VCS is allowed access, but that traffic
will be dropped if the VCS is not explicitly listening for it. You have to actively configure extra rules to lock
down the system to your specifications.
Note that return traffic from outbound connections is always accepted.
User-configured rules
The user-configured rules are typically used to restrict what can access the VCS. You can:
n Specify the source IP address subnet from which to allow or deny traffic.
n Choose whether to drop or reject denied traffic.
n Configure well known services such as SSH, HTTP/HTTPS or specify customized rules based on
transport protocols and port ranges.
n Configure different rules for the LAN 1 and LAN 2 interfaces (if the Advanced Networking option key is
installed), although note that you cannot configure specific destination addresses such as a multicast
address.
n Specify the priority order in which the rules are applied.
Setting up and activating firewall rules
The Firewall rules configuration page is used to set up and activate a new set of firewall rules.
The set of rules shown will initially be a copy of the current active rules. (On a system where no firewall rules
have previously been defined, the list will be empty.) If you have a lot of rules you can use the Filter options
to limit the set of rules displayed. Note that the built-in rules are not shown in this list.
You can then change the set of firewall rules by adding new rules, or by modifying or deleting any existing
rules. Any changes made at this stage to the current active rules are held in a pending state. When you have
completed making all the necessary changes you can activate the new rules, replacing the previous set.
Cisco VCS Administrator Guide (X8.1.1) Page 34of 507
Page 35
Network and system settings
Intrusion protection
To set up and activate new rules:
1. Go to System > Protection > Firewall rules > Configuration.
2. Make your changes by adding new rules, or by modifying or deleting any existing rules as required.
You can change the order of the rules by using the up/down arrows and to swap the priorities of
adjacent rules.
l New or modified rules are shown as Pending (in the State column).
l Deleted rules are shown as Pending delete.
3. When you have finished configuring the new set of firewall rules, click Activate firewall rules.
4. Confirm that you want to activate the new rules. This will replace the existing set of active rules with the
set you have just configured.
After confirming that you want to activate the new rules, they are validated and any errors reported.
5. If there are no errors, the new rules are temporarily activated and you are taken to the Firewall rules
confirmation page.
You now have 15 seconds to confirm that you want to keep the new rules:
l Click Accept changes to permanently apply the rules.
l If the 15 seconds time limit expires or you click Rollback changes, the previous rules are reinstated
and you are taken back to the configuration page.
The automatic rollback mechanism provided by the 15 seconds time limit ensures that the client system
that activated the changes is still able to access the system after the new rules have been applied. If the
client system is unable to confirm the changes (because it can no longer access the web interface) then
the rollback will ensure that its ability to access the system is reinstated.
When configuring firewall rules, you also have the option to Revert all changes. This discards all pending
changes and resets the working copy of the rules to match the current active rules.
Rule settings
The configurable options for each rule are:
Field Description Usage tips
Priority The order in which the
firewall rules are applied.
Interface The LAN interface on which
you want to control access.
IP address
and Prefix
length
Service Choose the service to which
These two fields together
determine the range of IP
addresses to which the rule
applies.
the rule applies, or choose
Custom to specify your own
transport type and port
ranges.
The rules with the highest priority (1, then 2, then 3 and so on) are
applied first.
Firewall rules must have unique priorities. Rule activation will fail if
there are multiple rules with the same priority.
This only applies if the Advanced Networking option key is installed.
The Address range field shows the range of IP addresses to which
the rule applies, based on the combination of the IP address and
Prefix length.
The prefix length range is 0-32 for an IPv4 address, and 0-128 for an
IPv6 address.
Note that if the destination port of a service is subsequently
reconfigured on the VCS, for example from 80 to 8080, any firewall
rules containing the old port number will not be automatically
updated.
Transport The transport protocol to
which the rule applies.
Cisco VCS Administrator Guide (X8.1.1) Page 35of 507
Only applies if specifying a Custom service.
Page 36
Network and system settings
Field Description Usage tips
Intrusion protection
Start and
end port
Action The action to take against
Description An optional free-form
The port range to which the
rule applies.
any IP traffic that matches
the rule.
Allow: Accept the traffic.
Drop: Drop the traffic
without any response to the
sender.
Reject: Reject the traffic
with an 'unreachable'
response.
description of the firewall
rule.
Only applies if specifying a UDP or TCP Custom service.
Dropping the traffic means that potential attackers are not provided
with information as to which device is filtering the packets or why.
For deployments in a secure environment, you may want to
configure a set of low priority rules (for example, priority 50000) that
deny access to all services and then configure higher priority rules
(for example, priority 20) that selectively allow access for specific IP
addresses.
If you have a lot of rules you can use the Filter by description options
to find related sets of rules.
Current active firewall rules
The Current active firewall rules page (System > Protection > Firewall rules > Current active rules)
shows the user-configured firewall rules that are currently in place on the system. Note that there is also a set
of built-in rules that are not shown in this list.
If you want to change the rules you must go to the Firewall rules configuration page from where you can
set up and activate a new set of rules.
Configuring automated intrusion protection
The automated protection service can be used to detect and block malicious traffic and to help protect the
VCS from dictionary-based attempts to breach login security.
It works by parsing the system log files to detect repeated failures to access specific service categories,
such as SIP, SSH and web/HTTPS access. When the number of failures within a specified time window
reaches the configured threshold, the source host address (the intruder) and destination port are blocked for a
specified period of time. The host address is automatically unblocked after that time period so as not to lock
out any genuine hosts that may have been temporarily misconfigured.
You can configure ranges of addresses that are exempted from one or more categories (see Configuring
exemptions [p.38] below).
Automated protection should be used in combination with the firewall rules feature - use automated protection
to dynamically detect and temporarily block specific threats, and use firewall rules to permanently block a
range of known host addresses.
About protection categories
The set of available protection categories on your VCS are pre-configured according to the software version
that is running. You can enable, disable or configure each category, but you cannot add additional categories.
The rules by which specific log file messages are associated with each category are also pre-configured and
cannot be altered. You can view example log file entries that would be treated as an access failure/intrusion
Cisco VCS Administrator Guide (X8.1.1) Page 36of 507
Page 37
Network and system settings
Intrusion protection
within a particular category by going to System > Protection > Automated detection > Configuration and
clicking on the name of the category. The examples are displayed above the Status section at the bottom of
the page.
Enabling automated protection
To enable intrusion protection on your VCS:
1. Go to System > Administration.
2. Set Automated protection service to On.
3. Click Save.
4. You must then ensure that the required protection categories are enabled and configured, and that any
required exemptions are specified, as described below.
All protection categories are disabled by default.
Configuring protection categories
The Automated detection overview page (System > Protection > Automated detection >
Configuration) is used to enable and configure the VCS's protection categories, and to view current activity.
The page displays a summary of all available categories, showing:
n Status: this indicates if the category is configured to be On or Off. When On, it additionally indicates the
state of the category: this is normally Active, but may temporarily display Initializing or Shutting down when
a category has just been enabled or disabled. Check the alarms if it displays Failed.)
n Currently blocked: the number of addresses currently being blocked for this category.
n Total failures: the total number of failed attempts to access the services associated with this category.
n Total blocks: the total number of times that a block has been triggered. Note that:
l The Total blocks will typically be less than the Total failures (unless the Trigger level is set to 1).
l The same address can be blocked and released several times per category, with each occurrence
counting as a separate block.
n Exemptions: the number of addresses that are configured as exempt from this category.
From this page, you can also view any currently blocked addresses or any exemptions that apply to a
particular category.
Enabling and disabling categories
To enable or disable one or more protection categories:
1. Go to System > Protection > Automated detection > Configuration.
2. Select the check box alongside the categories you want to enable or disable.
3. Click Enable or Disable as appropriate.
Configuring a category's blocking rules
To configure a category's specific blocking rules:
1. Go to System > Protection > Automated detection > Configuration.
2. Click on the name of the category you want to configure.
You are taken to the configuration page for that category.
Cisco VCS Administrator Guide (X8.1.1) Page 37of 507
Page 38
Network and system settings
Intrusion protection
3. Configure the category as required:
l State: whether protection for that category is enabled or disabled.
l Description: a free-form description of the category.
l Trigger level and Detection window: these settings combine to define the blocking threshold for the
category. They specify the number of failed access attempts that must occur before the block is
triggered, and the time window in which those failures must occur.
l Block duration: the period of time for which the block will remain in place.
4. Click Save.
Configuring exemptions
The Automated detection exemptions page (System > Protection > Automated detection >
Exemptions) is used to configure any IP addresses that are to be exempted always from one or more
protection categories.
To configure exempted addresses:
1. Go to System > Protection > Automated detection > Exemptions.
2. Click on the Address you want to configure, or click New to specify a new address.
3. Enter the Address and Prefix length to define the range of IPv4 addresses you want to exempt.
4. Select the categories from which the address is to be exempted.
5. Click Add address.
Note that if you exempt an address that is currently blocked, it will remain blocked until its block duration
expires (unless you unblock it manually via the Blocked addresses page).
Managing blocked addresses
The Blocked addresses page (System > Protection > Automated detection > Blocked addresses) is
used to manage the addresses that are currently blocked by the automated protection service:
n It shows all currently blocked addresses and from which categories those addresses have been blocked.
n You can unblock an address, or unblock an address and at the same time add it to the exemption list. Note
that if you want to permanently block an address, you must add it to the set of configured firewall rules.
If you access this page via the links on the Automated detection overview page it is filtered according to
your chosen category. It also shows the amount of time left before an address is unblocked from that
category.
Investigating access failures and intrusions
If you need to investigate specific access failures or intrusion attempts, you can review all the relevant
triggering log messages associated with each category. To do this:
1. Go to System > Protection > Automated detection > Configuration.
2. Click on the name of the category you want to investigate.
3. Click View all matching intrusion protection triggers for this category.
The system will display all the relevant events for that category. You can then search through the list of
triggering events for the relevant event details such as a user name, address or alias.
Cisco VCS Administrator Guide (X8.1.1) Page 38of 507
Page 39
Network and system settings
Intrusion protection
Automated protection service and clustered systems
When the automated protection service is enabled in a clustered system:
n Each peer maintains its own count of connection failures and the trigger threshold must be reached on each
peer for the intruder's address to be blocked by that peer.
n Addresses are blocked against only the peer on which the access failures occurred. This means that if an
address is blocked against one peer it may still be able to attempt to access another peer (from which it
may too become blocked).
n A blocked address can only be unblocked for the current peer. If an address is blocked by another peer, you
must log in to that peer and then unblock it.
n Category settings and the exemption list are applied across the cluster.
n The statistics displayed on the Automated detection overview page are for the current peer only.
Additional information
n When a host address is blocked and tries to access the system, the request is dropped (the host receives
no response).
n A host address can be blocked simultaneously for multiple categories, but may not necessarily be blocked
by all categories. Those blocks may also expire at different times.
n When an address is unblocked (either manually or after its block duration expires), it has to fail again for the
full number of times as specified by the category's trigger level before it will be blocked for a second time by
that category.
n IPv6 host addresses are not supported (the automated protection service currently detects IPv4 host
address failures only).
n A category is reset whenever it is enabled. All categories are reset if the system is restarted or if the
automated protection service is enabled at the system level. When a category is reset:
l Any currently blocked addresses are unblocked.
l Its running totals of failures and blocks are reset to zero.
n You can view all Event Log entries associated with the automated protection service by clicking View all
intrusion protection events on the Automated detection overview page.
Cisco VCS Administrator Guide (X8.1.1) Page 39of 507
Page 40
Network and system settings
Network services
Network services
Configuring system name and access settings
The System administration page (System > Administration) is used to configure the name of the VCS
and the means by which it is accessed by administrators.
System settings
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 Cisco TMS.
We recommend that you give the VCS a name that allows you to easily and uniquely identify it.
Ephemeral ports range
You can specify the Ephemeral port range start and end values. This defines the port range to use for
ephemeral outbound connections not otherwise constrained by VCS call processing.
The default range of 30000 – 35999 applies to new installations of X8.1 or later; the previous default range of
40000 – 49999 still applies to earlier releases that have upgraded to X8.1.
Administration access settings
While you can 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 the web interface (via HTTPS) or through a
command line interface (via SSH).
The configurable options are:
Field Description Usage tips
Services
Serial port /
console
SSH service Determines whether the VCS can be
Web interface
(over HTTPS)
Determines whether the system can
be accessed locally via either the
serial port (for a physical system) or
VMware console (for a virtual
machine). Default is On.
accessed via SSH and SCP. Default is
On.
Determines whether the VCS can be
accessed via the web interface.
Default is On.
Serial port / console access is always enabled for one
minute following a restart, even if it is normally
disabled.
Cisco TMS accesses the VCS via the web server. If
HTTPS mode is turned off, Cisco TMS will not be able to
access it.
Session limits
Cisco VCS Administrator Guide (X8.1.1) Page 40of 507
Page 41
Network and system settings
Field Description Usage tips
Network services
Session time
out
The number of minutes that an
administration session (serial port,
HTTPS or SSH) or a FindMe session
may be inactive before the session is
timed out. Default is 30 minutes.
Per-account
session limit
The number of concurrent sessions
that each individual administrator
account is allowed on each VCS.
System
session limit
The maximum number of concurrent
administrator sessions allowed on
each VCS.
System protection
Automated
protection
service
Determines whether the automated
protection service is active. Default is
Off.
Web server configuration
Redirect HTTP
requests to
HTTPS
Determines whether HTTP requests
are redirected to the HTTPS port.
Default is On.
A value of 0 means that session time outs are disabled.
This includes web, SSH and serial sessions. Session
limits are not enforced on FindMe accounts or the root
account.
A value of 0 turns session limits off.
This includes web, SSH and serial sessions. Session
limits are not enforced on 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.
After enabling the service you must go and configure
the specific protection categories.
HTTPS must also be enabled for access via HTTP to
function.
HTTP Strict
Transport
Security
(HSTS)
Determines whether web browsers
are instructed to only ever use a
secure connection to access this
server. Enabling this feature gives
added protection against man-in-themiddle (MITM) attacks.
On: the Strict-Transport-Security
header is sent with all responses
from the web server, with a 1 year
expiry time.
Off: the Strict-Transport-Security
header is not sent, and browsers
work as normal.
Default is On.
See below for more information about HSTS.
Cisco VCS Administrator Guide (X8.1.1) Page 41of 507
Page 42
Network and system settings
Field Description Usage tips
Network services
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). Note
that a restart is required if you are
changing from Not required to
Certificate validation.
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 (the client system) can use the VCS web
interface only if it has a valid (in date and not revoked
by a CRL) client certificate that is signed by a CA in the
VCS's trusted CA certificate list.
Ensure your browser has a valid client certificate
before enabling this feature. The procedure for
uploading a certificate to your browser may vary
depending on the browser type and you may need to
restart your browser for the certificate to take effect.
You can upload CA certificates on the Managing the
trusted CA certificate list [p.285] page, and test client
certificates on the Testing client certificates [p.292]
page.
Enabling Certificate-based authentication means that
the standard login mechanism is no longer available.
You can log in only if your browser certificate 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.
This setting does not affect client verification of the
VCS's server certificate.
Certificate
revocation list
(CRL)
checking
CRL
inaccessibility
fallback
behavior
Specifies whether HTTPS client
certificates are checked against
certificate revocation lists (CRLs).
None: no CRL checking is performed.
Peer: only the CRL associated with
the CA that issued the client's
certificate is checked.
All: all CRLs in the trusted certificate
chain of the CA that issued the
client's certificate are checked.
Default: All
Controls the revocation checking
behavior if the revocation status
cannot be established, for example if
the revocation source cannot be
contacted.
Treat as revoked: treat the certificate
as revoked (and thus do not allow the
TLS connection).
Treat as not revoked: treat the
certificate as not revoked.
Default: Treat as not revoked
Only applies if Client certificate-based security is
enabled.
Only applies if Client certificate-based security is
enabled.
Cisco VCS Administrator Guide (X8.1.1) Page 42of 507
Page 43
Network and system settings
Network services
By default, access via HTTPS and SSH is enabled. For optimum security, disable HTTPS and SSH and use
the serial port to manage the system. Because access to the serial port allows the password to be reset, we
recommend that you install the VCS in a physically secure environment.
HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) provides a mechanism where a web server forces a web browser to
communicate with it using secure connections only.
As of October 2012, this mechanism is supported by the following browsers:
n Chrome, versions 4.0.211.0 and later
n Firefox, versions 4 and later
When HSTS is enabled, a browser that supports HSTS will:
n Automatically turn any insecure links to the website into secure links (for example,
http://example.com/page/ is modified to https://example.com/page/ before accessing the
server).
n Only allow access to the server if the connection is secure (for example, the server's TLS certificate is
valid, trusted and not expired).
Browsers that do not support HSTS will ignore the Strict-Transport-Security header and work as before. They
will still be able to access the server.
Note that compliant browsers only respect Strict-Transport-Security headers if they access the server
through its fully qualified name (rather than its IP address).
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, alarms, and the number of current traversal calls, non-traversal calls and registrations.
To control the display of status items:
n ENTER stops the display from automatically rotating through the status items. This is useful if you need to
review all of the alarms or read a long IPv6 address. Press ENTER again to resume the rotating display.
n UP/DOWN displays the previous or next status item.
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 Cisco 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.
The information made available by the VCS includes the following:
Cisco VCS Administrator Guide (X8.1.1) Page 43of 507
Page 44
Network and system settings
Network services
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
Cisco TMS), you must select an alternative SNMP mode. The configurable options are:
Field Description Usage tips
SNMP mode Controls the level of SNMP support.
Disabled: no SNMP support.
SNMPv3 (secure SNMP): supports authentication and
encryption.
SNMPv3 plus TMS support: secure SNMPv3 plus nonsecure access to OID 1.3.6.1.2.1.1.2.0 only.
SNMPv2c: non-secure community-based SNMP.
Community
name
System
contact
Location Specifies the physical location of the VCS.
Username The VCS's SNMP username, used to identify this SNMP
v3 Authentication settings (only applicable to SNMPv3)
Authentication
mode
Type The algorithm used to encrypt authentication
The VCS's SNMP community name. The default is
public.
The name of the person who can be contacted
regarding issues with the VCS.
agent to the SNMP manager.
Enables or disables SNMPv3 authentication.
credentials.
SHA: Secure Hash Algorithm.
MD5: Message-Digest algorithm 5.
If you want to use secure SNMPv3 but
you also use Cisco TMS as your
external manager, you must select
SNMPv3 plus TMS support.
Only applies to SNMPv2c and
SNMPv3 plus TMS support.
The System contact and Location
are used for reference purposes by
administrators when following up on
queries.
Only applies when using secure
SNMPv3.
Password The password used to encrypt authentication
credentials.
v3 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.
Cisco VCS Administrator Guide (X8.1.1) Page 44of 507
Must be at least 8 characters.
Page 45
Network and system settings
Network services
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 settings
The Time page (System > Time) is used to configure the VCS's NTP servers and to specify the local time
zone.
An NTP server is a remote server with which the VCS synchronizes in order to ensure its time is accurate.
The NTP server provides the VCS with UTC time.
Accurate time is necessary for correct system operation.
Configuring the NTP servers
To configure the VCS with one or more NTP servers to be used when synchronizing system time, enter the
Address of up to five servers in one of the following formats, depending on the system's DNS settings (you
can check these settings on the DNS page, System > DNS):
n if there are no DNS servers configured, you must use an IP address for the NTP server
n if there are one or more DNS servers configured, you can use an FQDN or IP address for the NTP server
n if there is a DNS Domain name configured in addition to one or more DNS servers, you can use the
server name, FQDN or IP address for the NTP server
Three of the Address fields default to NTP servers provided by Cisco.
You can configure the Authentication method used by the VCS when connecting to an NTP server. Use one
of the following options for each NTP server connection:
Authentication
method
Disabled No authentication is used.
Symmetric key Symmetric key authentication. When using this method a Key ID, Hash method and Pass
Private key Private key authentication. This method uses an automatically generated private key with which
Description
phrase must be specified. The values entered here must match exactly the equivalent settings
on the NTP server. You can use the same symmetric key settings across multiple NTP servers.
However, if you want to configure each server with a different pass phrase, you must also ensure
that each server has a unique key ID.
to authenticate messages sent to the NTP server.
Displaying NTP status information
The synchronization status between the NTP server and the VCS is shown in the Status area as follows:
n Starting: the NTP service is starting.
n Synchronized: the VCS has successfully obtained accurate system time from an NTP server.
n Unsynchronized: the VCS is unable to obtain accurate system time from an NTP server.
n Down: the VCS's NTP client is not running.
n Reject: the NTP service is not accepting NTP responses.
Cisco VCS Administrator Guide (X8.1.1) Page 45of 507
Page 46
Network and system settings
Network services
Note that updates may take a few minutes to be displayed in the status table.
Other status information available includes:
Field Description
NTP server The actual NTP server that has responded to the request. This may be different to the NTP server
in the NTP server address field.
Condition Gives a relative ranking of each NTP server. All servers that are providing accurate time are
given a status of Candidate; of those, the server that the VCS considers to be providing the most
accurate time and is therefore using shows a status of sys.peer.
Flash A code giving information about the server's status. 00 ok means there are no issues. See the
Flash status word reference table [p.493] for a complete list of codes.
Authentication Indicates the status of the current authentication method. One of ok, bad or none. none is
specified when the Authentication method is Disabled.
Event Shows the last event as determined by NTP (for example reachable or sys.peer)
Reachability Indicates the results of the 8 most recent contact attempts between the VCS and the NTP server,
with a tick indicating success and a cross indicating failure. The result of the most recent attempt
is shown on the far right.
Each time the NTP configuration is changed, the NTP client is restarted and the Reachability
field will revert to all crosses apart from the far right indicator which will show the result of the first
connection attempt after the restart. However, the NTP server may have remained contactable
during the restart process.
Offset The difference between the NTP server's time and the VCS's time.
Delay The network delay between the NTP server and the VCS.
Stratum The degree of separation between the VCS and a reference clock. 1 indicates that the NTP
server is a reference clock.
Ref ID A code identifying the reference clock.
Ref time The last time that the NTP server communicated with the reference clock.
For definitions of the remaining fields on this page, and for further information about NTP, see Network Time
Protocol website.
VCS time display and time zone
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.
Note that UTC timestamps are included at the end of each entry in the Event 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 servers are 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 (or fractions 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) when
appropriate.
Cisco VCS Administrator Guide (X8.1.1) Page 46of 507
Page 47
Network and system settings
Network services
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 above the welcome message on the login page when using the web
interface.
n supported image file formats are JPG, GIF and PNG
n images larger than 200x200 pixels will be scaled down
If the VCS is using the TMS Provisioning Extension services to provide FindMe account data, then users log
into their FindMe accounts through Cisco TMS, not through VCS.
Note that this feature is not configurable using the CLI.
Cisco VCS Administrator Guide (X8.1.1) Page 47of 507
Page 48
Network and system settings
Configuring external manager settings
Configuring external manager settings
The External manager page (System > External manager) is used to configure the VCS's connection to
an external management system.
An external manager is a remote system, such as the Cisco TelePresence Management Suite (Cisco TMS),
used to monitor events occurring on the VCS, for example call attempts, connections and disconnections,
and as a place for where the VCS can send alarm information. The use of an external manager is optional.
Field Description Usage tips
Address
and path
Protocol Determines whether
Certificate
verification
mode
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.
communications with the
external manager are over
HTTP or HTTPS. The default
is HTTPS.
Controls whether the
certificate presented by the
external manager is verified.
If you are using Cisco TMS as your external manager, use the
default path of tms/public/external/management/
SystemManagementService.asmx.
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 Managing the
trusted CA certificate list [p.285] page (Maintenance > Security
certificates > Trusted CA certificate).
Note that:
n the VCS will continue to operate without loss of service if its connection to Cisco TMS fails. This applies
even if the VCSs are clustered. No specific actions are required as the VCS and Cisco TMS will
automatically start communicating with each other again after the connection is re-established.
n Cisco TMS identifies the VCS as a "TANDBERG VCS".
Cisco VCS Administrator Guide (X8.1.1) Page 48of 507
Page 49
Network and system settings
Configuring TMS Provisioning Extension services
Configuring TMS Provisioning Extension
services
Cisco TMSPE services are hosted on Cisco TMS. They provide the user, device and phone book data that is
used by the VCS's Provisioning Server to service provisioning requests from endpoint devices. They also
provide the VCS with the FindMe account configuration data that it uses to provide FindMe services.
The TMS Provisioning Extension services page (System > TMS Provisioning Extension services) is
used to configure how the VCS connects to the Cisco TMSPE services. We recommend that you use Cisco
TMS to make any changes to the Cisco TMSPE services' configuration settings. Any changes made to the
settings via this page will not be applied within Cisco TMS.
The FindMe service can only be configured if the FindMe option key is installed, and the Users, Phone
books and Devices services can only be configured if the Device Provisioning option key is installed.
The configurable options are:
Field Description Usage tips
Default connection configuration
This section specifies default connection settings for accessing the Cisco TMSPE services. Each specific service
can choose to use these default settings or, alternatively, specify its own connection settings, for example if a
different Cisco TMSPE server is being used for each service.
Server address The IP address or Fully Qualified
Domain Name (FQDN) of the
service.
Destination port The listening port on the Cisco
TMSPE service. Default is 443.
Encryption The encryption to use for the
connection to the Cisco TMSPE
service.
Off: no encryption is used.
TLS: TLS encryption is used.
Default is TLS.
Verify certificate Controls whether the certificate
presented by the Cisco TMSPE
service is verified against the
VCS's current trusted CA list and, if
loaded, the revocation list. Default
is Yes.
A TLS connection is recommended.
If you enable verification:
n IIS (on the Cisco TMSPE server) must be installed
with a signed certificate and be set to enforce SSL
connections.
n You must add the certificate of the issuer of the Cisco
TMSPE server's certificate to the file containing the
VCS's trusted CA certificates. This is done from the
Managing the trusted CA certificate list [p.285] page
(Maintenance > Security certificates > Trusted CA
certificate).
Cisco VCS Administrator Guide (X8.1.1) Page 49of 507
Page 50
Network and system settings
Field Description Usage tips
Configuring TMS Provisioning Extension services
Check certificate
hostname
Base group The ID used to identify this VCS
Authentication
username and
password
Service-specific configuration
You can specify the connection details for each of the Cisco TMSPE services: Users, FindMe, Phone books and
Devices.
Connect to this
service
Polling interval The frequency with which the
Controls whether the hostname
contained within the certificate
presented by the Cisco TMSPE
service is verified by the VCS.
Default is Yes.
(or VCS cluster) with the Cisco
TMSPE service.
The username and corresponding
password used by the VCS to
authenticate itself with the Cisco
TMSPE service.
Controls whether the VCS
connects to the Cisco TMSPE
service. Default is No.
VCS checks the Cisco TMSPE
service for updates. Defaults are:
FindMe: 2 minutes
Users: 2 minutes
Phone books: 1 day
The Device service polling
interval is set to 30 seconds and
cannot be modified.
If enabled, the certificate hostname (also known as the
Common Name) must match the specified Server
address. If the server address is an IP address, the
required hostname is obtained via a DNS lookup.
This only applies if Verify certificate is Yes.
The TMS administrator will supply this value.
The Base group ID used by the Devices service must
be explicitly specified as it is normally different from that
used by the other services.
If TLS encryption is not enabled, the authentication
password is sent in the clear.
If enabled, the status of the connection is shown to the
right of the field; this can be either Checking, Active or
Failed. Click details to view full status information.
You can request an immediate update of all services by
clicking Check for updates at the bottom of the page.
Use the default
connection
configuration
Controls whether the service uses
the default connection
configuration for Cisco TMSPE
services. Default is Yes.
A full and immediate resynchronization of all data between the VCS and Cisco TMS can be triggered at any
time by clicking Perform full synchronization (at the bottom of the of the TMS Provisioning Extension
services page). Note that this will result in a temporary (a few seconds) lack of service on the VCS while the
data is deleted and fully refreshed. If you only need to ensure that all of the latest updates within Cisco TMS
have been supplied to the VCS then click Check for updates instead.
Further status information
The menu options under Status > Applications > TMS Provisioning Extension services provide full
status information about the Cisco TMSPE services, including:
n the status of the connection between the VCS and the Cisco TMSPE services
n views of the user, FindMe and phone book data supplied by the Cisco TMSPE services
Cisco VCS Administrator Guide (X8.1.1) Page 50of 507
If No is selected, an additional set of connection
configuration parameters will appear. You can then
specify alternative connection details for the service that
will override those specified in the Default connection
configuration section.
Page 51
Network and system settings
Configuring TMS Provisioning Extension services
n a summary of the requests received from endpoint devices and the number of provisioning licenses being
consumed
n the status of the devices that are making provisioning requests to the VCS's Provisioning Server
Cisco VCS Administrator Guide (X8.1.1) Page 51of 507
Page 52
Firewall traversal
This section describes how to configure your VCS Control and VCS Expressway in order to traverse
firewalls.
About firewall traversal 53
Configuring a traversal client and server 57
Configuring ports for firewall traversal 58
Firewall traversal and authentication 61
Configuring Expressway and traversal endpoint communications 62
About ICE and TURN services 63
Cisco VCS Administrator Guide (X8.1.1) Page 52of 507
Page 53
Firewalltraversal
About firewall traversal
About firewall traversal
The purpose of a firewall is to control the IP traffic entering your network. Firewalls will generally block
unsolicited incoming requests, meaning that any calls originating from outside your network will be
prevented. However, firewalls can be configured to allow outgoing requests to certain trusted destinations,
and to allow responses from those destinations. This principle is used by Cisco's Expressway technology to
enable secure traversal of any firewall.
The Expressway solution
The Expressway solution consists of:
n A VCS Expressway located outside the firewall on the public network or in the DMZ, which acts as the
firewall traversal server.
n A VCS Control or other traversal-enabled endpoint located in a private network, which acts as the firewall
traversal client.
The two systems work together to create an environment where all connections between the two are
outbound, i.e. established from the client to the server, and thus able to successfully traverse the firewall.
We recommend that both the VCS Expressway and the VCS Control run the same software version.
How does it work?
The traversal client constantly maintains a connection via the firewall to a designated port on the traversal
server. This connection is kept alive by the client sending packets at regular intervals to the server. When the
traversal server receives an incoming call for the traversal client, it uses this existing connection to send an
incoming call request to the client. The client then initiates the necessary outbound connections required for
the call media and/or signaling.
This process ensures that from the firewall’s point of view, all connections are initiated from the traversal
client inside the firewall out to the traversal server.
For firewall traversal to function correctly, the VCS Expressway must have one traversal server zone
configured on it for each client system that is connecting to it (this does not include traversal-enabled
endpoints which register directly with the VCS Expressway; the settings for these connections are
configured in a different way). Likewise, each VCS client must have one traversal client zone configured on it
for each server that it is connecting to.
The ports and protocols configured for each pair of client-server zones must be the same. See the
Configuring a traversal client and server [p.57] for a summary of the required configuration on each system.
Because the VCS Expressway listens for connections from the client on a specific port, you are
recommended to create the traversal server zone on the VCS Expressway before you create the traversal
client zone on the VCS Control.
Note that the traversal client and the traversal server must both be VCS systems (neither can be a Cisco
Expressway).
Cisco VCS Administrator Guide (X8.1.1) Page 53of 507
Page 54
Firewalltraversal
About firewall traversal
Endpoint traversal technology requirements
The "far end" (at home or at a hotel, for example) endpoint requirements to support firewall traversal are
summarized below:
n For H.323, the endpoint needs to support Assent or H460.18 and H460.19.
n For SIP, the endpoint just needs to support standard SIP.
l Registration messages will keep the "‘far end" firewall ports open for VCS to send messages to that
endpoint. The VCS waits for media from the endpoint behind the firewall, before returning media to it on
that same port – the endpoint does have to support media transmission and reception on the same port.
l The VCS also supports SIP outbound, which is an alternative method of keeping firewalls open without
the overhead of using the full registration message.
n SIP and H.323 endpoints can register to the VCS Expressway or they can just send calls to the VCS
Expressway as the local "DMZ" firewall has relevant ports open to allow communication to the VCS
Expressway over SIP and H.323 ports.
Endpoints can also use ICE to find the optimal (in their view of what optimal is) path for media
communications between themselves. Media can be sent directly from endpoint to endpoint, from endpoint
via the outside IP address of the destination firewall to the destination endpoint, or from the endpoint via a
TURN server to destination endpoint.
n The VCS supports ICE for calls where the VCS does not have to traverse media (for example if there is no
IPv4/IPv6 conversion or SIP / H.323 conversion required); typically this means 2 endpoints which are able
to support ICE, directly communicating to a VCS Expressway cluster.
n The VCS Expressway has its own built-in TURN server to support ICE-enabled endpoints.
H.323 firewall traversal protocols
The VCS supports two different firewall traversal protocols for H.323: Assent and H.460.18/H.460.19.
n Assent is Cisco’s proprietary protocol.
n H.460.18 and H.460.19 are ITU standards which define protocols for the firewall traversal of signaling and
media respectively. These standards are based on the original Assent protocol.
A traversal server and traversal client must use the same protocol in order to communicate. The two
protocols each use a different range of ports.
SIP firewall traversal protocols
The VCS supports the Assent protocol for SIP firewall traversal of media.
The signaling is traversed through a TCP/TLS connection established from the client to the server.
Media demultiplexing
The VCS Expressway uses media demultiplexing in the following call scenarios:
Cisco VCS Administrator Guide (X8.1.1) Page 54of 507
Page 55
Firewalltraversal
About firewall traversal
n Any H.323 or SIP call leg to/from a VCS Control through a traversal zone configured to use Assent.
n Any H.323 call leg to/from a VCS Control through a traversal server zone configured to use H460.19 in
demultiplexing mode
n H.323 call legs between a VCS Expressway and an Assent or H.460.19 enabled endpoint
The VCS Expressway uses non-demultiplexed media for call legs directly to/from SIP endpoints (that is
endpoints which do not support Assent or H.460.19), or if the traversal server zone is not configured to use
H.460.19 in demultiplexing mode.
Media demultiplexing ports on the VCS Expressway are allocated from the general range of traversal media
ports. This applies to all RTP/RTCP media, regardless of whether it is H.323 or SIP. The default media port
range of 36000 to 59999 applies to new installations of X8.1 or later. The first 2 ports in the range are used for
multiplexed traffic only (with Large VM deployments the first 12 ports in the range – 36000 to 36011 – are
used). The previous default range of 50000 - 54999 still applies to earlier releases that have upgraded to X8.1.
For example, in a SIP call from within an enterprise to an endpoint at home through a VCS Control/VCS
Expressway pair, the only demultiplexing that would occur would be on the VCS Expressway ports facing
the VCS Control:
Enterprise
endpoint
Non-
RTP ports 36002 36004 36000 36002
RTCP ports 36003 36005 36001 36003
VCS Control VCS Expressway Home
demuxed
Nondemuxed
Demuxed Non-
demuxed
endpoint
However, an H.323 call from within an enterprise to an Assent capable H.323 endpoint at home through the
same VCS Control/VCS Expressway would perform demultiplexing on both sides of the VCS Expressway:
Enterprise
endpoint
Non-
RTP ports 36002 36004 36000 36000
RTCP ports 36003 36005 36001 36001
VCS Control VCS Expressway Home
demuxed
Nondemuxed
Demuxed Demuxed
endpoint
If the VCS Expressway has Advanced Networking, it will still use the same port numbers as described
above, but they will be assigned to the internal and external IP addresses.
Firewall traversal configuration overview
This section provides an overview to how the VCS can act as a traversal server or as a traversal client.
VCS as a firewall traversal client
The VCS can act as a firewall traversal client on behalf of SIP and H.323 endpoints registered to it, and any
systems that are neighbored with it. To act as a firewall traversal client, the VCS must be configured with
information about the systems that will act as its firewall traversal server.
Cisco VCS Administrator Guide (X8.1.1) Page 55of 507
Page 56
Firewalltraversal
About firewall traversal
You do this by adding a traversal client zone on the VCS client (Configuration > Zones > Zones) and
configuring it with the details of the traversal server. See Configuring traversal client zones [p.144] for more
information. You can create more than one traversal client zone if you want to connect to multiple traversal
servers.
Note that:
n In most cases, you will use a VCS Control as a firewall traversal client. However, a VCS Expressway can
also act as a firewall traversal client.
n The firewall traversal server used by the VCS client must be a VCS Expressway.
VCS as a firewall traversal server
The VCS Expressway has all the functionality of a VCS Control (including being able to act as a firewall
traversal client). However, its main feature is that it can act as a firewall traversal server for other Cisco
systems and any traversal-enabled endpoints that are registered directly to it. It can also provide TURN relay
services to ICE-enabled endpoints.
Configuring traversal server zones
For the VCS Expressway to act as a firewall traversal server for Cisco systems, you must create a traversal
server zone on the VCS Expressway (Configuration > Zones > Zones) and configure it with the details of
the traversal client. See Configuring traversal server zones [p.146] for more information.
You must create a separate traversal server zone for every system that is its traversal client.
Configuring other traversal server features
n For the VCS Expressway to act as a firewall traversal server for traversal-enabled endpoints (such as
Cisco MXP endpoints and any other endpoints that support the ITU H.460.18 and H.460.19 standards), no
additional configuration is required. See Configuring Expressway and traversal endpoint communications
[p.62] for more information.
n To enable TURN relay services and find out more about ICE, see About ICE and TURN services [p.63].
n To reconfigure the default ports used by the VCS Expressway, see Configuring ports for firewall traversal
[p.58].
Firewall traversal and Advanced Networking
The Advanced Networking option key enables the LAN 2 interface on the VCS Expressway (the option is not
available on a VCS Control). The LAN 2 interface is used in situations where the VCS Expressway is located
in a DMZ that consists of two separate networks - an inner DMZ and an outer DMZ - and your network is
configured to prevent direct communication between the two.
With the LAN 2 interface enabled, you can configure the VCS with two separate IP addresses, one for each
network in the DMZ. Your VCS then acts as a proxy server between the two networks, allowing calls to pass
between the internal and outer firewalls that make up your DMZ.
When Advanced Networking is enabled, all ports configured on the VCS, including those relating to firewall
traversal, apply to both IP addresses; you cannot configure ports separately for each IP address.
Cisco VCS Administrator Guide (X8.1.1) Page 56of 507
Page 57
Firewalltraversal
Configuring a traversal client and server
Configuring a traversal client and server
The basic steps in configuring a traversal client and server are as follows:
Step Description
On the VCS Expressway, create a traversal server zone (this represents the incoming connection from the
VCS Control). In the Username field, enter the VCS Control’s authentication username.
On the VCS Expressway, add the VCS Control’s authentication username and password as credentials
into the local authentication database.
On the VCS Control, create a traversal client zone (this represents the connection to the VCS Expressway).
Enter the same authentication Username and Password as specified on the VCS Expressway.
Configure all the modes and ports in the H.323 and SIP protocol sections to match identically those of the
traversal server zone on the VCS Expressway.
Enter the VCS Expressway’s IP address or FQDN in the Peer 1 address field.
Cisco VCS Administrator Guide (X8.1.1) Page 57of 507
Page 58
Firewalltraversal
Configuring ports for firewall traversal
Configuring ports for firewall traversal
Ports play a vital part in firewall traversal configuration. The correct ports must be set on the VCS
Expressway, traversal client and firewall in order for connections to be permitted.
Ports are initially configured on the VCS Expressway by the VCS Expressway administrator. The firewall
administrator and the traversal client administrator should then be notified of the ports, and they must
configure their systems to connect to these specific ports on the server. The only port configuration required
on the traversal client is the range of ports it uses for outgoing connections; the firewall administrator may
need to know this information so that if necessary they can configure the firewall to allow outgoing
connections from those ports.
The Port usage [p.311] pages (under Maintenance > Tools > Port usage) list all the IP ports that are being
used on the VCS, both inbound and outbound. This information can be provided to your firewall administrator
so that the firewall can be configured appropriately.
When Advanced Networking is enabled, all ports configured on the VCS, including those relating to firewall
traversal, apply to both IP addresses; you cannot configure ports separately for each IP address.
The Expressway solution works as follows:
1. Each traversal client connects via the firewall to a unique port on the VCS Expressway.
2. The server identifies each client by the port on which it receives the connection, and the authentication
credentials provided by the client.
3. After the connection has been established, the client regularly sends a probe to the VCS Expressway to
keep the connection alive.
4. When the VCS Expressway receives an incoming call for the client, it uses this initial connection to send
an incoming call request to the client.
5. The client then initiates one or more outbound connections. The destination ports used for these
connections differ for signaling and/or media, and depend on the protocol being used (see the following
sections for more details).
Configuring the firewall
For Expressway firewall traversal to function correctly, your firewall must be configured to:
n allow initial outbound traffic from the client to the ports being used by the VCS Expressway
n allow return traffic from those ports on the VCS Expressway back to the originating client
Note: we recommend that you turn off any H.323 and SIP protocol support on the firewall: these are not
needed in conjunction with the Expressway solution and may interfere with its operation.
Configuring traversal server ports
The VCS Expressway has specific listening ports used for firewall traversal. Rules must be set on your
firewall to allow connections to these ports. In most cases the default ports should be used. However, you
have the option to change these ports if necessary by going to the Ports page (Configuration > Traversal >
Ports).
The configurable ports are:
Cisco VCS Administrator Guide (X8.1.1) Page 58of 507
Page 59
Firewalltraversal
Configuring ports for firewall traversal
n H.323 Assent call signaling port; default is 2776
n H.323 H.460.18 call signaling port; default is 2777
Note that media demultiplexing ports are allocated from the general range of traversal media ports.
Configuring ports for connections from traversal clients
Each traversal server zone specifies an H.323 port and a SIP port to use for the initial connection from the
client. Each time you configure a new traversal server zone on the VCS Expressway, you are allocated
default port numbers for these connections:
n H.323 ports start at UDP/6001 and increment by 1 for every new traversal server zone.
n SIP ports start at TCP/7001 and increment by 1 for every new traversal server zone.
You can change these default ports if necessary but you must ensure that the ports are unique for each
traversal server zone. After the H.323 and SIP ports have been set on the VCS Expressway, matching ports
must be configured on the corresponding traversal client. Note that:
n The default port used for the initial connections from MXP endpoints is the same as that used for standard
RAS messages, that is UDP/1719. While you can change this port on the VCS Expressway, most
endpoints will not support connections to ports other than UDP/1719, therefore we recommend that you
leave this as the default.
n You must allow outbound connections through your firewall to each of the unique SIP and H.323 ports that
are configured on each of the VCS Expressway’s traversal server zones.
The following table shows the default ports used for connections to the VCS Expressway.
Table 1: Default traversal port connections
Protocol Call signaling Media
Assent UDP/1719: listening port for RAS
messages
TCP/2776: listening port for H.225 and
H.245 protocols
H.460.18/19 UDP/1719: listening port for RAS
messages
TCP/1720: listening port for H.225
protocol
TCP/2777: listening port for H.245
protocol
SIP SIP call signaling uses the same port as
used by the initial connection between
the client and server.
RTP and RTCP media demultiplexing ports are
allocated from the start of the traversal media ports
range: UDP/36000-36001*.
RTP and RTCP media demultiplexing ports are
allocated from the start of the traversal media ports
range: UDP/36000-36001*.
RTP and RTCP media non-demultiplexing ports are
allocated from the remainder of the traversal media
ports range: UDP/36002-59999*.
Where the traversal client is a VCS, SIP media uses
Assent to traverse the firewall.
* The default media port range of 36000 to 59999 applies to new installations of X8.1 or later. The first 2 ports
in the range are used for multiplexed traffic only (with Large VM deployments the first 12 ports in the range –
36000 to 36011 – are used). The previous default range of 50000 - 54999 still applies to earlier releases that
have upgraded to X8.1.
The call signaling ports are configured via Configuration > Traversal > Ports. The traversal media port
range is configured via Configuration > Local Zone > Traversal Subzone.
Cisco VCS Administrator Guide (X8.1.1) Page 59of 507
Page 60
Firewalltraversal
Configuring ports for firewall traversal
If your VCS Expressway does not have any endpoints registering directly with it, and it is not part of a
cluster, then UDP/1719 is not required. You therefore do not need to allow outbound connections to this port
through the firewall between the VCS Control and VCS Expressway.
Configuring TURN ports
The VCS Expressway can be enabled to provide TURN services (Traversal Using Relays around NAT)
which can be used by ICE-enabled SIP endpoints.
The ports used by these services are configurable via Configuration > Traversal > TURN.
The ICE clients on each of the SIP endpoints must be able to discover these ports, either by using SRV
records in DNS or by direct configuration.
Configuring ports for connections out to the public internet
In situations where the VCS Expressway is attempting to connect to an endpoint on the public internet, you
will not know the exact ports on the endpoint to which the connection will be made. This is because the ports
to be used are determined by the endpoint and advised to the VCS Expressway only after the server has
located the endpoint on the public internet. This may cause problems if your VCS Expressway is located
within a DMZ (where there is a firewall between the VCS Expressway and the public internet) as you will not
be able to specify in advance any rules that will allow you to connect out to the endpoint’s ports.
You can however specify the ports on the VCS Expressway that are used for calls to and from endpoints on
the public internet so that your firewall administrator can allow connections via these ports. The ports that
can be configured for this purpose are:
Table 2: Port connections out to the public internet
H.323 SIP TURN
TCP/1720: signaling
UDP/1719: signaling
UDP/36000-59999: media*
TCP/15000-19999: signaling
TCP/5061: signaling
UDP/5060 (default): signaling
UDP/36000-59999: media*
TCP: a temporary port in the range
25000-29999 is allocated
UDP/3478 (default): TURN services
**
UDP/24000-29999 (default range):
media **
* The default media port range of 36000 to 59999 applies to new installations of X8.1 or later. The first 2 ports
in the range are used for multiplexed traffic only (with Large VM deployments the first 12 ports in the range –
36000 to 36011 – are used). The previous default range of 50000 - 54999 still applies to earlier releases that
have upgraded to X8.1.
** On Large VM server deployments you can configure a range of TURN request listening ports. The default
range is 3478 – 3483. The default TURN relay media port range of 24000 – 29999 applies to new installations
of X8.1 or later. The previous default range of 60000 – 61799 still applies to earlier releases that have
upgraded to X8.1.
Cisco VCS Administrator Guide (X8.1.1) Page 60of 507
Page 61
Firewalltraversal
Firewalltraversal and authentication
Firewall traversal and authentication
The VCS Expressway allows only authenticated client systems to use it as a traversal server.
Upon receiving the initial connection request from the traversal client, the VCS Expressway asks the client
to authenticate itself by providing its authentication credentials. The VCS Expressway then looks up the
client’s credentials in its own authentication database. If a match is found, the VCS Expressway accepts the
request from the client.
The settings used for authentication depend on the type of traversal client:
Traversal client VCS Expressway traversal server
VCS Control (or VCS Expressway)
The VCS client provides its Username and
Password. These are set on the traversal client
zone by using Configuration > Zones > Zones >
Edit zone, in the Connection credentials
section.
Endpoint
The endpoint client provides its Authentication
ID and Authentication Password.
The traversal server zone for the VCS client must be
configured with the client's authentication Username. This is
set on the VCS Expressway by using Configuration > Zones
> Zones > Edit zone, in the Connection credentials section.
There must also be an entry in the VCS Expressway’s
authentication database with the corresponding client
username and password.
There must be an entry in the VCS Expressway’s
authentication database with the corresponding client
username and password.
Note that all VCS traversal clients must authenticate with the VCS Expressway, even if the VCS
Expressway is not using device authentication for endpoint clients.
Authentication and NTP
All VCS traversal clients that support H.323 must authenticate with the VCS Expressway. The
authentication process makes use of timestamps and requires that each system uses an accurate system
time. The system time on a VCS is provided by a remote NTP server. Therefore, for firewall traversal to
work, all systems involved must be configured with details of an NTP server.
Cisco VCS Administrator Guide (X8.1.1) Page 61of 507
Page 62
Firewalltraversal
Configuring Expressway and traversal endpoint communications
Configuring Expressway and traversal endpoint
communications
Traversal-enabled H.323 endpoints can register directly with the VCS Expressway and use it for firewall
traversal.
The Locally registered endpoints page (Configuration > Traversal > Locally registered endpoints)
allows you to configure the way in which the VCS Expressway and traversal-enabled endpoints
communicate.
The options available are:
Field Description
H.323 Assent
mode
H.460.18 mode Determines whether or not H.323 calls using H.460.18/19 mode for firewall traversal are
H.460.19
demux mode
H.323
preference
UDP probe
retry interval
UDP probe
retry count
UDP probe
keep alive
interval
TCP probe
retry interval
TCP probe
retry count
Determines whether or not H.323 calls using Assent mode for firewall traversal are allowed.
allowed.
Determines whether the VCS Expressway operates in demultiplexing mode for calls from
locally registered endpoints.
On: uses the media demultiplexing ports for all calls.
Off: each call uses a separate pair of ports for media.
Determines which protocol the VCS Expressway uses if an endpoint supports both Assent and
H.460.18.
The frequency (in seconds) with which locally registered endpoints send a UDP probe to the
VCS Expressway.
The number of times locally registered endpoints attempt to send a UDP probe to the VCS
Expressway.
The interval (in seconds) with which locally registered endpoints send a UDP probe to the VCS
Expressway after a call is established, in order to keep the firewall’s NAT bindings open.
The frequency (in seconds) with which locally registered endpoints send a TCP probe to the
VCS Expressway.
The number of times locally registered endpoints attempt to send a TCP probe to the VCS
Expressway.
TCP probe
keep alive
interval
Cisco VCS Administrator Guide (X8.1.1) Page 62of 507
The interval (in seconds) with which locally registered endpoints send a TCP probe to the VCS
Expressway after a call is established, in order to keep the firewall’s NAT bindings open.
Page 63
Firewalltraversal
About ICE and TURN services
About ICE and TURN services
About ICE
ICE (Interactive Connectivity Establishment) provides a mechanism for SIP client NAT traversal. ICE is not
a protocol, but a framework which pulls together a number of different techniques such as TURN and STUN.
It allows endpoints (clients) residing behind NAT devices to discover paths through which they can pass
media, verify peer-to-peer connectivity via each of these paths and then select the optimum media
connection path. The available paths typically depend on any inbound and outbound connection restrictions
that have been configured on the NAT device. Such behavior is described in RFC 4787.
An example usage of ICE is two home workers communicating via the internet. If the two endpoints can
communicate via ICE the VCS Expressway may (depending on how the NAT devices are configured) only
need to take the signaling and not take the media (and is therefore a non-traversal call). If the initiating ICE
client attempts to call a non-ICE client, the call set-up process reverts to a conventional SIP call requiring
NAT traversal via media latching where the VCS also takes the media and thus requires a traversal license.
For more information about ICE, see RFC 5245.
About TURN
TURN (Traversal Using Relays around NAT) services are relay extensions to the STUN network protocol
that enable a SIP or H.323 client to communicate via UDP or TCP from behind a NAT device. Currently the
VCS supports TURN over UDP only.
For more information about TURN see RFC 5766, and for detailed information about the base STUN
protocol, see RFC 5389.
Each ICE client requests the TURN server to allocate relays for the media components of the call. A relay is
required for each component in the media stream between each client.
After the relays are allocated, each ICE client has 3 potential connection paths (addresses) through which it
can send and receive media:
n its host address which is behind the NAT device (and thus not reachable from endpoints on the other side
of the NAT)
n its publicly-accessible address on the NAT device
n a relay address on the TURN server
The endpoints then decide, by performing connectivity checks through ICE, how they are going to
communicate. Depending upon how the NAT devices are configured, the endpoints may be able to
communicate between their public-facing addresses on the NAT devices or they may have to relay the media
via the TURN server. If both endpoints are behind the same NAT device they can send media directly
between themselves using their internal host addresses.
After the media route has been selected, the TURN relay allocations are released if the chosen connection
paths do not involve routing via the TURN server. Note that the signaling always goes via the VCS,
regardless of the final media communication path chosen by the endpoints.
Cisco VCS Administrator Guide (X8.1.1) Page 63of 507
Page 64
Firewalltraversal
About ICE and TURN services
Capabilities and limitations
n A VCS appliance (or equivalent VM) supports up to 1800 relay allocations. This is typically enough to
support 100 calls but does depend on the network topology and the number of media stream components
used for the call (for example, some calls may use Duo Video, or other calls might be audio only). A Large
VM supports up to 6000 relays, spread evenly across 6 ports where each port is limited to handling 1000
relays.
n Clustered VCSs: if the requested TURN server's relays are fully allocated the server will respond to the
requesting client with the details of an alternative server in the cluster (the TURN server currently with the
most available resources).
n The VCS's TURN services are supported over single and dual network interfaces (via the Advanced
Networking option). For dual network interfaces, the TURN server listens on both interfaces but relays are
allocated only on the VCS's externally facing LAN interface.
n If static NAT is enabled on the VCS Expressway, the TURN relay candidate address that is offered will be
the internal/private IP address of the VCS Expressway, not its static NAT address. Thus ICE clients in
the public internet may not be able to route media via the TURN server.
n Microsoft ICE (which is not standards-based) is not supported by the VCS Expressway's TURN server; to
enable communications between the VCS and Microsoft Lync clients that are registered through a
Microsoft Edge Server you need to use the B2BUA for Microsoft Lync.
n The TURN server does not support bandwidth requests. Traversal zone bandwidth limits do not apply.
Configuring TURN services
TURN relay services are only available on the VCS Expressway. To use TURN services you need the
TURN Relay option key (this controls the number of TURN relays that can be simultaneously allocated by
the TURN server).
The TURN page (Configuration > Traversal > TURN) is used to configure the VCS Expressway's TURN
settings. If you are configuring your VCS Expressway for delegated credential checking you can also
determine, via the Authentication realm, the traversal zone through which credential checking of TURN
server requests is delegated.
The configurable options are:
Field Description Usage tips
TURN
services
TURN
requests port
Determines whether the VCS offers TURN
services to traversal clients.
The listening port for TURN requests. The default
is 3478.
On Large VM server deployments you can
configure a range of TURN request listening
ports. The default range is 3478 – 3483.
To allow endpoints such as Jabber Video
to discover TURN services, you need to set
up a DNS SRV record for _turn._udp.
(either for the single port, or range of ports
as appropriate).
If TURN services are already enabled,
any changes to the port numbers do not
come into effect until the TURN services
are restarted.
Cisco VCS Administrator Guide (X8.1.1) Page 64of 507
Page 65
Firewalltraversal
Field Description Usage tips
About ICE and TURN services
Delegated
credential
checking
Authentication
realm
Media port
range start /
end
Controls whether the credential checking of
TURN server requests is delegated, via a
traversal zone, to another VCS. The associated
Authentication realm determines which traversal
zone is used.
Off: use the relevant credential checking
mechanisms (local database or H.350 directory
via LDAP) on the VCS performing the
authentication challenge.
On: delegate the credential checking to a
traversal client.
The default is Off.
This is the realm sent by the server in its
authentication challenges.
n When Delegated credential checking is Off,
this is a free-form text field.
n When Delegated credential checking is On,
you choose from the set of configured SIP
domains. The chosen domain also determines
the traversal zone through which credential
checking is delegated.
The lower and upper port in the range used for
the allocation of TURN relays.
The default TURN relay media port range of
24000 – 29999 applies to new installations of
X8.1 or later. The previous default range of 60000
– 61799 still applies to earlier releases that have
upgraded to X8.1.
See delegated credential checking for more
information.
When Delegated credential checking is
Off, ensure that the client's credentials are
stored in the relevant device authentication
database.
TURN relay status information
The TURN relays page lists all the currently active TURN relays on the VCS. You can also review further
details of each TURN relay including permissions, channel bindings and counters.
Cisco VCS Administrator Guide (X8.1.1) Page 65of 507
Page 66
Unified Communications
This section describes how to configure the VCS Control and VCS Expressway for Unified Communications
functionality, a core part of the Cisco Collaboration Edge Architecture:
Mobile and remote access 67
Configuring mobile and remote access on VCS 69
Cisco VCS Administrator Guide (X8.1.1) Page 66of 507
Page 67
Unified Communications
Mobile and remote access
Mobile and remote access
Cisco Unified Communications mobile and remote access is a core part of the Cisco Collaboration Edge
Architecture. It allows endpoints such as Cisco Jabber to have their registration, call control, provisioning,
messaging and presence services provided by Cisco Unified Communications Manager (Unified CM) when
the endpoint is not within the enterprise network. The VCS provides secure firewall traversal and line-side
support for Unified CM registrations.
The overall solution provides:
n Off-premises access: a consistent experience outside the network for Jabber and EX/MX/SX Series
clients
n Security: secure business-to-business communications
n Cloud services: enterprise grade flexibility and scalable solutions providing rich WebEx integration and
Service Provider offerings
n Gateway and interoperability services: media and signaling normalization, and support for non-standard
endpoints
Figure 3: Unified Communications: mobile and remote access
Note that third-party SIP or H.323 devices can register to the VCS Control and, if necessary, interoperate
with Unified CM-registered devices over a SIP trunk.
Cisco VCS Administrator Guide (X8.1.1) Page 67of 507
Page 68
Unified Communications
Mobile and remote access
Figure 4: Typical call flow: signaling and media paths
n Unified CM provides call control for both mobile and on-premises endpoints.
n Signaling traverses the Expressway solution between the mobile endpoint and Unified CM.
n Media traverses the Expressway solution and is relayed between endpoints directly; all media is encrypted
between the VCS Control and the mobile endpoint.
Jabber client connectivity without VPN
The mobile and remote access solution supports a hybrid on-premises and cloud-based service model,
providing a consistent experience inside and outside the enterprise. It provides a secure connection for
Jabber application traffic without having to connect to the corporate network over a VPN. It is a device and
operating system agnostic solution for Cisco Unified Client Services Framework clients on Windows, Mac,
iOS and Android platforms.
It allows Jabber clients that are outside the enterprise to:
n use instant messaging and presence services
n make voice and video calls
n search the corporate directory
n share content
n launch a web conference
n access visual voicemail
Note that Jabber Web and Cisco Jabber Video for TelePresence (Jabber Video) are not supported.
Cisco VCS Administrator Guide (X8.1.1) Page 68of 507
Page 69
Unified Communications
Configuring mobile and remote accesson VCS
Configuring mobile and remote access on VCS
This section describes the steps required to enable and configure mobile and remote access features on
VCS Control and VCS Expressway, and how to discover the Unified CM servers and IM&P servers used by
the service.
Note that this deployment requires valid certificates on both VCS Control and VCS Expressway. If XMPP
federation is to be used, the IM&P servers need to be discovered on the VCS Control for all the relevant
information to be available when generating certificate signing requests.
Setting up the VCS Control
This section describes the configuration steps required on the VCS Control.
Configuring DNS and NTP settings
Check and configure the basic system settings on VCS:
1. Ensure that System host name and Domain name are specified (System > DNS).
2. Ensure that local DNS servers are specified (System > DNS).
3. Ensure that all VCS systems are synchronized to a reliable NTP service (System > Time). Use an
Authentication method in accordance with your local policy.
If you have a cluster of VCSs you must do this for every peer.
Configuring the VCS Control for Unified Communications
Enabling mobile and remote access
To enable mobile and remote access functionality:
1. Go to Configuration > Unified Communications > Configuration.
2. Set Unified Communications mode to Mobile and remote access.
3. Click Save.
Note that you must select Mobile and remote access before you can configure the relevant domains and
traversal zones.
Configuring the domains to route to Unified CM
You must configure the domains for which registration, call control, provisioning, messaging and presence
services are to be routed to Unified CM.
1. On VCS Control, go to Configuration > Domains.
2. Select the domains (or create a new domain, if not already configured) for which services are to be routed
to Unified CM.
3. For each domain, turn On the services for that domain that VCS is to support. The available services are:
l SIP registrations and provisioning on VCS: the VCS is authoritative for this SIP domain. The VCS
acts as a SIP registrar and Presence Server for the domain, and accepts registration requests for any
SIP endpoints attempting to register with an alias that includes this domain. The default is On.
Cisco VCS Administrator Guide (X8.1.1) Page 69of 507
Page 70
Unified Communications
Configuring mobile and remote accesson VCS
l SIP registrations and provisioning on Unified CM: endpoint registration, call control and
provisioning for this SIP domain is serviced by Unified CM. The VCS acts as a Unified
Communications gateway to provide secure firewall traversal and line-side support for Unified CM
registrations. The default is Off.
l IM and Presence services on Unified CM: instant messaging and presence services for this SIP
domain are provided by the Unified CM IM and Presence service. The default is Off.
Turn On all of the applicable services for each domain. For example, the same domain may be used by
endpoints such as Jabber or EX Series devices that require line-side Unified Communications support,
and by other endpoints such as third-party SIP or H.323 devices that require VCS support. (In this
scenario, the signaling messages sent from the endpoint indicate whether line-side unified
communications or VCS support is required.)
Discovering IM&P and Unified CM servers
The VCS Control must be configured with the address details of the IM&P servers and Unified CM servers
that are to provide registration, call control, provisioning, messaging and presence services.
Note that IM&P server configuration is not required in the hybrid deployment model.
Uploading the IM&P / Unified CM tomcat certificate to the VCS Control trusted CA list
If you intend to have TLS verify mode set to On (the default and recommended setting) when discovering
the IM&P and Unified CM servers, the VCS Control must be configured to trust the tomcat certificate
presented by those IM&P and Unified CM servers.
1. Determine the relevant CA certificates to upload:
l If the servers are using self-signed certificates, the VCS Control's trusted CA list must include a copy
of the tomcat certificate from every IM&P / Unified CM server.
l If the servers are using CA-signed certificates, the VCS Control's trusted CA list must include the root
CA of the issuer of the tomcat certificates.
2. Upload the trusted Certificate Authority (CA) certificates to the VCS Control (Maintenance > Security
certificates > Trusted CA certificate).
3. Restart the VCS Control for the new trusted CA certificates to take effect (Maintenance > Restart
options).
Configuring IM&P servers
To configure the IM&P servers used for remote access:
1. On VCS Control, go to Configuration > Unified Communications > IM and Presence servers.
The resulting page displays any existing servers that have been configured.
2. Add the details of an IM&P publisher:
a. Click New.
b. Enter the IM and Presence publisher address and the Username and Password credentials
required to access the server. The address can be specified as an FQDN or as an IP address; we
recommend using FQDNs when TLS verify mode is On.
Note that these credentials are stored permanently in the VCS database. The IM&P user must have
the Standard AXL API Access role.
c. We recommend leaving TLS verify mode set to On to ensure VCS verifies the tomcat certificate
presented by the IM&P server for XMPP-related communications.
o
If the IM&P server is using self-signed certificates, the VCS Control's trusted CA list must include a
copy of the tomcat certificate from every IM&P server.
Cisco VCS Administrator Guide (X8.1.1) Page 70of 507
Page 71
Unified Communications
Configuring mobile and remote accesson VCS
o
If the IM&P server is using CA-signed certificates, the VCS Control's trusted CA list must include
the root CA of the issuer of the tomcat certificate.
d. Click Add address.
The system then attempts to contact the publisher and retrieve details of its associated nodes.
Note that the status of the IM&P server will show as Inactive until a valid traversal zone connection
between the VCS Control and the VCS Expressway has been established (this is configured later in
this process).
3. Repeat for every IM&P cluster.
After configuring multiple publisher addresses, you can click Refresh servers to refresh the details of the
nodes associated with selected addresses.
Configuring Unified CM servers
To configure the Unified CM servers used for remote access:
1. On VCS Control, go to Configuration > Unified Communications > Unified CM servers.
The resulting page displays any existing servers that have been configured.
2. Add the details of a Unified CM publisher:
a. Click New.
b. Enter the Unified CM publisher address and the Username and Password credentials of an
application user account that can access the server. The address can be specified as an FQDN or as
an IP address; we recommend using FQDNs when TLS verify mode is On.
Note that these credentials are stored permanently in the VCS database. The Unified CM user must
have the Standard AXL API Access role.
c. We recommend leaving TLS verify mode set to On to ensure VCS verifies the certificates presented
by the Unified CM server (its tomcat certificate for AXL and UDS queries, and its CallManager
certificate for subsequent SIP traffic).
o
If the Unified CM server is using self-signed certificates, the VCS Control's trusted CA list must
include a copy of the tomcat certificate and the CallManager certificate from every Unified CM
server.
o
If the Unified CM server is using CA-signed certificates, the VCS Control's trusted CA list must
include the root CA of the issuer of the tomcat certificate and the CallManager certificate.
d. Click Add address.
The system then attempts to contact the publisher and retrieve details of its associated nodes.
3. Repeat for every Unified CM cluster.
After configuring multiple publisher addresses, you can click Refresh servers to refresh the details of the
nodes associated with selected addresses.
Automatically generated zones and search rules
VCS Control automatically generates non-configurable neighbor zones between itself and each discovered
Unified CM node. A TCP zone is always created, and a TLS zone is created also if the Unified CM node is
configured with a Cluster Security Mode (System > Enterprise Parameters > Security Parameters) of 1
(Mixed) (so that it can support devices provisioned with secure profiles). The TLS zone is configured with its
TLS verify mode set to On if the Unified CM discovery had TLS verify mode enabled. This means that the
VCS Control will verify the CallManager certificate for subsequent SIP communications. Each zone is
created with a name in the format 'CEtcp-<node name>' or 'CEtls-<node name>'.
A non-configurable search rule, following the same naming convention, is also created automatically for each
zone. The rules are created with a priority of 45. If the Unified CM node that is targeted by the search rule has
a long name, the search rule will use a regex for its address pattern match.
Cisco VCS Administrator Guide (X8.1.1) Page 71of 507
Page 72
Unified Communications
Configuring mobile and remote accesson VCS
Note that load balancing is managed by Unified CM when it passes routing information back to the registering
endpoints.
Setting up the VCS Expressway
This section describes the configuration steps required on the VCS Expressway.
Configuring DNS and NTP settings
Check and configure the basic system settings on VCS:
1. Ensure that System host name and Domain name are specified (System > DNS).
2. Ensure that public DNS servers are specified (System > DNS).
3. Ensure that all VCS systems are synchronized to a reliable NTP service (System > Time). Use an
Authentication method in accordance with your local policy.
If you have a cluster of VCSs you must do this for every peer.
Configuring the VCS Expressway for Unified Communications
To enable mobile and remote access functionality:
1. Go to Configuration > Unified Communications > Configuration.
2. Set Unified Communications mode to Mobile and remote access.
3. Click Save.
Ensuring that TURN services are disabled on VCS Expressway
You must ensure that TURN services are disabled on the VCS Expressway used for mobile and remote
access.
1. Go to Configuration > Traversal > TURN.
2. Ensure that TURN services are Off.
Setting up VCS security certificates
This deployment requires secure communications between the VCS Control and the VCS Expressway, and
between the VCS Expressway and endpoints located outside the enterprise. Therefore, you must:
1. Install a suitable server certificate on both the VCS Control and the VCS Expressway. The certificate on
each VCS has different requirements for what needs to be included as subject alternate names as
described in VCS Control / VCS Expressway server certificate requirements below.
l The certificate must include the Client Authentication extension. (The system will not allow you to
upload a server certificate without this extension when mobile and remote access is enabled.)
l The VCS includes a built-in mechanism to generate a certificate signing request (CSR) and is the
recommended method for generating a CSR. This CSR includes the client authentication request and
can be used to help ensure each VCS certificate includes the correct subject alternate names for
Unified Communications and to establish a secure traversal zone. Ensure that the CA that signs the
request does not strip out the client authentication extension.
Cisco VCS Administrator Guide (X8.1.1) Page 72of 507
Page 73
Unified Communications
Configuring mobile and remote accesson VCS
l To generate a CSR and /or to upload a server certificate to the VCS, go to Maintenance > Security
certificates > Server certificate. You must restart the VCS for the new server certificate to take effect.
2. Install on both VCSs the trusted Certificate Authority (CA) certificates of the authority that signed the
VCS's server certificates, and, if appropriate, the authority that signed the endpoints' certificates. The
VCS Control must also trust the Unified CM and IM&P tomcat certificate.
To upload trusted Certificate Authority (CA) certificates to the VCS, go to Maintenance > Security
certificates > Trusted CA certificate. You must restart the VCS for the new trusted CA certificate to
take effect.
VCS Control server certificate requirements
The VCS Control server certificate needs to include the following elements in its list of subject alternate
names:
n The Chat Node Aliases that are configured on the IM and Presence servers. These are required only for
Unified Communications XMPP federation deployments that intend to use both TLS and group chat. (Note
that Unified Communications XMPP federation will be supported in a future VCS release).
The VCS Control automatically includes the chat node aliases in the CSR, providing it has discovered a
set of IM&P servers.
n The names, in FQDN format, of all of the Phone Security Profiles in Unified CM that are configured for
encrypted TLS and are used for devices requiring remote access. This ensures that Unified CM can
communicate with VCS Control via a TLS connection when it is forwarding messages from devices that
are configured with those security profiles.
A new certificate may need to be produced if chat node aliases are added or renamed, such as when an IM
and Presence node is added or renamed, or if new TLS phone security profiles are added. You must restart
the VCS Control for any new uploaded server certificate to take effect.
VCS Expressway server certificate requirements
The VCS Expressway server certificate needs to include the following elements in its list of subject alternate
names:
n All of the domains which have been configured for Unified Communications. They are required for secure
communications between endpoint devices and VCS Expressway.
This should include the email address domain entered by users of the client application (e.g. Jabber) and
any presence domains (as configured on the VCS Control) if they are different. There is no need to include
the domains in DNS-SEC deployments.
n The same set of Chat Node Aliases as entered on the VCS Control's certificate, if you are deploying
federated XMPP.
Note that the list of required aliases can be viewed (and copy-pasted) from the equivalent Generate CSR
page on the VCS Control.
A new certificate must be produced if new presence domains or chat node aliases are added to the system.
You must restart the VCS Expressway for any new uploaded server certificate to take effect.
See Certificate Creation and Use With VCS Deployment Guide for full information about how to create and
upload the VCS’s server certificate and how to upload a list of trusted certificate authorities.
Cisco VCS Administrator Guide (X8.1.1) Page 73of 507
Page 74
Unified Communications
Configuring mobile and remote accesson VCS
Setting up secure VCS traversal zones
To support Unified Communications features such as mobile and remote access, there must be a secure
traversal zone connection between the VCS Control and the VCS Expressway:
n The traversal client zone and the traversal server zone must be configured to use SIP TLS with TLS verify
mode set to On, and Media encryption mode must be Force encrypted.
n Both VCSs must trust each other's server certificate. As each VCS acts both as a client and as a server
you must ensure that each VCS’s certificate is valid both as a client and as a server.
n If a H.323 or a non-encrypted connection is required, a separate pair of traversal zones must be configured.
To set up a secure traversal zone, configure your VCS Control and VCS Expressway as follows:
1. Go to Configuration > Zones > Zones.
2. Click New.
3. Configure the fields as follows (leave all other fields with default values):
VCS Control VCS Expressway
Name "Traversal zone" for example "Traversal zone" for example
Type Traversal client Traversal server
Username "exampleauth" for example "exampleauth" for example
Password "ex4mpl3.c0m" for example Click Add/Edit local authentication database,
then in the popup dialog click New and enter
the Name ("exampleauth") and Password
("ex4mpl3.c0m") and click Create credential.
H.323 Mode Off Off
SIP section
Mode On On
Port
Transport TLS TLS
Unified
Communications
services
TLS verify mode On On
TLS verify subject
name
7001 7001
Yes Yes
Not applicable Enter the name to look for in the traversal
client's certificate (must be in either the Subject
Common Name or the Subject Alternative
Name attributes). If there is a cluster of traversal
clients, specify the cluster name here and
ensure that it is included in each client's
certificate.
Media encryption
mode
Authentication section
Cisco VCS Administrator Guide (X8.1.1) Page 74of 507
Force encrypted Force encrypted
Page 75
Unified Communications
VCS Control VCS Expressway
Configuring mobile and remote accesson VCS
Authentication
policy
Location section
Peer 1 address Enter the FQDN of the VCS
Peer 2...6 address Enter the FQDNs of additional peers
Do not check credentials Do not check credentials
Expressway.
Note that if you use an IP address
(not recommended), that address
must be present in the VCS
Expressway server certificate.
if it is a cluster of VCS Expressways.
Not applicable
Not applicable
Note that you should enable Unified Communications services on one traversal zone only per VCS.
4. Click Create zone.
Checking the status of Unified Communications services
You can check the status of the unified communications services on both VCS Control and VCS
Expressway.
1. Go to Status > Unified Communications.
2. Review the list and status of domains, zones and (VCS Control only) Unified CM and IM&P servers.
Any configuration errors will be listed along with links to the relevant configuration page from where you
can address the issue.
Additional configuration
Configuring the HTTP server allow list (whitelist) on VCS Control
Jabber client endpoints may need to access additional web services inside the enterprise. This requires an
"allow list" of servers to be configured to which the VCS will grant access for HTTP traffic originating from
outside the enterprise.
The features and services that may be required, and would need whitelisting, include:
Cisco VCS Administrator Guide (X8.1.1) Page 75of 507
Page 76
Unified Communications
Configuring mobile and remote accesson VCS
n Visual Voicemail
n Jabber Update Server
n Custom HTML tabs / icons
n Directory Photo Host
The IP addresses of all discovered Unified CM nodes (that are running the CallManager or TFTP service) and
IM&P nodes are added automatically to the allow list and cannot be deleted . Note, however, that they are not
displayed on the HTTP server allow list page.
To configure the set of addresses to which HTTP access will be allowed:
1. On VCS Control, go to Configuration > Unified Communications > Configuration.
2. Click HTTP server allow list.
3. Configure the hostnames or IP addresses of an HTTP server that a Jabber client located outside of the
enterprise is allowed to access.
Access is granted if the server portion of the client-supplied URI matches one of the names entered here,
or if it resolves via DNS lookup to a specified IP address.
Cisco VCS Administrator Guide (X8.1.1) Page 76of 507
Page 77
Protocols
This section provides information about how to configure the VCS to support the SIP and H.323 protocols.
About H.323 78
Configuring H.323 79
About SIP 81
Configuring SIP 84
Configuring domains 88
Configuring SIP and H.323 interworking 90
Cisco VCS Administrator Guide (X8.1.1) Page 77of 507
Page 78
Protocols
About H.323
About H.323
The VCS supports the H.323 protocol: it is an H.323 gatekeeper.
It can 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 (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 order to 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 (Configuration > Protocols > H.323).
Cisco VCS Administrator Guide (X8.1.1) Page 78of 507
Page 79
Protocols
Configuring H.323
Configuring H.323
The H.323 page (Configuration > Protocols > H.323) is used to configure the H.323 settings on the VCS,
including:
n whether H.323 is enabled or not
n H.323 gatekeeper settings
n whether to insert the prefix of the ISDN gateway into the caller's E.164 number presented on the
destination endpoint
The configurable options are:
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
Call
signaling
TCP port
Call
signaling
port range
start and
end
Registration
conflict
mode
The listening port for H.323
UDP registrations. Default is
1719.
The listening port for H.323 call
signaling. Default is 1720.
Specifies the lower port in the
range used by H.323 calls after
they are established. Default is
15000.
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.
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.
The call signaling port range must be great enough to support all
the required concurrent calls.
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.
Note that in a cluster a registration conflict is only detected if the
registration requests are received by the same peer.
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.
Cisco VCS Administrator Guide (X8.1.1) Page 79of 507
Some older endpoints do not support the ability to periodically reregister 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.
Page 80
Protocols
Field Description Usage tips
Configuring H.323
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.
Auto
discover
Determines whether it will
respond to Gatekeeper
Discovery Requests sent out by
endpoints. The default is On.
Caller ID Specifies whether the prefix of
the ISDN gateway is inserted
into the caller's E.164 number
presented on the destination
endpoint.
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.
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.
Including the prefix allows the recipient to directly return the call.
Cisco VCS Administrator Guide (X8.1.1) Page 80of 507
Page 81
Protocols
About SIP
About SIP
The VCS supports the SIP protocol. It can act 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:
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. The AOR is the alias through which the endpoint can be contacted; it is a SIP URI and
always takes the form username@domain.
When a call is received for that AOR, the SIP registrar refers to the record to find its corresponding endpoint.
(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 registrar only accepts registrations for domains for which it is authoritative. The VCS can act as a SIP
registrar for up to 200 domains. 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 against that domain. Note that the VCS will also accept registration requests where the
domain portion of the AOR is either the FQDN or the IP address of the VCS. Whether or not the VCS accepts
a registration request depends on its registration control settings.
In a Unified Communications deployment, endpoint registration for SIP devices may be provided by Unified
CM. In this scenario, the VCS provides secure firewall traversal and line-side support for Unified CM
registrations. When configuring domains, you must select the system - either Unified CM or VCS to provide
registration services for each domain.
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.
Cisco VCS Administrator Guide (X8.1.1) Page 81of 507
Page 82
Protocols
About SIP
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.
Registration refresh intervals
Depending on the typical level of active registrations on your system, you may want to configure the
Standard registration refresh strategy to Variable and set the refresh intervals as follows:
Active registrations Minimum refresh interval Maximum refresh interval
1–100 45 60
101–500 150 200
501–1000 300 400
1000–1500 450 800
1500+ 750 1000
If you want to ensure registration resiliency, use SIP outbound registrations as described below.
SIP registration resiliency
The VCS supports multiple client-initiated connections (also referred to as "SIP Outbound") as outlined in
RFC 5626.
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.
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 behavior as 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 the VCS, it 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 signaling must follow a specified path to successfully traverse the
firewall. For more information about path headers, see RFC 3327.
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:
Cisco VCS Administrator Guide (X8.1.1) Page 82of 507
Page 83
Protocols
About SIP
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.
If your network is set up to proxy registration requests, we recommend that you disable GRUU on the VCS
systems that are acting as a Registrar for those proxied requests. If GRUU is left enabled, Presence may not
work properly for the proxy registered endpoints.
GRUU can only be disabled via the CLI (xConfiguration SIP GRUU Mode: Off).
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.
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.
Cisco VCS Administrator Guide (X8.1.1) Page 83of 507
Page 84
Protocols
Configuring SIP
Configuring SIP
The SIP page (Configuration > Protocols > SIP) is used to configure the SIP settings on the VCS,
including:
n SIP functionality and SIP-specific transport modes and ports
n certificate revocation checking modes for TLS connections
n registration controls for standard and outbound registrations
n authentication controls for delegated credential checking
SIP functionality and SIP-specific transport modes and ports
This section contains the basic settings for enabling SIP functionality and for configuring the various SIPspecific transport modes and ports. The configurable options are:
Field Description Usage tips
SIP mode Enables and disables SIP functionality (SIP registrar and
SIP proxy services) on the VCS. Default is On.
SIP protocols
and ports
TCP outbound
port start / end
Session
refresh
interval
Minimum
session
refresh
interval
The VCS supports SIP over UDP, TCP and TLS transport
protocols. Use the Mode and Port settings for each
protocol to configure whether or not incoming and
outgoing connections using that protocol are supported,
and if so, the ports on which the VCS listens for such
connections.
By default UDP is Off, and TCP and TLS are On. The
default ports are:
n UDP port: 5060
n TCP port: 5060
n TLS port: 5061
The range of ports the VCS uses when TCP and TLS
connections are established. The default range is 25000
to 29999.
The maximum time allowed between session refresh
requests for SIP calls. Default is 1800 seconds.
The minimum value the VCS will negotiate for the session
refresh interval for SIP calls. Default is 500 seconds.
This mode must be enabled to use
either the Presence Server or the
Presence User Agent.
At least one of the transport
protocols must be set to a Mode of
On for SIP functionality to be
supported.
The range must be sufficient to
support all required concurrent
connections.
For further information see the
definition of Session-Expires in RFC
4028.
For further information see the
definition of Min-SE header in RFC
4028.
Certificate revocation checking modes
This section controls the certificate revocation checking modes for SIP TLS connections. The configurable
options are:
Cisco VCS Administrator Guide (X8.1.1) Page 84of 507
Page 85
Protocols
Field Description Usage tips
Configuring SIP
Certificate
revocation
checking
mode
Use OCSP Controls whether the Online Certificate Status Protocol
Use CRLs Controls whether Certificate Revocation Lists (CRLs) are
Allow CRL
downloads
from CDPs
Fallback
behavior
Controls whether revocation checking is performed for
certificates exchanged during SIP TLS connection
establishment.
(OCSP) may be used to perform certificate revocation
checking.
used to perform certificate revocation checking.
Controls whether the download of CRLs from the CDP
URIs contained in X.509 certificates is allowed.
Controls the revocation checking behavior if the
revocation status cannot be established, for example if
the revocation source cannot be contacted.
Treat as revoked: treat the certificate as revoked (and
thus do not allow the TLS connection).
Treat as not revoked: treat the certificate as not revoked.
Default: Treat as not revoked
We recommend that revocation
checking is enabled.
To use OCSP, the X.509 certificate
to be checked must contain an
OCSP responder URI.
CRLs can be used if the certificate
does not support OCSP.
CRLs can be loaded manually onto
the VCS, downloaded
automatically from preconfigured
URIs (see Managing certificate
revocation lists (CRLs) [p.288]), or
downloaded automatically from a
CRL distribution point (CDP) URI
contained in the X.509 certificate.
Treat as not revoked ensures that
your system continues to operate in
a normal manner if the revocation
source cannot be contacted,
however it does potentially mean
that revoked certificates will be
accepted.
Registration controls
This section contains the registration controls for standard and outbound SIP registrations. The configurable
options are:
Cisco VCS Administrator Guide (X8.1.1) Page 85of 507
Page 86
Protocols
Field Description Usage tips
Configuring SIP
Standard
registration
refresh
strategy
Standard
registration
refresh
minimum
Standard
registration
refresh
maximum
The method used to generate the SIP registration expiry
period (the period within which a SIP endpoint must reregister to prevent its registration expiring) for standard
registrations.
Maximum: uses the lesser of the configured Maximum
refresh value and the value requested in the registration.
Variable: generates a random value between the
configured Minimum refresh value and the lesser of the
configured Maximum refresh value and the value
requested in the registration.
The default is Maximum.
The minimum allowed value for a SIP registration refresh
period for standard registrations. Requests for a value
lower than this will result in the registration being rejected
with a 423 Interval Too Brief response. The default is 45
seconds.
The maximum allowed value for a SIP registration refresh
period for standard registrations. Requests for a value
greater than this will result in a lower value being returned
(calculated according to the Standard registration
refresh strategy). The default is 60 seconds.
The Maximum setting uses the
requested value providing it is
within the specified maximum and
minimum ranges.
The Variable setting calculates a
random refresh period for each
registration (and re-registration)
request in an attempt to continually
spread the load. The VCS never
returns a value higher than what
was requested.
This applies only to endpoints
registered with the VCS. It does not
apply to endpoints whose
registrations are proxied through
the VCS.
See Registration refresh intervals
[p.82]
Outbound
registration
refresh
strategy
Outbound
registration
refresh
minimum
The method used to generate the SIP registration expiry
period for outbound registrations.
Maximum: uses the lesser of the configured Maximum
refresh value and the value requested in the registration.
Variable: generates a random value between the
configured Minimum refresh value and the lesser of the
configured Maximum refresh value and the value
requested in the registration.
The default is Variable.
The minimum allowed value for a SIP registration refresh
period for outbound registrations. Requests for a value
lower than this will result in the registration being rejected
with a 423 Interval Too Brief response. The default is 600
seconds.
These options work in the same
manner as for the Standard
registration refresh strategy.
However, outbound registrations
allow a much higher maximum
value than standard registrations.
This is because standard
registrations use the re-registration
mechanism to keep their
connection to the server alive. With
outbound registrations the keepalive process is handled by a
separate, less resource-intensive
process, meaning that reregistrations (which are more
resource-intensive) can be less
frequent.
Cisco VCS Administrator Guide (X8.1.1) Page 86of 507
Page 87
Protocols
Field Description Usage tips
Configuring SIP
Outbound
registration
refresh
maximum
SIP
registration
proxy mode
The maximum allowed value for a SIP registration refresh
period for an outbound registration. Requests for a value
greater than this will result in a lower value being returned
(calculated according to the Outbound registration
refresh strategy). The default is 3600 seconds.
Specifies how proxied registrations and requests
containing Route Sets are handled when the VCS
receives a registration request for a domain for which it is
not acting as a Registrar.
Off: registration requests are not proxied (but are still
permitted locally if the VCS is authoritative as a Registrar
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.
The default is Off.
See Proxying registration requests
[p.83] for more information.
Authentication controls
This section contains the device authentication controls for enabling delegated credential checking. The
configurable options are:
Field Description Usage tips
Delegated
credential
checking
Controls whether the credential checking of SIP
messages is delegated, via a traversal zone, to another
VCS.
Off: use the relevant credential checking mechanisms
(local database, Active Directory Service or H.350
directory via LDAP) on the VCS performing the
authentication challenge.
On: delegate the credential checking to a traversal client.
The default is Off.
Note that delegated credential
checking must be enabled on both
the traversal server and the
traversal client.
See delegated credential checking
for more information.
Cisco VCS Administrator Guide (X8.1.1) Page 87of 507
Page 88
Protocols
Configuring domains
Configuring domains
The Domains page (Configuration > Domains) lists the SIP domains managed by this VCS.
A 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.
Note that values shown in the Index column correspond to the numeric elements of the %localdomain1%,
%localdomain2%, . . . %localdomain200% pattern matching variables.
You can configure up to 200 domains.
Configuring the supported services for Unified
Communications (VCS Control only)
When the VCS Control has been enabled for Unified Communications mobile and remote access, you must
select the services that each domain will support. The options are:
n SIP registrations and provisioning on VCS: the VCS is authoritative for this SIP domain. The VCS
acts as a SIP registrar and Presence Server for the domain, and accepts registration requests for any SIP
endpoints attempting to register with an alias that includes this domain. The default is On.
n SIP registrations and provisioning on Unified CM: endpoint registration, call control and provisioning
for this SIP domain is serviced by Unified CM. The VCS acts as a Unified Communications gateway to
provide secure firewall traversal and line-side support for Unified CM registrations. The default is Off.
n IM and Presence services on Unified CM: instant messaging and presence services for this SIP domain
are provided by the Unified CM IM and Presence service. The default is Off.
Configuring delegated credential checking (VCS Expressway
only)
If you have enabled delegated credential checking (Configuration > Protocols > SIP), you need to specify
the traversal zone to use when delegating credential checks for SIP messages for this domain. This only
applies to the SIP domains for which VCS is acting as the service provider and SIP registrar.
You can specify a different zone for each SIP domain, if required.
Choose Do not delegate if you want to continue to use this VCS Expressway to perform the credential
checking.
Testing the credential checking service
To verify whether the VCS to which credential checking has been delegated is able to receive messages and
perform the relevant authentication checks:
1. Go to Configuration > Domains.
2. Select the relevant domains.
3. Click Test credential checking service.
The system displays a Results section and reports whether the receiving VCS can be reached over the
traversal zone and, additionally, if it is able to perform credential checking for both NTLM and SIP digest
type challenges.
Cisco VCS Administrator Guide (X8.1.1) Page 88of 507
Page 89
Protocols
Configuring domains
If you are not using NTLM authentication in your video network, and thus the receiving VCS is not
configured with a connection to an Active Directory Service, then the NTLM check will be expected to
fail.
Cisco VCS Administrator Guide (X8.1.1) Page 89of 507
Page 90
Protocols
Configuring SIP and H.323 interworking
Configuring SIP and H.323 interworking
The Interworking page (Configuration > Protocols > Interworking) lets you configure whether or not the
VCS acts as a gateway between SIP and H.323 calls. The translation of calls from one protocol to the other
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 acts 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 does not act as a SIP–H.323 gateway.
n Registered only: the VCS acts as a SIP–H.323 gateway but only if at least one of the endpoints is locally
registered.
n On: the VCS acts 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 your network 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.
Calls for which the VCS acts as a SIP to H.323 gateway are traversal calls. The VCS always takes the
media for SIP–H.323 interworked calls so that it can independently negotiate payload types on the SIP and
H.323 sides and VCS will re-write these as the media passes.
Also in a SIP SDP negotiation, multiple codec capabilities can be agreed (more than one video codec can be
accepted) and the SIP device is at liberty to change the codec it uses at any time within the call. If this
happens, because VCS is in the media path it will close and open logical channels to the H.323 device as the
media changes (as required) so that media is passed correctly.
Searching by protocol
When searching a zone, the VCS first performs the search using the protocol of the incoming call. If the
search is unsuccessful the VCS may then search the zone again using the alternative protocol, depending on
where the search came from and the Interworking mode. Note that the zone must also be configured with
the relevant protocols enabled (SIP and H.323 are enabled on a zone by default).
n If the request has come from a neighboring system and Interworking mode is set to Registered only, the
VCS searches the Local Zone using both protocols, and all other zones using the native 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
searches the Local Zone and all external zones using both protocols.
Enabling SIP endpoints to dial H.323 numbers
SIP endpoints can only make calls in the form of URIs — such as name@domain. If the caller does not
specify a domain when placing the call, the SIP endpoint automatically appends 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 will not be able to locate the alias 123@domain and the call
will fail. The solutions are to either:
Cisco VCS Administrator Guide (X8.1.1) Page 90of 507
Page 91
Protocols
Configuring SIP and H.323 interworking
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.
See the pre-search transforms section for information about how to configure pre-search transforms, and
the stripping @domain for dialing to H.323 numbers section for an example of how to do this.
Cisco VCS Administrator Guide (X8.1.1) Page 91of 507
Page 92
Registration control
This section provides information about the pages that appear under the Configuration > Registration
menu.
About registrations 93
About Allow and Deny Lists 97
Configuring Registration Policy to use an external service 99
Cisco VCS Administrator Guide (X8.1.1) Page 92of 507
Page 93
Registration control
About registrations
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 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.
You can also control some protocol-specific behavior, including:
n the Registration conflict mode and Auto discover settings for H.323 registrations
n the SIP registration proxy mode for SIP registrations
For specific information about how registrations are managed across peers in a cluster, see the Sharing
registrations across peers [p.166] section.
In a Unified Communications deployment, endpoint registration for SIP devices may be provided by Unified
CM. In this scenario, the VCS provides secure firewall traversal and line-side support for Unified CM
registrations. When configuring domains, you must select the system - either Unified CM or VCS to provide
registration services for each domain.
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. Traversalenabled 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
Cisco VCS Administrator Guide (X8.1.1) Page 93of 507
Page 94
Registration control
About registrations
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.
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 (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 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.
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. See Configuring Registration Policy to use an external service
[p.99].
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:
Cisco VCS Administrator Guide (X8.1.1) Page 94of 507
Page 95
Registration control
About registrations
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.
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.
H.350 directory authentication and registrations
If the VCS is using an H.350 directory service to authenticate registration requests, the Source of aliases
for registration setting is used to determine which aliases the endpoint is allowed to attempt to register with.
See Using an H.350 directory service lookup via LDAP [p.120] for more information.
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 (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 behavior can be changed but only via the CLI by using the
command xConfiguration SIP Registration Call Remove.
Cisco VCS Administrator Guide (X8.1.1) Page 95of 507
Page 96
Registration control
About registrations
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.
The frequency of re-registrations is determined by the Registration expire delta setting for SIP
(Configuration > Protocols > SIP) and the Time to live setting for H.323 (Configuration > Protocols >
H.323).
Cisco VCS Administrator Guide (X8.1.1) Page 96of 507
Page 97
Registration control
About Allow and Deny Lists
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 [p.94] page) to Allow List or Deny List and then to include any one of
the endpoint’s aliases on the Allow List or the 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 (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 List for 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
Description An optional free-form description
of the entry.
Pattern
type
The way in which the Pattern
string must match the alias.
Options are:
Exact: the alias must match the
pattern string exactly.
Prefix: the alias must begin with
the pattern string.
Suffix: the alias must end with
the pattern string.
Regex: the pattern string is a
regular expression.
You can test whether a pattern matches a particular alias by
using the Check pattern tool (Maintenance > Tools > Check
pattern).
Pattern
string
Cisco VCS Administrator Guide (X8.1.1) Page 97of 507
The pattern against which an
alias is compared.
Page 98
Registration control
About Allow and Deny Lists
Configuring the registration Deny List
The Registration Deny List page (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 List for 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
Description An optional free-form description
of the entry.
Pattern
type
Pattern
string
The way in which the Pattern
string must match the alias.
Options are:
Exact: the alias must match the
pattern string exactly.
Prefix: the alias must begin with
the pattern string.
Suffix: the alias must end with
the pattern string.
Regex: the pattern string is a
regular expression.
The pattern against which an
alias is compared.
You can test whether a pattern matches a particular alias by
using the Check pattern tool (Maintenance > Tools > Check
pattern).
Cisco VCS Administrator Guide (X8.1.1) Page 98of 507
Page 99
Registration control
Configuring Registration Policyto use an external service
Configuring Registration Policy to use an
external service
To configure Registration Policy to refer all registration restriction policy decisions out to an external service:
1. Go to Configuration > Registration > Configuration.
2. Select a Restriction policy of Policy service.
3. Configure the fields as follows:
Field Description Usage tips
Protocol The protocol used to connect to the policy
service.
The default is HTTPS.
Certificate
verification
mode
HTTPS
certificate
revocation list
(CRL)
checking
Server
address 1 - 3
When connecting over HTTPS, this setting
controls whether the certificate presented by
the policy server is verified.
If On, for the VCS to connect to a policy server
over HTTPS, the VCS must have a root CA
certificate loaded that authorizes that server’s
server certificate. Also the certificate's Subject
Common Name or Subject Alternative Name
must match one of the Server address fields
below.
Enable this option if you want to protect
certificate checking using CRLs and you have
manually loaded CRL files, or you have
enabled automatic CRL updates.
Enter the IP address or Fully Qualified Domain
Name (FQDN) of the server hosting the service.
You can specify a port by appending :<port>
to the address.
The VCS automatically supports HTTP to
HTTPS redirection when communicating
with the policy service server.
The VCS’s root CA certificates are loaded
via (Maintenance > Security certificates
> Trusted CA certificate).
Go to Maintenance > Security
certificates > CRL management to
configure how the VCS uploads CRL files.
If an FQDN is specified, ensure that the
VCS has an appropriate DNS
configuration that allows the FQDN to be
resolved.
For resiliency, up to three server
addresses can be supplied.
Path Enter the URL of the service on the server.
Status path The Status path identifies the path from where
the VCS can obtain the status of the remote
service.
The default is 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.
Cisco VCS Administrator Guide (X8.1.1) Page 99of 507
The policy server must supply return status
information, see Policy server status and
resiliency [p.338].
The maximum plaintext length is 30
characters (which is subsequently
encrypted).
Page 100
Registration control
Configuring Registration Policyto use an external service
Field Description Usage tips
Default CPL This is the fallback CPL used by the VCS if the
service is not available.
You can change it, for example, to redirect
to an answer service or recorded
message.
For more information, see Default CPL for
policy services [p.492].
4. Click Save.
The VCS should connect to the policy service server and start using the service for Registration Policy
decisions.
Any connection problems will be reported on this page. Check the Status area at the bottom of the page
and check for additional information messages against the Server address fields.
Cisco VCS Administrator Guide (X8.1.1) Page 100 of 507
Loading...