TANDBERG D14049.04 Administrator's Manual

March 2010 Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

Introduction The TANDBERG VCS................................................................. 8 Overview........................................................................... 8 VCS and the TANDBERG Total Solution............................... 8 VCS base applications....................................................... 9 VCS Control................................................................. 9 VCS Expressway™....................................................... 9 Standard features ........................................................... 10 Optional features ............................................................ 11 FindMe™................................................................... 11 Device Provisioning.................................................... 11 Dual Network Interfaces............................................. 11 What’s new in this version?.............................................. 12 Usability enhancements............................................. 12 FindMe™ / User Policy option key............................... 12 Subzone registration policies...................................... 12 Zone configuration..................................................... 12 Conference Factory generated alias ranges................. 12 Advanced Media Gateway support.............................. 12 Far end camera control interworking........................... 13 G.729 support for interworked calls............................ 13 Advanced account security......................................... 13 CRL checking for TLS connections to LDAP servers..... 13 HTTPS client certificate validation............................... 13 Clustering.................................................................. 13 Hardware failure warnings.......................................... 13 Auditor account access level...................................... 13 Remote account authentication over LDAP.................. 13 Starter Pack.............................................................. 13 Using this guide..................................................................... 14 Using the VCS....................................................................... 15 Web interface.................................................................. 15 Installation and initial configuration............................ 15 Using the web interface............................................. 15 Provisioning..................................................................... 29 Warnings......................................................................... 30 Hardware........................................................................ 30 Event Log........................................................................ 31 Configuration Log............................................................. 39 System configuration System configuration............................................................. 41 System administration..................................................... 41 About the system name ............................................ 41 About administration access settings ........................ 41 Ethernet.......................................................................... 41 About Ethernet speed................................................ 41 IP.................................................................................... 42 About IP protocols..................................................... 42 IPv4 to IPv6 gatewaying (interworking).................. 42 External LAN interface............................................... 42 About IP routes (static routes).................................... 42 About LAN configuration............................................. 42 About Dual Network Interfaces................................... 42 About static NAT........................................................ 42 Quality of Service (QoS)................................................... 43 Supported mechanisms............................................. 43 DNS................................................................................ 43 About DNS servers.................................................... 43 About DNS settings................................................... 43 Time............................................................................... 44 About the NTP server................................................. 44 VCS time display........................................................ 44 Login page...................................................................... 44 SNMP............................................................................. 45 About SNMP.............................................................. 45 External manager............................................................ 45 About external managers........................................... 45 Supported browsers................................................... 15 Page features and layout............................................ 16 Command line interface (CLI)............................................17 Installation and initial configuration.............................17 Command types..........................................................17 How CLI commands are shown in this guide.................17 Text entry.........................................................................17 Supported characters.................................................17 Case sensitivity..........................................................17 Overview and status Overview page....................................................................... 19 Status................................................................................... 20 System information.......................................................... 20 Ethernet status................................................................ 20 IP status......................................................................... 21 Resource usage............................................................... 21 Registrations by device.................................................... 22 Registrations by alias....................................................... 22 Registration history.......................................................... 23 Registration details.......................................................... 23 Calls............................................................................... 24 Call history...................................................................... 24 Call summary.................................................................. 24 Searches......................................................................... 25 Search history................................................................. 25 Search details................................................................. 25 Local Zone...................................................................... 26 Zones............................................................................. 26 Links............................................................................... 27 Pipes.............................................................................. 27 TURN relays..................................................................... 28 Presence......................................................................... 28 OCS Relay....................................................................... 29 TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance What’s in this manual?

Configuration............................................................. 45 Logging........................................................................... 46 About Event Log levels............................................... 46 Setting the Event Log level......................................... 46 About remote logging................................................. 46 Enabling remote logging............................................. 46 VCS configuration H.323................................................................................... 48 H.323 overview............................................................... 48 About H.323 on the VCS............................................ 48 Using the VCS as an H.323 gatekeeper...................... 48 H.323 endpoint registration............................................. 48 Configuring H.323............................................................ 49 Enabling H.323.......................................................... 49 Configuring H.323 ports............................................. 49 Registration conflict mode.......................................... 49 Time to live................................................................ 49 Call time to live.......................................................... 49 Auto discover............................................................. 49 Caller ID.................................................................... 49 SIP........................................................................................ 50 SIP overview.................................................................... 50 About SIP on the VCS................................................. 50 Using the VCS as a SIP registrar................................. 50 Using the VCS as a SIP Presence Server..................... 50 Using the VCS as a SIP proxy server........................... 50 Proxying registration requests.................................... 50 SIP endpoint registration............................................ 50 Movi v2.0 (or later) clients.................................... 50 Configuring SIP................................................................ 51 Enabling SIP.............................................................. 51 SIP registration expiry................................................ 51 SIP registration proxy mode........................................ 51 Zones and neighbors Introduction........................................................................... 62 Local Zone and subzones....................................................... 63 Configuring the Local Zone and its subzones..................... 63 Bandwidth management............................................. 63 Local Zone searches.................................................. 63 Traversal Subzone........................................................... 64 What are traversal calls?............................................ 64 Configuring the Traversal Subzone ports..................... 64 Zones................................................................................... 65 About zones.................................................................... 65 Neighbor zone................................................................. 65 Traversal client zone........................................................ 65 Traversal server zone....................................................... 65 ENUM zone...................................................................... 66 DNS zone........................................................................ 66 Default Zone................................................................... 66 Zone configuration........................................................... 67 TLS certificate verification of neighbor systems .......... 67 Connections to neighbor systems over TCP and TLS.... 67 SIP authentication trust............................................. 67 Configuring zones............................................................ 68 Configuring neighbor zones.............................................. 68 Configuring traversal client zones..................................... 69 Configuring traversal server zones.................................... 70 Configuring ENUM zones...................................................71 Configuring DNS zones......................................................71 Zone configuration: advanced settings.............................. 72 Zone configuration: pre-configured profile settings............. 75 Dial plans.............................................................................. 76 Structuring your dial plan................................................. 76 Flat dial plan.............................................................. 76 Structured dial plan................................................... 76 Hierarchical dial plan................................................. 76 SIP protocols and ports.............................................. 51 Session timers.......................................................... 51 SIP device interoperability.......................................... 51 SIP domains.................................................................... 51 Interworking.......................................................................... 52 Configuring interworking................................................... 52 H.323 <-> SIP interworking mode............................... 52 Enabling SIP endpoints to dial H.323 numbers............ 52 Registration control............................................................... 53 Registration overview....................................................... 53 Endpoint registration.................................................. 53 Registrations on a VCS Expressway............................ 53 MCU, gateway and Content Server registration............ 53 Finding a VCS with which to register............................ 54 SIP...................................................................... 54 H.323................................................................. 54 Preventing automatic registrations........................ 54 Device authentication...................................................... 55 Device authentication using LDAP.................................... 56 Configuring the LDAP server directory......................... 56 Configuring LDAP server settings ............................... 56 Authentication using a local database.............................. 57 Authenticating with external systems................................ 57 Registering aliases.......................................................... 58 About alias registration.............................................. 58 Attempts to register using an existing alias................. 58 Blocking registrations................................................ 58 Allow and Deny Lists........................................................ 59 About Allow and Deny Lists........................................ 59 Activating use of Allow or Deny Lists........................... 59 Removing existing registrations.................................. 59 Using the Allow and Deny Lists................................... 60 TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance What’s in this manual?

Clustering and peers Clustering overview................................................................ 78 About clustering.............................................................. 78 About the configuration master................................... 78 Cluster configuration.............................................................. 79 Configuring clusters......................................................... 79 Setting up a cluster.................................................... 79 Maintaining a cluster.................................................. 79 Setting configuration for the cluster...................... 79 Adding and removing peers from a cluster............. 79 Cluster name....................................................... 79 Changing the master peer.................................... 79 Monitoring the status of the cluster...................... 79 Which configuration is not replicated?............................... 80 Troubleshooting cluster replication problems.................... 80 Managing clusters and peers................................................. 81 Sharing registrations across peers................................... 81 Sharing bandwidth across peers....................................... 81 Upgrades and downgrades............................................... 81 Backup and restore.......................................................... 81 Clustering and FindMe..................................................... 82 Clustering and Presence.................................................. 82 Clustering and TMS.......................................................... 82 Cluster Subzone.............................................................. 83 Neighboring the local VCS to another VCS cluster.............. 83 Call processing Introduction........................................................................... 85 Search process............................................................... 85 Dialing by address types........................................................ 86 About the different address types.................................... 86 Dialing by IP address....................................................... 86 Endpoints registered to a VCS Expressway.................. 86 Dialing by H.323 ID or E.164 alias.................................... 86 Configuring Call Policy using a CPL script........................ 102 Viewing existing CPL script....................................... 102 About CPL XSD files................................................. 102 Uploading a CPL script............................................. 102 Deleting an existing CPL script................................. 102 Routing calls via the Advanced Media Gateway..................... 103 VCS and the Advanced Media Gateway........................... 103 Configuring the VCS to use the AM gateway............... 103 Usage features and limitations................................. 103 Controlling which calls to route via the AM gateway... 103 Configuring AM gateway policy rules.......................... 104 URI dialing........................................................................... 105 Overview....................................................................... 105 URI dialing without DNS........................................... 105 URI dialing via DNS.................................................. 105 Enabling URI dialing via DNS.......................................... 105 URI resolution process using DNS.................................. 106 URI dialing via DNS for outgoing calls..............................107 URI dialing process...................................................107 Adding and configuring DNS zones.............................107 Configuring search rules for DNS zones.....................107 Configuring DNS servers...........................................107 URI dialing via DNS for incoming calls............................. 108 Types of DNS records required................................. 108 Incoming call process.............................................. 108 SRV record format .................................................. 108 Configuring H.323 SRV records................................. 108 Configuring SIP SRV records..................................... 108 Example DNS record configuration............................ 109 URI dialing and firewall traversal..................................... 109 Recommended configuration.................................... 109 ENUM dialing....................................................................... 110 ENUM dialing process.................................................... 110 Enabling ENUM dialing................................................... 110 Dialing by H.323 or SIP URI.............................................. 86 Dialing by ENUM.............................................................. 86 Hop counts............................................................................ 87 About hop counts............................................................ 87 Configuring hop counts.................................................... 87 Searches and transforms....................................................... 88 Overview of searches and transforms............................... 88 Zone searching and transform process....................... 88 Pre-search transforms..................................................... 89 Pre-search transform process.................................... 89 Configuring pre-search transforms.............................. 90 Search configuration ....................................................... 91 Calls to unknown IP addresses................................... 91 About unregistered endpoints............................... 91 Calls to Unknown IP addresses settings................ 91 Recommended configuration for firewall traversal .91 Fallback alias............................................................ 91 Zone searching and zone transforms................................ 92 Examples........................................................................ 94 Stripping @domain for dialing to H.323 numbers......... 94 Examples........................................................................ 95 Transforms for alphanumeric H.323 ID dial strings...... 95 Combining match types and priorities......................... 96 Always query a zone with original alias (no transforms).96 Configuring a zone for incoming calls only................... 96 Filter queries to a zone without transforming............... 97 Allowing calls to IP addresses only if they come from known zones.............................................................. 97 Query a zone for original and transformed alias........... 98 Query a zone for two or more transformed aliases....... 99 Call Policy........................................................................... 100 Call Policy and authentication......................................... 100 Enabling Call Policy........................................................ 101 Configuring basic Call Policy using the web interface....... 101 TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance What’s in this manual?

ENUM dialing for outgoing calls...................................... 111 Prerequisites........................................................... 111 Process................................................................... 111 ENUM dialing for outgoing calls...................................... 112 Adding and configuring ENUM zones......................... 112 Configuring matches for ENUM zones........................ 112 Configuring transforms for ENUM zones.................... 112 Configuring DNS servers.......................................... 112 ENUM dialing for incoming calls...................................... 113 Prerequisites........................................................... 113 About DNS domains for ENUM.................................. 113 Configuring DNS NAPTR records............................... 113 Call configuration................................................................. 114 Call routed mode........................................................... 114 Call loop detection mode............................................... 114 Call IDs, Serial Numbers and Tags........................................ 115 Identifying calls............................................................. 115 Disconnecting calls.............................................................. 116 Limitations when disconnecting SIP calls........................ 116 Bandwidth control Bandwidth control overview.................................................. 118 Bandwidth control on the VCS........................................ 118 Example network deployment......................................... 118 Subzones............................................................................ 119 About subzones............................................................. 119 Subzone registration policy....................................... 119 About the Traversal Subzone.......................................... 119 Traversal calls......................................................... 119 About the Default Subzone............................................. 119 Default links between subzones..................................... 119 Configuring subzones and membership rules................... 120 Applying bandwidth limitations to subzones.................... 121 Bandwidth consumption of traversal calls................. 121 Configuring the VCS as a traversal client............................... 135 Configuring the VCS as a traversal server............................. 136 Adding and configuring a traversal server zone................ 136 Configuring traversal for endpoints................................. 136 Configuring traversal server ports................................... 137 Configuring the VCS as a TURN server.................................. 138 TURN services............................................................... 138 About ICE................................................................ 138 About TURN............................................................. 138 TURN relay server.................................................... 138 Capabilities and limitations...................................... 138 Configuring TURN services....................................... 138 Applications Conference Factory.............................................................. 140 Configuration................................................................. 140 Presence..............................................................................141 Presence Server.............................................................141 Presence User Agent (PUA)............................................. 142 Aggregation of presence information........................ 142 FindMe presence............................................... 142 Registration refresh period....................................... 142 Configuring Presence..................................................... 143 Enabling and disabling Presence Services................. 143 Presence Server expiration times............................. 143 Viewing presence status................................................ 144 Publishers............................................................... 144 Presentities ............................................................ 144 Subscribers............................................................. 144 OCS Relay........................................................................... 145 Configuring OCS Relay.................................................... 145 Viewing OCS Relay status............................................... 145 FindMe™............................................................................. 146 Overview....................................................................... 146 Links................................................................................... 122 Creating and editing links............................................... 122 Default links.................................................................. 122 Pipes.................................................................................. 123 Creating and editing pipes.............................................. 123 Applying pipes to links................................................... 124 Default bandwidth and downspeeding................................... 125 Bandwidth control examples................................................ 126 Example without a firewall.............................................. 126 Example with a firewall................................................... 127 VCS Expressway subzone configuration..................... 127 VCS Control subzone configuration........................... 127 Firewall traversal Firewall traversal overview.................................................... 129 About Expressway™....................................................... 129 VCS as a firewall traversal client..................................... 129 VCS as a firewall traversal server.................................... 129 Quick guide to VCS traversal client - server configuration....... 130 Firewall traversal protocols and ports................................... 131 Expressway process...................................................... 131 H.323 firewall traversal protocols................................... 131 SIP firewall traversal protocols....................................... 131 Ports for initial connections from traversal clients........... 132 Assent ports................................................................. 132 SIP ports....................................................................... 132 H.460.18/19 ports........................................................ 132 TURN ports.................................................................... 132 Ports for connections out to the public internet............... 132 Firewall traversal and authentication.................................... 133 Authentication and NTP.................................................. 133 Other issues........................................................................ 134 Firewall traversal and Dual Network Interfaces................ 134 Firewall configuration..................................................... 134 TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance What’s in this manual?

What is FindMe?...................................................... 146 How are devices specified?...................................... 146 Process overview..................................................... 146 Who must do what before FindMe can be used?........ 146 Recommendations when deploying FindMe............... 146 Enabling FindMe on the VCS............................................147 Configuring FindMe...................................................147 Caller ID.............................................................147 Device creation message....................................147 Searching for FindMe accounts.......................................147 Principal devices.............................................................147 TANDBERG FindMe™ user guide........................................... 148 About FindMe................................................................ 148 FindMe user accounts.............................................. 148 Individual versus group FindMe ................................ 148 Accessing the FindMe home page.................................. 148 Configuring your FindMe user account............................. 149 FindMe home page.................................................. 149 Defining device details............................................. 150 Defining location details........................................... 151 Provisioning (Starter Pack)................................................... 152 Configuration................................................................. 152 TMS Agent.......................................................................... 153 Overview....................................................................... 153 FindMe™................................................................. 153 Device Provisioning.................................................. 153 TMS Agent account passwords................................. 153 Maintenance Upgrading software components.......................................... 155 Overview....................................................................... 155 VCS software components....................................... 155 Prerequisites........................................................... 155 Backing up before upgrading.................................... 155 TLS encryption and CRL checking............................. 165 Root account................................................................. 166 Changing the root account password........................ 166 Accessing the root account over SSH and Telnet....... 166 Resetting passwords..................................................... 166 System administration access............................................. 167 Overview....................................................................... 167 Security considerations............................................ 167 Configuring administration access............................ 167 Administration session timeout................................ 167 Backup and restore............................................................. 168 Creating a backup of your VCS data................................ 168 Restoring a previous backup.......................................... 168 System snapshot................................................................. 169 Creating a system snapshot........................................... 169 Incident reporting.................................................................170 Warning: privacy-protected personal data...................170 What information does the report contain?......................170 Viewing incident reports..................................................171 Sending incident reports manually...................................171 Removing sensitive information from the report.........171 Sending incident reports automatically............................171 Tools....................................................................................172 Check pattern.................................................................172 Locate............................................................................172 Port usage......................................................................173 Local VCS inbound ports...........................................173 Local VCS outbound ports.........................................173 Remote listening ports..............................................173 Restarting, rebooting and shutting down................................174 Restoring default configuration..............................................175 Configuration items reset by DefaultValuesSet level 3......175 Configuration items reset by DefaultValuesSet level 2......176 Password encryption.............................................................178 Upgrading and option keys....................................... 155 Installing and rebooting............................................ 155 Upgrade procedure........................................................ 156 Upgrading using secure copy (SCP/PSCP)................. 156 Downgrade procedure.................................................... 156 Option keys......................................................................... 157 Adding option keys using the web interface..................... 157 Adding option keys using the CLI.................................... 157 Security certificates............................................................. 158 Enabling security........................................................... 158 Trusted CA certificate............................................... 158 Server certificate data.............................................. 158 Advanced account security................................................... 159 Prerequisites........................................................... 159 VCS functionality: changes and limitations................ 159 Enabling advanced account security............................... 159 Login accounts.................................................................... 160 Account authentication configuration.............................. 160 Administrator accounts.................................................. 161 Default administrator account.................................. 161 Additional administrator accounts............................. 161 Administrator password security............................... 161 Maintaining administrator accounts................................ 161 Maintaining user accounts............................................. 162 Creating user accounts............................................ 162 Managing user accounts.......................................... 163 Configuring devices and locations....................... 163 Configuring principal devices.............................. 163 Changing an account's password........................ 163 Administrator and user groups........................................ 164 Configuring administrator groups.............................. 164 Configuring user groups........................................... 164 Account authentication using LDAP................................. 165 Configuring LDAP server settings ............................. 165 TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance What’s in this manual?

Appendices CPL reference...................................................................... 180 Overview of CPL on the VCS........................................... 180 address-switch.............................................................. 180 address .................................................................. 180 field........................................................................ 181 subfield................................................................... 182 otherwise...................................................................... 182 not-present.................................................................... 182 location......................................................................... 183 rule-switch..................................................................... 183 proxy ............................................................................ 184 reject ........................................................................... 184 Unsupported CPL elements............................................ 184 CPL examples................................................................ 185 Call screening of authenticated users....................... 185 Call screening based on alias................................... 185 Call screening based on domain............................... 186 Change of domain name.......................................... 186 Allow calls from locally registered endpoints only...... 187 Block calls from Default Zone and Default Subzone... 187 Restricting access to a local gateway........................ 188 Using the address-switch node........................... 188 Using the taa:rule-switch node............................ 188 Redirecting failed calls based on status code........... 189 Reject attempts to subscribe to a presentity............. 190 Regular expression reference............................................... 191 Pattern variable reference.................................................... 192 VCS port reference.............................................................. 193 DNS configuration................................................................ 196 Overview....................................................................... 196 Verifying the SRV record........................................... 196 Microsoft DNS server..................................................... 196 BIND 8 & 9 ................................................................... 196 LDAP configuration for device authentication......................... 197 About the LDAP databases............................................. 197 Downloading the H.350 schemas................................... 197 Microsoft Active Directory ............................................. 197 Prerequisites .......................................................... 197 Installing the H.350 schemas................................... 197 Adding H.350 objects ............................................. 198 Securing with TLS ................................................... 198 OpenLDAP..................................................................... 199 Prerequisites .......................................................... 199 Installing the H.350 schemas .................................. 199 Adding H.350 objects ............................................. 200 Securing with TLS ................................................... 200 Command reference - xConfiguration.................................... 201 Command reference - xCommand......................................... 248 Command reference - xStatus.............................................. 265 Warnings............................................................................. 284 Bibliography........................................................................ 287 Glossary............................................................................. 289 Legal notices....................................................................... 295 Contact information............................................................. 296 TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance What’s in this manual?

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance The TANDBERG VCS FINDME FIREWALL TRAVERSAL MANAGEMENT SUITE VIDEO COMMUNICATION SERVER CALL CONTROL POLICE NE TWOR K ST AN DA RD S C OM PLI AN T 3G S IP/ H.3 23 , H .3 20 MAN AGED CONCI ERGE IP IS DN THIR D P ART Y V ID EO P RES EN CE N ETW ORK ASSE SSME NT TE LEPR ESEN CE S ERV ER V OIP U NIF IED D IRE CTO RIE S INSTA LLATIO N & CONF IGUR ATION USAG E & ADO PTIO N CLASS SOLU TIO NS SCALA BLE C ARR IER CONFE REN CE ME MULTIPLE MULTIWA Y CONTROL UNITS V.35 Identify Requirements Build the Foundation Deploy the Right Solutions Transform your Organization Make sure your next investment supports your overall communication strategy and is interoperable with all existing and future IT investments. Everything should be easy to implement and even easier to use. Tame the network and centralize call control and management for all video assets. Ensure everything is reliable and scalable. As your deployment strategy grows, your foundation supports you every step of the way. One size does not fit all. Choose the right video endpoints and services to support your end user needs. Deliver the best possible experience while scaling video to everyone in the organization. Enable increased productivity and richer collaboration. Support teleworking initiatives and reduce your carbon footprint. Gain a competitive edge while maximizing ROI. ©2008 XPLANE.com™ FINANCE HEALTHCARE EDUCATION GOVERNMENT MANUFACTURING PUBLIC SAFETY SMALL AND MEDIUM BUSINESS 1 2 3 4 COLLAB ORATIO N WA LL EXECUTIVE DE SKTO P P ERSONAL VI DEO SMALL TEAM ROOM TELEPRES ENCE Multipoint Conferen cing Brid ges Managed and Prof essional Se rvices Stre amin g, Re cordi ng an d Arch iving Gateways a nd IVR Intero perab ility INDUSTRY SOLUTIONS The TANDBERG Total Solution TANDBERG delivers the most comprehensive and reliable total solution of video products in the industry - including telepresence and high definition video, a full portfolio of infrastructure products and MCUs, and the best video management platform available. A TANDBERG solution-based approach means organizations can add new standards-compliant technologies and capabilities, easily and transparently, at any time - with no disruption to the end-user experience. This translates into future-proof investments and an unparalleled video experience for end users and IT professionals alike. PERSONA L LARGE TEAM ROOM EXTENDED ACCESS MOBI LE PC VIDEO COMM UNICATION S UNIFIED FIREWALL TRAVERSAL PROVISIONING DIRECTORIES MONITORING SCHEDULING ROI DIAGNOSTICS VCS and the TANDBERG Total Solution TANDBERG delivers the most comprehensive and reliable total solution of video products in the industry - including telepresence and high definition video, a full portfolio of infrastructure products and MCUs, and the best video management platform available. A TANDBERG solution-based approach means organizations can add new standards-compliant technologies and capabilities, easily and transparently, at any time - with no disruption to the end-user experience. This translates into future-proof investments and an unparalleled video experience for end users and IT professionals alike. The TANDBERG Video Communication Server (VCS) enhances the video experience and provides seamless communication between SIP and H.323 devices utilizing IETF and ITU standards. The VCS is the center of the video communication network, and connects all H.323 and SIP endpoints, infrastructure, and management devices. The VCS provides unrivaled scalability and redundancy to video communications, and is integral to TANDBERG interoperability with unified communications and Voice over IP systems. The VCS can be deployed with either the Control application or the Expressway™ application, with various optional packages including FindMe™, Dual Network Interfaces and Device Provisioning. Overview

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance The TANDBERG VCS VCS Control The VCS Control provides internal video control and administration for all SIP and H.323 devices. It is normally deployed within your wide area network with endpoints that are behind the same firewalls or NAT devices. The VCS Control replaces the need to have separate H.323 gatekeeper, SIP registrar and H.323 - SIP gateway servers. VCS base applications VCS Expressway™ The VCS Expressway provides standards-based firewall traversal for SIP and H.323 devices allowing secure firewall traversal of any firewall or NAT device. As well as all the functionality of a VCS Control, it also provides registration of traversal-enabled devices and can act as a standards-based TURN server. The VCS Expressway is normally deployed outside of your firewall or within the DMZ.

Standard features • 2500 endpoint registrations • H.323 gatekeeper • SIP Proxy/Registrar • SIP Presence Server • SIP Presence User Agent • SIP and H.323 support, including SIP/H.323 gatewaying • IPv4 and IPv6 support, including IPv4/IPv6 gatewaying • QoS tagging • 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 • Automatic downspeeding option for calls that exceed the available bandwidth • URI and ENUM dialing via DNS, enabling global connectivity • Up to 500 non-traversal calls • Up to 100 traversal calls • 1000 external zones with up to 2000 matches • 1000 subzones and supporting up to 3000 membership rules • Flexible zone configuration with prefix, suffix and regex support • Can function as a standalone VCS or be neighbored with other systems such as VCSs, Border Controllers, gatekeepers and SIP proxies • n+1 redundancy, can be part of a cluster of up to 6 VCSs for increased capacity and redundancy • Intelligent Route Director for single number dialing and network failover facilities • Optional endpoint authentication • Control over which endpoints are allowed to register • Call Policy (also known as Administrator Policy) including support for CPL • Can be managed with TANDBERG Management Suite 12.5 or later • AD authentication for administrators of the VCS • Pre-configured defaults for Microsoft Office Communications Server (OCS) 2007 neighbor zones • Pre-configured defaults for Cisco Call Manager neighbor zones • Pre-configured defaults for Nortel Communication Server neighbor zones • Embedded setup wizard using a serial port for initial configuration • System administration using a web interface or RS-232, Telnet, SSH, and HTTPS TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance The TANDBERG VCS

The following features are available on the VCS by the purchase and installation of the appropriate option key: FindMe™ A unique industry solution that gives individual video users a single alias on which they can be contacted regardless of location. Users have the ability to log on to a Web-based interface and control where and how they are contacted. The FindMe feature also includes support for Microsoft Office Communications Server (OCS) 2007, enabling FindMe aliases to register as Microsoft Office Communicator (MOC) clients, and MOC clients to view the presence status of FindMe aliases. Device Provisioning The Device Provisioning option key allows VCS to provision endpoints with configuration information on request and to supply endpoints with phone book information. (Endpoints including TANDBERG Movi v2.0 or later, and E20 v2.1 or later can request to be provisioned.) All configuration and phone book information is managed in TMS, and distributed to the clients through the TMS Agent running on the VCS. The TMS Agent on the VCS also provides TMS with the provisioned client’s status. There is no configuration associated with Device Provisioning on the VCS – it is either on or off, depending on whether or not the option key is installed. See the TMS documentation and the TANDBERG Provisioning Deployment Guide [26]. Dual Network Interfaces Enables the LAN 2 Ethernet port on the VCS Expressway, allowing you to have a secondary IP address for your VCS. This option also includes support for deployments where a VCS Expressway is located behind a static NAT device, allowing it to have separate public and private IP addresses. This configuration is intended for high-security deployments where the VCS Expressway is located in a DMZ between two separate firewalls on separate network segments. Optional features TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance The TANDBERG VCS

The following features have been introduced in version X5.1 of the VCS software: Usability enhancements Many usability improvements have been made, including: • Description fields for configuration items: a free-format description can be specified for the following configuration items: transforms, Allow List and Deny List patterns, search rules, subzone membership rules. When viewing the summary list of these items the description is displayed as a mouse-over tooltip. • Enable and disable configuration items: transforms, search rules and subzone membership rules can be individually enabled and disabled. This makes it easier to make or test configuration changes. Previously, configuration items would have to be deleted and re-created as necessary. The enabled or disabled state is clearly shown on the summary list pages. • "Add suffix" and "add prefix" transform options: new pre- search transform pattern behavior options let you add a prefix or suffix to the matching alias. Previously, regular expressions would have been required to do this. • Consistent create and modify behavior for configuration items: for configuration where multiple items can be defined (for example, Allow List patterns, search rules and so on) the create and modify behavior has been made consistent so that you are always returned to the summary list page after saving your changes. Additionally, new search rules, subzone membership rules, subzones and zones are all created in a single step. Previously you had to specify some of the configuration values when creating the item, and then return to the edit page to specify the remainder of the values. • "Please select" in drop-down fields: when creating configuration items some of the default values presented in drop-down selection fields have been replaced with a "please select" value. This helps prevent potentially undesirable default values being selected by mistake. • Improved filtering options for Event Log and Configuration Log: advanced filtering options let you include or exclude specific words or phrases when filtering the view of the Event Log and the Configuration Log. • OCS Relay status: colored status icons make the difference between the online and offline OCS Relay status more distinct. • Configuration warnings: more warnings are raised for common misconfiguration scenarios, for example if a clustered VCS has H.323 disabled, or if default links are not present. FindMe™ / User Policy option key • The User Policy option key has been renamed as the FindMe™ option key. • "FindMe accounts" and "FindMe groups" are now referred to as "user accounts" and "user groups" respectively. Subzone registration policies • In addition to using Allow Lists and Deny Lists, registrations can be controlled at the subzone level. Each subzone can be configured to allow or deny registrations assigned to it via the subzone membership rules. See the subzones section for more information. • Up to 3000 subzone membership rules (previously 2000) can be configured across all subzones. Zone configuration • TLS authentication: the VCS can perform certificate verification of neighbor zones when communicating over TLS. Mutual authentication can be performed with neighbor VCSs. • TLS default transport type: TLS is the default SIP transport type when setting up new neighbor, traversal client and traversal server zones. • SIP authentication trust: the VCS can be configured to trust incoming SIP messages from specified neighbor zones, rather than challenge them. This applies even if device authentication is enabled on the VCS. • Accept proxied registrations: controls whether proxied SIP registrations routed through a neighbor, traversal client or traversal server zone are accepted. • Nortel Communication Server 1000 zone profile: the VCS can automatically configure the settings required for connections to a Nortel Communication Server 1000. • Separate authentication credentials per traversal client zone: each traversal client zone specifies its own username and password for authentication with the traversal server. This allows a traversal client VCS to connect to one or more service providers. See the zone configuration section for more information. Note that the existing Outbound connection credentials username and password are still used for connections to all other (non traversal server) external systems. Conference Factory generated alias ranges • The upper and lower range limits of the numeric portion of the generated alias can be specified. • The numeric portion of the generated alias will pad with leading zeroes to maintain a constant length, for example a range of 10-999 will generate aliases 010 through 999. Advanced Media Gateway support The Advanced Media Gateway (AM gateway) provides support for transcoding between standard codecs (such as H.264) and Microsoft RT Video to allow high definition calls between Microsoft Office Communicator (MOC) clients and TANDBERG endpoints. • Advanced Media Gateway zone profile: automatically configures the VCS with the zone settings required for connection to an AM gateway. • Policy rules: ability to define policy rules to control whether all or only selected calls to or from MOC clients are diverted through the AM gateway. See VCS and the Advanced Media Gateway for more information. What’s new in this version? TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance The TANDBERG VCS

Far end camera control interworking The VCS supports far end camera control (FECC) when interworking calls between SIP and H.323 endpoints. G.729 support for interworked calls The G.729 codec is supported for interworked calls. Advanced account security An Advanced account security option key enables advanced security features and restrictions for high-security installations. Contact your TANDBERG support representative for more information about this feature. CRL checking for TLS connections to LDAP servers Certificate revocation lists (CRLs) can be uploaded and used to verify certificates presented by an LDAP server to the VCS when forming a TLS connection. See Configuring LDAP server settings for more information. HTTPS client certificate validation • The VCS web server can be configured to request a valid client certificate before establishing an HTTPS session with a client system (typically a web browser). • Client certificate revocation lists can be uploaded and used to verify the client certificate. See Security certificates for more information. Clustering • Improved resilience: cluster configuration replication is more resilient to network delay. • TURN server: relay allocation requests are redirected to other cluster peers if the first VCS's relays are fully allocated. Hardware failure warnings Improved hardware failure detection, warnings and status display. Auditor account access level An Auditor access level can be assigned to administrator accounts and groups. Users with the Auditor privilege can only access the Overview, Event Log and Configuration Log pages. Remote account authentication over LDAP The LDAP server address of the remote directory service can be specified as a DNS SRV record, thus allowing multiple (primary and backup) servers to be specified. Starter Pack The Starter Pack option key is only available as a pre-configured factory setting. It is designed for single box deployments and provides basic device provisioning for registered Movi users, without the need for TMS. It supports device authentication and supplies phone book information to provisioned devices. The Starter Pack includes the following features: • Expressway • FindMe It has the following license restrictions: • 50 registrations • 5 calls (any combination of traversal and non-traversal calls) Note that installing additional call license option keys will have no effect while the Starter Pack option key is present. See Provisioning (Starter Pack) for more information. What’s new in this version? (continued) The TANDBERG VCS TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Using this guide This Administrator Guide is provided to help you make the best use of your TANDBERG VCS. Your approach to this documentation depends on what you want to do and how much you already know. The Administrator Guide has been divided into several sections, each providing different information. In some places information is duplicated between sections to let you have all the relevant information in one place. This document does not have an index. This is intentional; if the Table of contents does not direct you to the information you need, you can use the Find function in Adobe Reader to search the text for keywords. Note that the Administrator Guide describes a fully equipped version of the VCS. Your version may not have all the described extensions installed. Our main objective with this Administrator Guide is to address your goals and needs. Please let us know how well we succeeded! How to use this Administrator Guide Typographical conventions Most configuration tasks on the VCS can be performed by using either the web interface or a command line interface (CLI). This guide describes how to use both methods. Web interface 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. Command line interface (CLI) In this guide, instructions for performing a task using the command line interface (CLI) are shown in the format: • xConfiguration • xCommand These are meant as a reference only. Each command is hyperlinked to the Command reference table at the back of this guide; clicking on the hyperlink will take you to the appropriate section of the table showing all the available sub-elements, parameters and valuespaces for the given command. Note that: • Typing the given xConfiguration path into the CLI will return a list of values currently configured for that element (and sub-elements where applicable). • Typing the given xConfiguration path into the CLI followed by a ? will return information about the usage for that element and sub-elements. • Typing the given xCommand command into the CLI with or without a ? will return information about the usage of that command.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Using the VCS Web interface Installation and initial configuration Full installation and initial configuration instructions for the VCS are contained in the TANDBERG VCS Getting Started Guide [28}. Using the web interface To use the web interface: 1. Open a browser window and in the address bar type either: • the IP address of the system • the FQDN of the system 2. Click Administrator Login. 3. Enter a valid administrator username and password and click Login. (See the Login accounts section for details on setting up administrator accounts.) You are presented with the Overview page. 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. How page navigation is shown in this guide In this Administrator Guide, instructions for navigating the web interface are shown in the format: • Menu option1 > Menu option2 followed by the Name of the page that you will be taken to in order to perform a task. Supported browsers The VCS web interface is designed for use with Internet Explorer 6 or later, and Firefox 2 or later. It may work with Opera and Safari, but you could encounter unexpected behavior. Javascript and cookies must be enabled to use the VCS web interface.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Using the VCS Web interface Page features and layout These are the features that can be found on some or all of the web interface pages. Note that you cannot change configuration settings if your admin account is read-only. Log out This icon appears on the top right corner of every page. Clicking on this icon ends your administrator session. Manual This icon appears on the top right corner of every page. Clicking on this icon takes you directly to the latest version of the VCS Administrator Guide on the TANDBERG web site. Information This icon appears to the right of most input fields in the web interface. Clicking on this icon activates the Information Box. Page name and Location Every page shows the page name and the menu path to that page. Each part of the menu path is a link; clicking on any of the higher level menu items takes you to that page. System Warning This icon appears on the top right corner of every page when there is a system warning in place. Click on this icon to go to the Warnings page which gives information about the warning and its suggested resolution. Information box 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. System Information The name of the user currently logged in, the system name (or LAN 1 IPv4 address if no system name is configured), local system time, hardware serial number and VCS software version are shown at the bottom of the page. Sorting Columns Click on column headings to sort the information in ascending and descending order. Select All and Unselect All Use these buttons to select and unselect all items in the list. Status On configuration pages, this section shows you the current status of the items you are configuring. Note that some configuration changes require a restart to take effect, so if you have changed the configuration but not yet restarted this shows the existing (unchanged) status. Information bar The VCS provides you with feedback in certain situations, for example when settings have been saved or when you need to take further action. This feedback is given in a yellow information bar at the top of the page. Help This icon appears on the top right corner of every page. Clicking on this icon opens a new browser window with help specific to the page you are viewing. It gives an overview of the purpose of the page, and introduces any concepts configured from the page.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Using the VCS Supported characters The VCS supports the following characters when entering text in the CLI and web interface: • the letters A-Z and a-z • decimal digits ( 0-9 ) • underscore ( _ ) • minus sign / hyphen ( - ) • equals sign ( = ) • plus sign ( + ) • at sign ( @ ) • comma ( , ) • period/full stop ( . ) • exclamation mark ( ! ) • spaces • FindMe account names additionally allow the use of all uppercase and lowercase Unicode characters The following characters are specifically not allowed: • tabs • angle brackets ( < and > ) • ampersand ( & ) • caret ( ^ ) Note that some specific text fields have different restrictions and these are noted in the relevant sections of this guide, including: • Administrator and user groups Case sensitivity Text items entered through the CLI and web interface are case insensitive. The only exception is passwords which are case sensitive. Command line interface (CLI) Installation and initial configuration Full installation and initial configuration instructions for the VCS are contained in the TANDBERG VCS Getting Started Guide [28}. Using the CLI The command line interface (CLI) is available by default over SSH and through the serial port. Access using Telnet can also be enabled. To use the CLI: 1. Start a SSH or Telnet session. 2. Enter the IP address or FQDN of the VCS. 3. Login with a username of admin and your system password. You will see a screen similar to that shown below. You can now start using the CLI by typing the appropriate commands. Command types Commands are divided into different groups: 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. xConfiguration These commands allow you to add and edit single items of data such as IP address and zones. xCommand These commands allow you to add and configure items and obtain information. xHistory These commands provide historical information about calls and registrations. xFeedback These commands provide information about events as they happen, such as calls and registrations. See the Command reference Appendix for a full description of commands available on the VCS. How CLI commands are shown in this guide In this guide, instructions for performing a task using the CLI are shown in the format: • xConfiguration • xCommand These are meant as a reference only. Each command is hyperlinked to the Command reference table at the back of this guide; clicking on the hyperlink takes you to the appropriate section of the table showing all the available sub-elements, parameters and valuespaces for the given command. Note that: • Typing the given xConfiguration path into the CLI returns a list of values currently configured for that element (and sub- elements where applicable). • Typing the given xConfiguration path into the CLI followed by a ? returns information about the usage for that element and sub-elements. • Typing the given xCommand command into the CLI with or without a ? returns command usage information. Text entry

This section describes the information that appears on the Overview page and all the pages under the Status menu of the web interface. These pages provide information on the current status and configuration of the VCS. Overview and status TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Overview page The Overview page summarizes the current configuration and status of your VCS. The Overview page opens automatically when you first log on to the web interface. You can also access it at any time by clicking on the Overview menu at the top left of any page. Many of the items on this page are configurable, and contain links to the page where they can be configured. For example, clicking on System name will take you to the System administration page, from where you can configure the system name. The Overview page displays the following information: System information System name The name that has been assigned to the VCS. Up time The amount of time that has elapsed since the system last restarted. Software version The version of software that is currently installed on the VCS. IPv4 address The VCS’s IPv4 address(es). IPv6 address The VCS’s IPv6 address(es). Options The maximum number of calls and registrations, and the availability of additional VCS features such as TURN Relays, FindMe™, Device Provisioning and Dual Network Interfaces, are controlled through the use of option keys. This section shows all the options that are currently installed on the VCS. Resource Usage Traversal calls Current: The number of traversal calls going through the VCS at this moment. Max (peak): The highest number of concurrent traversal calls handled by the VCS since it was last restarted. Total: The total number of traversal calls handled by the VCS since it was last restarted. See the Traversal calls section for details on what constitutes a traversal call. Non-traversal calls Current: The number of non-traversal calls going through the VCS at this moment. Max (peak): The highest number of concurrent non-traversal calls handled by the VCS since it was last restarted. Total: The total number of non-traversal calls handled by the VCS since it was last restarted. Registrations Current: The number of endpoints registered to the VCS at this moment. Max (peak): The highest number of endpoints concurrently registered to the VCS since it was last restarted. Total: The total number of registrations on the VCS since it was last restarted. TURN relays (VCS Expressway only) Current: The number of active TURN relays at this moment. Max (peak): The highest number of concurrently active TURN relays since the VCS was last restarted. Total: The total number of TURN relays allocated on the VCS since it was last restarted. Overview page

The System information page provides details of the software, hardware, and time settings of the VCS. To view the System information page: • Status > System > Information Some of the items on this page are configurable, and contain links to the page where they can be configured. For example, clicking on Software options will take you to the Option keys page, from where you can install new optional features. The page displays the following information: System information System name The name that has been assigned to the VCS. Product This will be TANDBERG VCS. Software version The version of software that is currently installed on the VCS. Software build The build number of this software version. Software release date The date on which this version of the software was released. Software name The internal TANDBERG reference number for this software release. Software options The maximum number of calls, and the availability of additional VCS features such as FindMe™, Device Provisioning and Dual Network Interfaces, are controlled through the use of option keys. This section shows all the optional features currently installed on the VCS. Hardware version The version number of the hardware on which the VCS software is installed. Hardware serial number The serial number of the hardware on which the VCS software is installed. Time Information Up time The amount of time that has elapsed since the system last restarted. System time (UTC) The time as determined by the NTP server. If no NTP server has been configured, this will show Time Not Set. Time zone The time zone that has been configured on the Time page. Local time If an NTP server has been configured, the system time in local time (UTC adjusted according to the local time zone) is shown. If no NTP server has been configured, the time according to the VCS’s operating system is shown. System information The Ethernet status page provides details of the MAC address and Ethernet speed settings of the VCS. To view the Ethernet status page: • Status > System > Ethernet The page displays the following information for the LAN 1 port and, if the Dual Network Interfaces option key has been installed, the LAN 2 port: MAC address The MAC address of the VCS’s Ethernet device for that LAN port. Speed The speed of the connection between the LAN port on the VCS and the Ethernet switch. Ethernet status TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The IP status page provides details of the IP and DNS settings of the VCS. To view the IP status page: • Status > System > IP The information shown on this page will vary depending on your system configuration, but may include the following information: IP Protocol Indicates the IP protocol supported by the VCS. IPv4: The VCS will only accept registrations from endpoints using an IPv4 address, and will only take calls between two endpoints or devices communicating via IPv4. It will communicate with other systems via IPv4 only. IPv6: The VCS will only accept registrations from endpoints using an IPv6 address, and will only take calls between two endpoints communicating via IPv6. It will communicate with other systems via IPv6 only. Both: The VCS will accept registrations from endpoints using either an IPv4 or IPv6 address, and will take calls using either protocol. If a call is between an IPv4-only and an IPv6-only endpoint, the VCS will act as an IPv4 to IPv6 gateway (note that this will require a traversal call license). The VCS can communicate with other systems via either protocol. IPv4 gateway The IPv4 gateway used by VCS. IPv6 gateway The IPv6 gateway used by VCS. Dual Network Interfaces Indicates whether the second LAN port has been enabled. This is done by installing the Dual Network Interfaces option key. LAN 1 Shows the IPv4 address and subnet mask, and IPv6 address of the LAN 1 port. LAN 2 If the Dual Network Interfaces option key has been installed, this shows the IPv4 address and subnet mask, and IPv6 address of the LAN 2 port. DNS Server 1..5 address The IP address(es) of each of the DNS servers that will be queried when resolving domain names. Up to 5 DNS servers may be configured. Domain Specifies the name to be appended to the host name before a query to the DNS server is executed. IP status The Resource usage page provides statistics about the numbers of current and cumulative calls and registrations on the VCS. This page automatically refreshes every 5 seconds. To view the Resource usage page: • Status > System > Resource usage The page displays the following information: Traversal calls Current: The number of traversal calls going through the VCS at this moment. Max (peak): The highest number of concurrent traversal calls handled by the VCS since it was last restarted. Total: The total number of traversal calls handled by the VCS since it was last restarted. Non-traversal calls Current: The number of non-traversal calls going through the VCS at this moment. Max (peak): The highest number of concurrent non-traversal calls handled by the VCS since it was last restarted. Total: The total number of non-traversal calls handled by the VCS since it was last restarted. Registrations Current: The number of devices registered to the VCS at this moment. Max (peak): The highest number of devices concurrently registered to the VCS since it was last restarted. Total: The total number of registrations on the VCS since it was last restarted. Resource usage TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Registrations by device page lists each device currently registered with the VCS, and allows you to remove a device's registration. To view the Registrations by device page: • Status > Registrations > By device Note that an H.323 device can register with more than one alias; in such cases this page will show only one alias and (when present) one E.164 number for that device. Note also that a single device can support both the SIP and H.323 protocols; in such a case the SIP registration and the H.323 registration will appear as separate entries on this page. For a list of all aliases currently registered with the VCS, see the Registrations by alias page. Clicking on a device's name or E164 number takes you to the Registrations details page for that device. The page displays the following information: Name For H.323 devices, this is one of its aliases. If the device has registered with more than one alias, this will be (in order of preference) its H.323 ID, URI or email address. For MCUs and Gateways this will be its alias or, if it has not registered an alias, one of its prefixes. For SIP devices, this is its SIP AOR. E164 For H.323 devices that have registered one or more E.164 numbers, the first will be shown here. For SIP devices this will always be blank because they cannot register E.164 numbers. Type Indicates the nature of the registration. This will most commonly be Endpoint, MCU, Gateway, or SIP UA. Protocol Whether the registration is for a SIP or H.323 device. Creation Time The date and time at which the registration was accepted. If an NTP server has not been configured, this will say Time not set. IP address For H.323 devices, this is the RAS address. For SIP UAs it is the Contact address presented in the REGISTER request. Unregister Click to remove the selected registrations. Note that removing a registration will not prevent the same device from automatically re-registering. Filter To limit the list of registrations, enter one or more characters in the Filter field and select Filter. Only those registrations that contain (in any of the displayed fields) the string you entered will be shown. To return to the full list of registrations, click Reset. Registrations by device Registrations by alias The Registrations by alias page lists all the aliases, E.164 numbers and prefixes used by all endpoints and systems currently registered with the VCS. To view the Registrations by alias page: • Status > Registrations > By alias Note that a single H.323 device can register with more than one alias, and each will appear as a separate entry on this page. For a list of all devices registered with the VCS, see the Registrations by device page. Clicking on any Alias will take you to the Registrations details page for the device that registered that alias. The page displays the following information: Alias The H.323 alias, E.164 number, prefix or SIP AOR registered by a device. Alias type Shows whether the alias is an H.323 ID, E.164 number, prefix or SIP AOR. Device type Indicates the nature of the device that registered the alias. This will most commonly be Endpoint, MCU, Gateway or SIP UA. Protocol Indicates whether the registration is for a SIP or H.323 device. Creation Time The date and time at which the registration was accepted. If an NTP server has not been configured, this will say Time not set. IP address For H.323 devices, this is the RAS address. For SIP UAs it is the Contact address presented in the REGISTER request. Filter To limit the list of registrations, enter one or more characters in the Filter field and click Filter. Only those registrations that contain (in any of the displayed fields) the string you entered will be shown. To return to the full list of registrations, click Reset. TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Registration history page lists all the registrations that are no longer current. It lists the most recent historical registrations since the last restart, up to a maximum of 255. To view the Registration history page: • Status > Registrations > History The page displays the following information: Name The H.323 alias or SIP AOR that the device registered. Clicking on an individual name will take you to the Registrations Details page for that registration. E164 For H.323 devices that registered one or more E.164 numbers, the first will be shown here. For SIP devices this will always be blank because they cannot register E.164 numbers. Type Indicates the nature of the registration. This will most commonly be Endpoint, Gateway, or SIP UA. Protocol Indicates whether the registration was for a SIP or H.323 device. Creation Time The date and time at which the registration was accepted. If an NTP server has not been configured, this will say Time not set. End Time The date and time at which the registration was terminated. Duration The length of time that the registration was in place. Reason The reason why the registration was terminated. Filter To limit the list of registrations, enter one or more characters in the Filter field and click Filter. Only those registrations that contain (in any of the displayed fields) the string you entered will be shown. To return to the full list of registrations, click Reset. Registration history Registration details The Registration details page shows full information about an individual device's registration. The exact details and options shown here will depend on the device's protocol, whether the registration is still current, and whether a Deny List is in use. To view the Registration details page: • Status > Registrations > By device, then click on the device's Name or E164 number • Status > Registrations > By alias, then click on the device's Alias • Status > Registrations > History, then click on the device's Name or E164 number. Unregister Click to unregister the device. Note that the device may automatically re-register after a period of time, depending on its configuration. To prevent this, you must also use an Allow List or Deny List. Block Click to add all the aliases for this registration to the Deny List. (This option is only available if a Deny List has been activated.) Unregister and block Click to de-register the device add all the aliases for this registration to the Deny List, thus preventing the device from automatically re-registering. (This option is only available if a Deny List has been activated.) The links available in the Related tasks section may include: Configure the registration Deny List Click to go to the Registration Deny List page, where you can add entries to the Deny List. View active calls involving this registration Click to go to the Calls page, filtered for this particular registration. View previous calls involving this registration Click to go to the Call history page, filtered for this particular registration. TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Call status page lists all the calls currently taking place to or from devices registered with the VCS, or that are passing through the VCS. To view the Calls status page: • Status > Calls > Calls The page displays the following information: Start time The date and time when the call was placed. Source The alias of the device that placed the call. Destination The alias to which the call was placed. This may be different from the alias that was actually dialed from the device, as it may have been transformed either locally or before the zone was queried. Bandwidth allocated The bandwidth allocated to this call. This may be different from the amount requested by the endpoint that placed the call. Route The subzone or zone from which the call was received and the subzone or zone to which the call was placed. To see the complete route taken by the call within the VCS, including intermediary subzones, click View to go to the Call summary page. Protocol Shows whether the call used H.323, SIP, or both protocols. Actions Click View to go to the Call summary page, which lists further details of this call. Disconnect Click to disconnect the selected calls. ! Call disconnection works differently for H.323 and SIP calls due to differences in the way the protocols work. For H.323 calls, and interworked H.323 to SIP calls, the Disconnect command will actually disconnect the call. For SIP to SIP calls, the Disconnect command will cause the VCS to release all resources used for the call and the call will appear on the system as disconnected. However, SIP calls are peer-to-peer and as a SIP proxy the VCS has no authority over the endpoints. Although releasing the resources may have the side-effect of disconnecting the SIP call, it is also possible that the call signaling, media or both may stay up (depending on the type of call being made). The call will not actually disconnect until the SIP endpoints involved have also cleared their resources. Filter To limit the list of calls, enter one or more characters in the Filter field and click Filter. Only those calls that contain (in any of the displayed fields) the characters you entered will be shown. To return to the full list of calls, click Reset. Calls The Call history page lists all the calls that are no longer active that have taken place since the VCS was last restarted. To view the Call history page: • Status > Calls > History The page displays the following information: Start time The date and time when the call was placed. Source The alias of the device that placed the call. Destination The alias to which the call was placed. This may be different from the alias that was actually dialed from the device, as it may have been transformed either locally or before the zone was queried. Protocol Shows whether the call used H.323, SIP, or both protocols. Duration The length of time of the call. Status The reason the call was terminated. Actions Click View to go to the Call summary page, which lists further details of this call. Filter To limit the list of calls, enter one or more characters in the Filter field and click Filter. Only calls containing those characters (in any of the displayed fields) are shown. To return to the full list of calls, click Reset. Call history Call summary The Call summary page (Status > Calls > Calls or Status > Calls > History, then click View for a particular call) provides overview statistics about a call, including information about the most relevant legs. From here further detailed information about the call can be viewed by using the links in the Related tasks section at the bottom of the page: • View media statistics for this call takes you to the Call media page, where you can view information about the most relevant session for a call. For traversal calls (where the VCS took the media), it also lists the individual media channels (audio, video, data and so on) that made up the call. • View all details of this call takes you to the Call details page, where you can view full information about this call. • View search details for this call takes you to the Search details page, which lists full information about all the searches associated with this call's Call Tag, including the subzones and zones that were searched and any transforms that were applied to the alias being searched for. • View all events associated with this call takes you to the Event Log page, filtered to show only those events associated with this call's Call Tag. TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Search history page lists the most recent 255 searches that have taken place since the VCS was last restarted. To view the Search history page: • Status > Search history The page displays the following information: Start time The date and time at which the search was initiated. Search type The type of message being sent. Source The alias of the endpoint that initiated the call. Destination The alias that was dialed from the endpoint. This may be different from the alias to which the call was actually placed, as the original alias may have been transformed either locally or before the neighbor was queried. Found Indicates whether or not the search was successful. Actions Click View to go to the Search details page which lists full details of this call. Filter To limit the list of calls, enter one or more characters in the Filter field and click Filter. Only those calls that contain (in any of the displayed fields) the characters you entered will be shown. To return to the full list of calls, click Reset. Searches About searches Before a call can be placed, the endpoint being called must be located. The VCS sends and receives a series of messages during its attempt to locate the endpoint being called; these messages are each known as searches. An individual call can have one or more searches associated with it, and these searches can be of different types. The type of search message that is sent will depend on whether the call is for SIP or H.323, and whether the call request was received locally or from an external zone, as follows: • For H.323 calls that are placed locally, two messages are sent: the first is an ARQ which locates the device being called, and the second is the call Setup which sends a request to the device asking it to accept the call. Each message shows up as a separate search in the Search history page, but only the Setup message will be associated with a particular call. • For H.323 searches originating from external zones, an LRQ will appear in the Search history page. • For SIP, a single message is sent in order to place a call: this will either be a SIP INVITE or a SIP OPTIONS. Each search has an individual Search ID; each call has an individual Call Tag (see Call IDs, Serial Numbers and Tags). Search history Search details The Search details page (Status > Search history, then click View for a particular search) lists full information about either an individual search, or all searches associated with a single call (depending on how you reached the page). The information shown includes: • the subzones and zones that were searched • the call path and hops • any transforms that were applied to the alias being searched for Other information associated with the search and (if it was successful) the resulting call can be viewed using the links in the Related tasks section at the bottom of the page. • View all events associated with this call tag takes you to the Event Log page, filtered to show only those events associated with the Call Tag relating to this search. • View call information associated with this call tag takes you to the Call summary page, where you can view overview information about the call. • View all searches associated with this call tag will be shown if you are viewing details of an individual search and there are other searches associated with the same call. It takes you to a new Search details page which lists full information about all the searches associated with the call's Call Tag. TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Local Zone status page lists all the subzones that together make up the Local Zone. This will always include the Default Subzone and the Traversal Subzone, plus any other subzones that have been configured. To view the Local Zone page: • Status > Local Zone Clicking on a subzone name will take you to the configuration page for that subzone The page displays the following information: Subzone name The names of each subzone currently configured on this VCS. Registrations The number of devices currently registered within the subzone. Note that devices cannot be registered to the Traversal Subzone. Calls The number of calls currently passing through the subzone. Note that a single call may pass through more than one subzone, depending on the route it takes. For example, traversal calls from a locally registered endpoint will always pass through the Traversal Subzone, so they will show up twice; once in the originating subzone and once in the Traversal Subzone. Bandwidth used The total amount of bandwidth used by all calls passing through the subzone. Local Zone The Zone status page lists all the zones that are currently configured on your VCS, the number of calls and amount of bandwidth being used by each, and their current status. The list of zones always includes the Default Zone, plus any other zones that you have created. To view the Zones page: • Status > Zones Clicking on a zone name takes you to the configuration page for that zone. Note that this does not apply to the Default Zone, as this is not configurable. The page displays the following information: Name The names of each zone currently configured on this VCS. Type The type of zone. See the About zones section for a full description of each zone type. Calls The number of calls currently passing out to or received in from each zone. Bandwidth used The total amount of bandwidth used by all calls passing out to or received in from each zone. Status The current status of each zone. Zones TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

Links The Link status page lists all the links currently configured on your VCS, along with the number of calls and the bandwidth being used by each link. To view the Link status page: • Status > Bandwidth > Links Clicking on a link name will take you to the configuration page for that link. The page displays the following information: Name The name of each link. Calls The total number of calls currently traversing the link. Note that a single call may traverse more than one link, depending on how your system is configured. Bandwidth used The total bandwidth of all the calls currently traversing the link. Pipes The Pipe status page lists all the pipes currently configured on your VCS, along with the number of calls and the bandwidth being used by each pipe. To view the Pipe status page: • Status > Bandwidth > Pipes Clicking on a pipe name will take you to the configuration page for that pipe. The page displays the following information: Name The name of each pipe. Calls The number of calls currently traversing the pipe. Note that a single call may traverse more than one pipe, depending on how your system is configured. Bandwidth used The total bandwidth of all the calls currently traversing the pipe. TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Status > Applications > Presence menu has three sub-menus: • Publishers • Presentities • Subscribers. These pages provide information about endpoints and presentities using the Presence services on the VCS. Refer to the Viewing presence status section for a full explanation of the information on these pages. Presence TURN relays The TURN relays page lists all the currently active TURN relays on the VCS. For each relay, it shows the requesting client address and port and the corresponding VCS address and port. TURN services are available on VCS Expressways only. They are configured from the TURN page (VCS configuration > Expressway > TURN). To view the TURN relays page: • Status > TURN relays The page displays the following information: Relay The index number of the relay. Address The IP address and port on the VCS of the relay resource that has been allocated for this particular request. Client The IP address and port on the NAT (or the client if there is no NAT) that requested the relay Creation time The date and time the relay became active. Expiry time The date and time the relay will become inactive. Click View to go to the TURN relay summary page where you can see more information about a relay. From here further detailed information about the relay can be viewed by using the links in the Related tasks section at the bottom of the page: • View permissions for this relay takes you to the TURN relay permissions page, where you can view information about the permissions that have been defined on the relay. • View channels for this relay takes you to the TURN relay channels page, where you can view information about the channel bindings that have been defined on the relay. • View counters for this relay takes you to the TURN relay counters page, where you can view TURN request, response and error counters, as well as media counters, for the relay. TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

The Provisioning status page shows the status of the VCS's provisioning server. The provisioning server provides basic device provisioning for registered Movi users, without the need for TMS. To view the Provisioning status page: • Status > Applications > Provisioning The provisioning server is only available if the Starter Pack option key is installed. The page displays the following information: Server status The state of the provisioning server. Subscription counters A summary of the subscription requests received by the server since the VCS was last restarted. It shows counts of: • the total number of subscription requests received • how many requests were sent a successful provisioning response • failed requests because the account requesting provisioning could not be found • failed requests because the account requesting provisioning had no provisioned devices associated with it Provisioning OCS Relay The OCS Relay status page lists all the FindMe IDs being handled by the OCS Relay application, and shows the current status of each. The OCS Relay application is required in deployments that use both Microsoft Office Communicator (MOC) clients and FindMe, if they both use the same SIP domain. Its purpose is to: • enable the VCS to share FindMe presence information with MOC clients • enable the Microsoft Office Communications Server (OCS) to forward calls to FindMe IDs. To view the OCS Relay status page: • Status > Applications > OCS Relay The OCS Relay application is configured from the OCS Relay page (Applications > OCS Relay). The page displays the following information: Alias The FindMe ID being handled by the OCS Relay application. Presence state Shows the presence information currently being published for the FindMe ID. Registration state Indicates whether the FindMe ID has registered successfully with OCS. Doing so allows OCS to forward calls to the FindMe ID. Subscription state Indicates whether the OCS Relay application has subscribed successfully to the FindMe ID's presence information. Doing so allows MOC clients to view the presence information of FindMe users. Status TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

Warnings The Warnings page provides a list of all the warnings currently in place on your system (and, where applicable, their proposed resolution). Warnings occur when an event or configuration change has taken place on the VCS that requires some manual administrator intervention, such as a restart. Warnings may also be raised for hardware and environmental issues such as faulty disks and fans or high temperatures. When there are unacknowledged warnings in place on the VCS, a warning icon appears at the top right of all pages. To view the Warnings page, either: • click the icon • go to Status > Warnings The page displays the following information: Warning The warning message. State Indicates whether the warning is New or Acknowledged. Action Shows you how to address the problem. Clicking the hyperlink either takes you to the appropriate configuration page or displays further detailed instructions. You should deal with each warning by clicking each Action hyperlink and making the necessary configuration changes to resolve the problem. You can acknowledge a warning by selecting it and clicking on the Acknowledge button). This removes the warning icon from the web interface, but the warning will still be listed on the Warnings page with a status of Acknowledged. If a new warning occurs, the warning icon will reappear. You cannot delete warnings from the Warnings page. Warnings are removed by the VCS only after the required action or configuration change has been made. After a restart of the VCS, any Acknowledged warnings that are still in place on the VCS will reappear with a status of New, and must be re-acknowledged. A list of warnings that can be raised by the VCS is included at the back of this guide. Hardware The Hardware page provides information about the physical status of your VCS unit. To view the Hardware page: • Status > Hardware Information displayed includes: • fan speeds • component temperatures • component voltages Any appropriate minimum or maximum levels are shown to help identify any components operating outside of their standard limits. Do not attempt to service the apparatus yourself as opening or removing covers may expose you to dangerous voltages or other hazards, and will void the warranty. Refer all servicing to qualified service personnel. ! TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

Event Log The Event Log is a list of all the events that have occurred on the system since the last upgrade. The Event Log holds 2GB of data; when this size is reached, the oldest entries are overwritten. However only the first 50MB of event log data can be displayed through the web interface. To view the Event Log page: • Status > Logs > Event Log To view the Event Log using the CLI: • eventlog Filtering the Event Log Search for lets you filter the event log. Enter the words you want to search for and click Filter. Only those events that contain all the words you entered are shown. To do more advanced filtering, click more options. This gives you additional filtering methods: Contains the string: only includes events containing the exact phrase entered here. Contains any of the words: includes any events that contain at least one of the words entered here. Not containing any of the words: filters out any events containing any of the words entered here. Note: use spaces to separate each word you want to filter by. Click Filter to reapply any modified filter conditions. To return to the complete event log listing, click Reset. Reconfigure the log settings Clicking this link takes you to the Logging configuration page. From this page, you can set the level of events that are recorded in the Event Log, and also set up a remote server to which the Event Log can be copied. See the sections on Setting the Event Log level and About remote logging for more information. Results This section shows all the events, with the most recent being shown first. Most tvcs events contain hyperlinks in one or more of the fields (such fields change color when you hover over them). You can click on the hyperlink to show only those events that contain the same text string. For example, clicking on the text that appears after Event= will filter the list to show all the events of that particular type. Likewise, clicking on a particular Call-Id will show just those events that contain a reference to that particular call. Event Log color coding Certain events in the Event Log are color-coded so that you can identify them more easily. These events are as follows: Green • System Start • Installation of succeeded • Registration Accepted • Call Connected • Request Successful • Beginning System Restore • Completed System Restore Orange • System Shutdown Red • Registration Rejected • Registration Refresh Rejected • Call Rejected • Security Alert • License Limit Reached • Decode Error • TLS Negotiation Error • External Server Communications Failure • Application Failed • Request Failed • System Backup Error • System Restore Error • Authorization Failure TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

Administrator and FindMe user sessions Administrator session related events are: • Admin Session Start • Admin Session Finish • Admin Session Login Failure FindMe user session related events are: • User Session Start • User Session Finish • User Session Login Failure For both administrator and FindMe user related events, the Detail field includes: • the name of the administrator or FindMe user to whom the session relates, and their IP address • the date and time that the login was attempted, started, or ended TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Event Log format The Event Log is displayed in an extension of the UNIX syslog format: date time process _ name: message _ details where: Field Description date The local date on which the message was logged. time The local time at which the message was logged. process _ name The name of the program generating the log message. This could include: tvcs for all messages originating from TANDBERG VCS processes findme for FindMe account data migration events web for all web login and configuration events tprovisioning for all events associated with the TMS Agent but will differ for messages from other applications running on the VCS. message _ details The body of the message (see the Message details field section for further information). Event Log

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Name Description Event The event which caused the log message to be generated. See Events and levels for a list of all events that are logged by the VCS, and the level at which they are logged. User The username that was entered when a login attempt was made. ipaddr The source IP address of the user who has logged in. Protocol Specifies which protocol was used for the communication. Valid values are: • TCP • UDP • TLS Reason Textual string containing any reason information associated with the event. Service Specifies which protocol was used for the communication. Will be one of: • H323 • SIP • H.225 • H.245 • LDAP • Q.931 • NeighbourGatekeeper • Clustering • ConferenceFactory Message Type Specifies the type of the message. Response- code SIP response code or, for H.323 and interworked calls, a SIP equivalent response code. Src-ip Source IP address (the IP address of the device attempting to establish communications). This can be an IPv4 address or an IPv6 address. Dst-ip Destination IP address (the IP address of the destination for a communication attempt). The destination IP is recorded in the same format as Src-ip. Src-port Source port: the IP port of the device attempting to establish communications. Dst-port Destination port: the IP port of the destination for a communication attempt. Src-alias If present, the first H.323 alias associated with the originator of the message. If present, the first E.164 alias associated with the originator of the message. Dst-alias If present, the first H.323 alias associated with the recipient of the message. If present, the first E.164 alias associated with the recipient of the message. Detail Descriptive detail of the Event. Name Description Auth Whether the call attempt has been authenticated successfully. Method SIP method (INVITE, BYE, UPDATE, REGISTER, SUBSCRIBE, etc). Contact Contact: header from REGISTER. AOR Address of record. Call-id The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. Call-serial- number The VCS-local Call Serial Number that is common to all protocol messages for a particular call. Tag The Tag is common to all searches and protocol messages across a VCS network for all forks of a call. Call-routed Indicates if the VCS took the signaling for the call. To • for REGISTER requests: the AOR for the REGISTER request • for INVITEs: the original alias that was dialed • for all other SIP messages: the AOR of the destination. Request-URI The SIP or SIPS URI indicating the user or service to which this request is being addressed. Num-bytes The number of bytes sent/received in the message. Protocol- buffer Shows the data contained in the buffer when a message could not be decoded. Duration Request/granted registration expiry duration. Time A full UTC timestamp in YYYY/MM/DD-HH:MM:SS format. Using this format permits simple ASCII text sorting/ordering to naturally sort by time. This is included due to the limitations of standard syslog timestamps. Level The level of the event as defined in the About Event Log levels section. UTCTime Time the event occurred, shown in UTC format. Event Log Message details field For all messages logged from the tvcs process, the message _ details field, which contains the body of the message, consists of a number of human-readable name=value pairs, separated by a space. The first name element within the message _ details field is always Event and the last name element is always Level. The table below shows all the possible name elements within the message _ details field, in the order that they would normally appear, along with a description of each. In addition to the events described below, a syslog.info event containing the string MARK is logged after each hour of inactivity to provide confirmation that logging is still active.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Event Log Events and levels Event Description Level Admin Session Finish An administrator has logged off the system. 1 Admin Session Login Failure An unsuccessful attempt has been made to log in as an administrator. This could be because an incorrect username or password (or both) was entered. 1 Admin Session Start An administrator has logged onto the system. 1 Application Exit The VCS application has been exited. Further information may be provided in the Detail event parameter. 1 Application Failed The VCS application is out of service due to an unexpected failure. 1 Application Start The VCS has started. Further detail may be provided in the Detail event parameter. 1 Application Warning The VCS application is still running but has experienced a recoverable problem. Further detail may be provided in the Detail event parameter. 1 Authorization Failure The user has either entered invalid credentials, does not belong to an access group, or belongs to a group that has an access level of "None". Applies when remote authentication is enabled. 1 Beginning System Backup A system backup has started. 1 Beginning System Restore A system restore has started. 1 Call Answer Attempted An attempt to answer a call has been made. 1 Call Attempted A call has been attempted. 1 Call Bandwidth Changed The endpoints in a call have renegotiated call bandwidth. 1 Call Connected A call has been connected. 1 Call Diverted A call has been diverted. 1 Call Disconnected A call has been disconnected. 1 Call Inactivity Timer A call has been disconnected due to inactivity. 1 Call Rejected A call has been rejected. The Reason event parameter contains a textual representation of the H.225 additional cause code. 1 Call Rerouted The VCS has Call Routed mode set to Optimal and has removed itself from the call signaling path. 1 Completed System Backup A system backup has completed. 1 Completed System restore A system restore has completed. 1 Configlog Cleared An operator cleared the Configuration Log. 1 Decode Error A syntax error was encountered when decoding a SIP or H.323 message. 1 Directory Service Database Started The TMS Agent database has started. 1

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Event Log Event Description Level Directory Service Database Stopped The TMS Agent database has stopped. 1 Directory Service Failed Restarting The TMS Agent failed to restart. 1 Directory Service Restarted The TMS Agent has restarted. 1 Directory Service Restarting The TMS Agent is restarting. 1 Directory Service Starting The TMS Agent is starting. 1 Directory Service Shutting Down The TMS Agent is shutting down. 1 Error Response Sent The TURN server has sent an error message to a client (using STUN protocol). 3 Eventlog Cleared An operator cleared the Event Log. 1 External Server Communication Failure Communication with an external server failed unexpectedly. The Detail event parameter should differentiate between "no response" and "request rejected". Servers concerned are: • DNS • LDAP servers • Neighbor Gatekeeper • NTP servers • Peers 1 FindMe Search Failed A search of the FindMe database has failed, for example due to no alias being provided. 1 FindMe Transfer FindMe user accounts have been migrated across clusters. The Detail event parameter provides additional details. 1 Hardware Failure There is an issue with the VCS hardware. If the problem persists, contact your TANDBERG support representative. 1 License Limit Reached Licensing limits for a given feature have been reached. The Detail event parameter specifies the facility/limits concerned. Possible values for the detail field are: • Non Traversal Call Limit Reached • Traversal Call Limit Reached If this occurs frequently, you may want to contact your TANDBERG representative to purchase more licenses. 1 Message Received An incoming RAS message has been received. 2 Message Received An incoming RAS NSM Keepalive, H.225, H.245 or a RAS message between peers has been received. 3 Message Received (SIP) An incoming message has been received. 4

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Event Log Event Description Level Message Rejected This could be for one of two reasons: • The VCS Authentication mode is set to On, and an endpoint has unsuccessfully attempted to send a message (such as a registration request) to the VCS. This could be either because the endpoint has not supplied any authentication credentials, or because its credentials do not match those expected by the VCS. • Clustering is enabled but bandwidth across the cluster has not been configured identically, and the VCS has received a message relating to an unknown peer, link, pipe, subzone or zone. 1 Message Sent An outgoing RAS message has been sent. 2 Message Sent An outgoing RAS NSM Keepalive, H.225, H.245 or a RAS message between peers has been sent. 3 Message Sent (SIP) An outgoing message has been sent. 4 Operator Call Disconnect An administrator has disconnected a call. 1 Outbound TLS Negotiation Error The VCS is unable to communicate with another system over TLS. Refer to the event parameters for more information. 1 Policy Change A policy file has been updated. 1 POST request failed A HTTP POST request was submitted from an unauthorized session. 1 Provisioning Diagnostic messages from the provisioning server. The Detail event parameter provides additional information. 1 Reboot Requested A system reboot has been requested. Refer to the Reason event parameter for specific information. 1 Registration Accepted A registration request has been accepted. 1 Registration Refresh Accepted A request to refresh or keep a registration alive has been accepted. 3 Registration Refresh Rejected A request to refresh a registration has been rejected. 1 Registration Refresh Requested A request to refresh or keep a registration alive has been received. 3 Registration Rejected A registration request has been rejected. The Reason and Detail event parameters provide more information about the nature of the rejection. 1 Registration Removed A registration has been removed by the VCS. The Reason event parameter specifies the reason why the registration was removed. This is one of: • Authentication change • Conflicting zones • Operator forced removal • Operator forced removal (all registrations removed) • Registration superseded. 1 Registration Requested A registration has been requested. 1 Relay Allocated A TURN server relay has been allocated. 2 Relay Deleted A TURN server relay has been deleted. 2

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Event Log Event Description Level Relay Expired A TURN server relay has expired. 2 Request Failed A request sent to the Conference Factory has failed. 1 Request Received A call-related SIP request has been received. 2 Request Received A non-call-related SIP request has been received. 3 Request Sent A call-related SIP request has been sent. 2 Request Sent A non-call-related SIP request has been sent. 3 Request Successful A successful request was sent to the Conference Factory. 1 Response Received A call-related SIP response has been received. 2 Response Received A non-call-related SIP response has been received. 3 Response Sent A call-related SIP response has been sent. 2 Response Sent A non-call-related SIP response has been sent. 3 Restart Requested A system restart has been requested. Refer to the Reason event parameter for specific information. 1 Search Attempted A search has been attempted. 1 Search Cancelled A search has been cancelled. 1 Search Completed A search has been completed. 1 Search Loop detected The VCS is in Call loop detection mode and has identified and terminated a looped branch of a search. 2 Secure mode disabled The VCS has successfully exited Advanced account security mode. 1 Secure mode enabled The VCS has successfully entered Advanced account security mode. 1 Security Alert A potential security-related attack on the VCS has been detected. 1 Source Aliases Rewritten A source alias has been changed to indicate the caller's FindMe ID. 1 Success Response Sent The TURN server has sent a success message to a client (using STUN protocol). 3 System backup completed The system backup process has completed. 1 System Backup error An error occurred while attempting a system backup. 1 System backup started The system backup process has started. 1 System Configuration Changed An item of configuration on the system has changed. The Detail event parameter contains the name of the changed configuration item and its new value. 1 System restore completed The system restore process has completed. 1

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status Event Log Event Description Level System Restore error An error occurred while attempting a system restore. 1 System restore started The system restore process has started. 1 System Shutdown The operating system was shutdown. 1 System snapshot started A system snapshot has been initiated. 1 System snapshot completed A system snapshot has completed. 1 System Start The operating system has started. The Detail event parameter may contain additional information if there are startup problems. 1 TLS Negotiation Error Transport Layer Security (TLS) connection failed to negotiate. 1 TMS Agent backup completed The TMS Agent backup process has completed. 1 TMS Agent backup error An error occurred while attempting a TMS Agent backup. 1 TMS Agent backup started The TMS Agent backup process has started. 1 TMS Agent restore completed The TMS Agent restore process has completed. 1 TMS Agent Restore error An error occurred while attempting a TMS Agent restore. 1 TMS Agent restore started The TMS Agent restore process has started. 1 Unregistration Accepted An unregistration request has been accepted. 1 Unregistration Rejected An unregistration request has been rejected. 1 Unregistration Requested An unregistration request has been received. 1 Upgrade Messages related to the software upgrade process. Refer to the Detail event parameter for specific information. 1 User session finish A FindMe user has logged out of the system. 1 User session Login failure An unsuccessful attempt has been made to log in as a FindMe user. This could be because either an incorrect username or password (or both) was entered. 1 User session start A FindMe user has logged on to the system. 1 Warning acknowledged An administrator has acknowledged a warning. The Detail event parameter provides information about the nature of the issue. 1 Warning lowered The issue that caused a warning to be raised has been resolved. The Detail event parameter provides information about the nature of the issue. 1 Warning raised The VCS has detected an issue and raised a warning. The Detail event parameter provides information about the nature of the issue. 1

Configuration Log The Configuration Log is a list of all changes to the VCS configuration made using the web or command line interface. The Configuration Log visible using the web interface holds a maximum of 4MB of data; when this size is reached, the oldest entries are overwritten. To view the Configuration Log page: • Status > Logs > Configuration Log To view the Configuration Log using the CLI: • configlog Filtering the Configuration Log Search for lets you filter the Configuration Log. Enter the words you want to search for and click Filter. Only those events that contain all the words you entered are shown. To do more advanced filtering, click more options. This gives you additional filtering methods: Contains the string: only includes events containing the exact phrase entered here. Contains any of the words: includes any events that contain at least one of the words entered here. Not containing any of the words: filters out any events containing any of the words entered here. Note: use spaces to separate each word you want to filter by. Click Filter to reapply any modified filter conditions. To return to the complete Configuration Log listing, click Reset. Results This section shows all the web-based events, with the most recent being shown first. Most events contain hyperlinks in one or more of the fields (such fields will change color when you hover over them). You can click on the hyperlink to automatically filter the search so that only those events that contain that same text string are shown. For example, clicking on the text that appears after Event= will filter the list to show all the events of that particular type. Likewise, clicking on a particular user will show just those events relating to that particular administrator account. All events that appear in the Configuration Log are recorded as Level 1 Events, so any changes to the Logging levels will not affect their presence in the Configuration Log. Configuration Log events Changes to the VCS configuration made by administrators using the web interface have an Event field of System Configuration Changed. The Detail field of each of these events shows: • the configuration item that was affected • what it was changed from and to • the name of the administrator user who made the change, and their IP address • the date and time that the change was made TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Status

This section describes all the options that appear under the System Configuration menu of the web interface. These options enable you to configure the VCS in relation to the network in which it is located, for example its IP settings and the external services used by the VCS (e.g. DNS, NTP and SNMP). System configuration TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance System configuration The System administration page allows you to configure the name of the VCS and the means by which it is accessed by administrators. To go to the System administration page: • System configuration > System To configure these settings using the CLI: • xConfiguration SystemUnit Name • xConfiguration Administration You must save your changes and restart the system for any changes (apart from Session time out) to take effect. About the system name The system name is used to identify the VCS. It appears in various places in the web interface, and in the display on the front panel of the unit (so that you can identify it when it is in a rack with other systems). The system name is also used by TANDBERG’s TMS. We recommend that you give the VCS a name that allows you to easily and uniquely identify it. If the system name (or IPv6 address) is longer than 16 characters, only the last 16 characters will be shown in the display on the front panel. About administration access settings While it is possible to administer the TANDBERG VCS by using a PC connected directly to the unit via a serial cable, you may want to access the system remotely over IP. You can do this using either or both: • the web interface via HTTPS • a command line interface via SSH or Telnet. By default, access via HTTPS and SSH is enabled; access via Telnet is disabled. You can also enable access via HTTP. However, this mode works by redirecting HTTP calls to the HTTPS port, so HTTPS must also be enabled for access via HTTP to function. The Session time out setting controls whether the system automatically logs out the current user after a configurable period of inactivity. ! By default, access via HTTPS and SSH is enabled; access via Telnet is disabled. To securely manage the VCS you should disable Telnet, using the encrypted HTTPS and SSH protocols instead. For further security, disable HTTPS and SSH as well and use the serial port to manage the system. ! TMS accesses the VCS via the web server. If HTTPS mode is turned off, TMS will not be able to access it. System administration The Ethernet page allows you to configure the speed of the connection between the VCS and the Ethernet switch to which it is connected. To go to the Ethernet page: • System configuration >Ethernet To configure ethernet settings using the CLI: • xConfiguration Ethernet You must save your changes and restart the system for changes made using this page to take effect. About Ethernet speed The Ethernet speed setting determines the speed of the connection between the VCS and the Ethernet switch. It must be set to the same value on both systems. If you have the Dual Network Interfaces option key installed, you will be able to configure the speed for both the LAN 1 and LAN 2 ports separately. The default is Auto, which means that the two systems will auto- negotiate the appropriate speed. ! You should only change the default value from Auto if 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. Ethernet

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance System configuration The IP page lets you configure the IP protocols and settings of the VCS. To go to the IP page • System configuration > IP To configure these settings using the CLI: • xConfiguration IP • xConfiguration IPProtocol • xConfiguration Ethernet You must save your changes and restart the system for changes to take effect. About IP protocols You can configure the VCS to use IPv4, IPv6 or Both protocols. The default is Both. IPv4: the VCS only: accepts registrations from endpoints using an IPv4 address; takes calls between endpoints communicating via IPv4; communicates with other systems via IPv4. IPv6: the VCS only: accepts registrations from endpoints using an IPv6 address; takes calls between endpoints communicating via IPv6; communicates with other systems via IPv6. Both: the VCS 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. 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. Some endpoints support both IPv4 and IPv6, but an endpoint can use only one protocol when registering with the VCS. Whether the endpoint uses IPv4 or IPv6 is determined by the IP addressing scheme used on the endpoint to specify the IP address of the VCS. 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. External LAN interface The External LAN interface field indicates which LAN port is connected to your external network. It also determines the port from which TURN server relay allocations are made. About IP routes (static routes) You can set the default IPv4 and IPv6 gateways used by the VCS. These are the gateways to which IP requests are sent for IP addresses that do not fall within the VCS’s local subnet. However, you can also configure additional IP routing information (static routes) on the VCS. This is sometimes required when using the Dual Network Interfaces option and occasionally required in other complex network deployments. You can configure routes for up to 50 networks and host combinations. IP routes can be configured using the CLI only: • xConfiguration IP Route • xCommand RouteAdd About LAN configuration LAN 1 is the primary network port on the VCS. You can configure the IPv4 address and subnet mask, and IPv6 address for this port. For VCS Expressway boxes behind a static NAT, you can also configure the NAT's IP address. If you have Dual Network Interfaces installed, you can also configure these options for the LAN 2 port. The VCS is shipped with a default IP address of 192.168.0.100 (for both LAN ports). This lets you connect the VCS to your network and access it via the default address so that you can configure it remotely. About Dual Network Interfaces The Dual Network Interface option key enables the LAN 2 port on the VCS Expressway for both management and call signaling. This allows you to have a second IP address for your VCS. This configuration is intended for high-security deployments where the VCS is located in a DMZ between two separate firewalls on separate network segments. In such deployments, routers prevent devices on the internal network from being able to route IP traffic to the public internet, and instead the traffic must pass through an application proxy such as the VCS. To enable this feature you must purchase and install the appropriate option key. Contact your TANDBERG representative for information. You should configure the LAN 1 port and restart the VCS before configuring the LAN 2 port. If you have Dual Network Interfaces enabled but only want to configure one of the Ethernet ports, you must use LAN 1. About static NAT It is possible to deploy a VCS Expressway behind a static NAT device, allowing it to have separate public and private IP addresses. This feature is intended for use in deployments where the VCS Expressway is located in a DMZ, and has the Dual Network Interfaces feature enabled (see the previous section). In these deployments, the externally-facing LAN port has static NAT enabled in order to use both a private and public IPv4 address; the internally facing LAN port does not have static NAT enabled and uses a single IPv4 (or IPv6) address. In such a deployment, when configuring traversal clients to use the VCS Expressway as a traversal server, it is the latter internally-facing IP address of the VCS Expressway that should be used. To enable the use of a static NAT: • ensure that the Dual Network Interfaces option key is installed • on the IP page (System Configuration > IP), for the externally-facing LAN port: • in the IPv4 address field, enter the VCS Expressway's private IP address • select an IPv4 static NAT mode of On • in the IPv4 static NAT field, enter the VCS Expressway's public IP address - this is the IP address of the outside of the NAT. The static NAT configuration options are only available on VCS Expressway systems which have the Dual Network Interfaces option key installed. IP

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance System configuration The DNS page lets you configure the VCS's DNS servers and DNS settings. To go to the DNS page: • System configuration > DNS To configure DNS settings using the CLI: • xConfiguration IP DNS About DNS servers You must specify at least one DNS server to be queried for address resolution if you want to either: • 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) • use features such as URI dialing or ENUM dialing You can specify up to 5 DNS servers. The VCS sends requests to all configured servers in parallel taking the first result received and discounting the rest. ! This can lead to confusing behavior should local network administrators, for example, deploy "split horizon" DNS where records held on an internal, corporate, DNS server use the same domain names but with different values to those on the public internet - an often used tactic in corporate intranets. About DNS settings Local host name The Local host name defines the DNS host name that this VCS is known by. • It must be unique for each peer in a cluster. • It is used to identify the VCS on a remote log server (a default name of "TANDBERG" is used if the Local host name is not specified). Domain name The Domain name is used when attempting to resolve unqualified server addresses (for example "ldap" or "ldap_server"). It is appended to the unqualified server address before the query is sent to the DNS server. If the server address is fully qualified (for example "ldap.server") 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 only to the following configuration settings in the VCS: • LDAP server • NTP server • External Manager server • Remote logging server TANDBERG recommends that all server addresses use an IP address or FQDN (Fully Qualified Domain Name). The DNS Domain name plays no part in URI dialing. Note that the FQDN of the VCS is the Local host name plus the Domain name. DNS Quality of Service (QoS) The Quality of Service (QoS) page lets you 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. To go to the Quality of Service page: • System configuration > Quality of Service To configure QoS settings using the CLI: • xConfiguration IP QoS 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. You must save your changes and restart the system for changes to take effect.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance System configuration The Time page lets you configure the VCS's NTP server and specify your local time zone. To go to the Time page: • System configuration > Time To configure these settings using the CLI: • xConfiguration NTP Address • xConfiguration TimeZone Name About the NTP server The NTP server is a remote server with which the VCS synchronizes to ensure its time setting is accurate. The NTP server provides the VCS with UTC time. Accurate timestamps play an important part in H.323 authentication, helping to guard against replay attacks. For this reason, if you are using authentication in a deployment that includes H.323, both the VCS and the endpoints must use an NTP server to synchronize their system time. Accurate time is also vital for configuration replication to work properly if the VCS is in a cluster, and to ensure accurate timestamps in system logs. ! Traversal clients must always authenticate with traversal servers, even if the server’s Authentication Mode is Off. Therefore, for a traversal client and traversal server to connect to each other, both must be configured with details of an NTP server. SIP-only deployments do not require the use of NTP for authentication. To configure the VCS with an NTP server, on the Time page enter the IP address or FQDN (or server address, if a DNS Domain Name has also been configured) of the NTP server to be used when synchronizing system time. • The NTP server field defaults to one of four NTP servers provided by TANDBERG, either: 0.ntp.tandberg.com, 1.ntp. tandberg.com, 2.ntp.tandberg.com or 3.ntp.tandberg.com. • The connection status to the NTP server is shown in the Status area. VCS time display Local time is used throughout the web interface. It is shown in the system information bar at the bottom of the screen and is used to set the timestamp that appears at the start of each line in the Event Log and Configuration Log. Internally, the VCS maintains its system time in UTC. It is based on the VCS's operating system time, which is synchronized using an NTP server if one is configured. If no NTP server is configured, the VCS uses its own operating system time to determine the time and date. Specifying your local Time zone lets the VCS determine the local time where the system is located. It does this by offsetting UTC time by the number of hours associated with the selected time zone. It also adjusts the local time to account for summer time (also known as daylight saving time). The Time page displays both UTC and local time in the Status area. Note that a UTC system timestamp is included at the end of each entry in the Event Log and Configuration Log. Time Login page The Login page page allows you to specify a message and image that will appear to users attempting to log in to the VCS. To go to the Login page page: • System configuration > Login page This feature is not configurable using the CLI. 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. The Image will appear to FindMe users and administrators when attempting to log in using the web interface.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance System configuration The SNMP page lets you configure the VCS’s SNMP settings: To go to the SNMP page: • System configuration > SNMP To configure SNMP settings using the CLI: • xConfiguration SNMP About SNMP Tools such as TANDBERG Management Suite (TMS) or HP OpenView may act as SNMP Network Management Systems (NMS). They allow you to monitor your network devices, including the VCS, for conditions that might require administrative attention. The VCS supports the most basic MIB-II tree (.1.3.6.1.2.1) as defined in RFC 1213 [23]. The information made available by the VCS includes the following: • system uptime • system name • location • contact • interfaces • disk space, memory, and other machine-specific statistics To allow the VCS to be monitored by an SNMP NMS (including TMS), you must Enable SNMP on the VCS and provide the name of the SNMP community within which it resides. You may optionally provide the name of a System contact and the physical Location of the system for reference by administrators when following up on queries. By default, SNMP is Disabled with a SNMP community name of public. ! 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. The VCS does not support SNMP traps or SNMP sets, therefore it cannot be managed using SNMP. SNMP About external managers An external manager is a remote system, such as the TANDBERG Management Suite (TMS), used to monitor events occurring on the VCS, for example call attempts, connections and disconnections. The use of an external manager is optional. Configuration The External manager page allows you to configure the VCS's external manager settings. To go to the External manager page: • System configuration > External manager To configure external manager settings using the CLI: • xConfiguration ExternalManager The options are: Address and path To use an external manager, you must configure the VCS with the IP address or host name and path of the external manager to be used. If you are using TMS as your external manager, use the default path of tms/public/external/management/SystemManagementService.asmx. Protocol This setting allows you to determine whether communications with the external manager are over HTTP or HTTPS. Certificate verification mode You may also require that the VCS verifies the certificate presented by the external manager by selecting a Certificate verification mode of On. If you do this, you must also add the certificate of the issuer of the external manager's certificate to the file containing the VCS's trusted CA certificates. This is done from the Security certificates page (Maintenance > Security certificates). External manager

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance System configuration Overview The VCS provides an Event Logging facility for troubleshooting and auditing purposes. The Event Log records information about such things as calls, registrations, and messages sent and received. The Logging page lets you: • specify the Log level to set the amount of information to record • copy the Event Log to a Remote syslog server To go to the Logging page: • System configuration > Logging To view the Event Log using the web interface: • Status > Logs > Event Log To view the Event Log using the CLI: • eventlog About Event Log levels All events have an associated level in the range 1-4, with Level 1 Events considered the most important. The table below gives an overview of the levels assigned to different events. See the Events and levels section for a complete list of all events that are logged by the VCS, and the level at which they are logged. Level Assigned Events Level 1 High-level events such as registration requests and call attempts. Easily human readable. For example: • call attempt/connected/disconnected • registration attempt/accepted/rejected Level 2 All Level 1 Events, plus: • logs of protocol messages sent and received (SIP, H.323, LDAP etc.) excluding noisy messages such as H.460.18 keepalives and H.245 video fast-updates Level 3 All Level 1 and Level 2 Events, plus: • protocol keepalives • call-related SIP signaling messages Level 4 The most verbose level: all Level 1, Level 2 and Level 3 Events, plus: • network level SIP messages Setting the Event Log level You can control which events are logged by the VCS by setting the log level. All events with a level numerically equal to and lower than the specified logging level are recorded in the Event Log. So, at Level 1, only Level 1 events are logged; at Level 2, both Level 1 and Level 2 events are logged, and so on. The default is 1. To set the log level: • System configuration > Logging • xConfiguration Log Level ! TANDBERG does not usually recommend logging at Level 3 or Level 4 as the Event Log holds a maximum of 2GB of data and logging at these levels on a busy system could cause the Event Log to be recycled too quickly. Changes to the Event Log level affect both the Event Log that you can view using the web interface, and the information that is copied to the remote log server (if any) that you have configured. Changes to the Event Log level are not retrospective. If you change the Event Log level, it will only affect what is logged from that point onwards. About remote logging The Event Log is always stored locally on the VCS. However, it is often convenient to collect copies of all Event Logs from various systems in a single location. A computer running a BSD-style syslog server, as defined in RFC 3164 [4], may be used as the central log server. Note that: • A VCS will not act as a central logging server for other systems. • Events are always logged locally (to the Event Log) regardless of whether or not remote logging is enabled. • The VCS may use any of the 23 available syslog facilities for different messages. Specifically, LOCAL0..LOCAL7 (facilities 16..23) are used by different components of the application software on the VCS. Enabling remote logging To enable remote logging, you must configure the VCS with the address of the central log server to which the Event Log will be copied. To do this: • System configuration > Logging • xConfiguration Log Server Address Logging

This section provides information on the pages that appear under the Protocols, Registrations and Authentication sub-menus of the VCS Configuration menu. These pages allow you to configure the functionality of the VCS in each of these areas. This section includes the following information: • an overview of H.323 and the H.323 configuration options available on the VCS • an overview of SIP and the SIP configuration options available on the VCS • how to configure the VCS to act as a SIP to H.323 gateway • how to control registrations on the VCS using authentication and Allow Lists and Deny Lists. VCS configuration TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance H.323 About H.323 on the VCS The VCS supports the H.323 protocol: it is an H.323 gatekeeper. It will also provide interworking between H.323 and SIP, translating between the two protocols to enable endpoints that only support one of these protocols to call each other. In order to support H.323, the H.323 mode must be enabled. Using the VCS as an H.323 gatekeeper As an H.323 gatekeeper, the VCS accepts registrations from H.323 endpoints and provides call control functions such as address translation and admission control. To enable the VCS as an H.323 Gatekeeper, you must ensure that H.323 mode is set to On (VCS configuration > Protocols > H.323). 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 overview 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). • 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. • If the mode is set to manual, you must specify the IP address of the VCS with which you wish your endpoint to register, and the endpoint will attempt to register with that VCS only.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance H.323 The H.323 page allows you to enable and disable H.323 system- wide on the VCS, and configure H.323-specific ports and settings. To go to the H.323 page: • VCS configuration > Protocols > H.323 To configure H.323 using the CLI: • xConfiguration H323 Enabling H.323 H.323 support is On by default. To enable or disable H.323 on the VCS, use the H.323 Mode setting. Configuring H.323 ports 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. You can configure the following H.323 ports: Registration UDP port The listening port for H.323 UDP registrations. Default is 1719. Call signaling TCP port The listening port for H.323 call signaling. Default is 1720. Call signaling port range start Specifies the lower port in the range used by H.323 calls after they are established. Default is 15000. Call signaling port range end Specifies the upper port in the range used by H.323 calls after they are established. Default is 19999. ! The call signalling port range must be great enough to support all the required concurrent calls. Registration conflict mode 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: • Two endpoints at different IP addresses are attempting to register using the same alias. • 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. You can determine how the VCS will behave in this situation by configuring the Registration conflict mode. The options are: Reject: denies the new registration. Overwrite: deletes the original registration and replaces it with the new registration. The default is Reject. Time to live H.323 endpoints must periodically re-register with the VCS in order to confirm that they are still functioning. The VCS allows you to configure the interval (in seconds) between these re- registrations, known as the Time to live. The default is 1800. Some older endpoints do not support the ability to periodically re-register with the system. In this case, and in any other situation where the system has not had a confirmation from the endpoint within the specified period, it will send an IRQ to the endpoint to verify that it is still functioning. Call time to live When the endpoint is in a call, the VCS will periodically poll it to confirm whether it is still in the call. If the endpoint does not respond, the call will be disconnected. The VCS allows you to configure the interval (in seconds) at which the endpoints are polled, known as the Call time to live. The default is 120. The system will poll endpoints in a call regardless of whether the call type is traversal or non-traversal. Auto discover The VCS has an Auto discover setting which determines whether it will respond to Gatekeeper Discovery Requests sent out by endpoints. The default is On. To prevent H.323 endpoints being able to register automatically with the VCS, set Auto discover to Off. This will mean that endpoints will be able to register with the VCS only if they have been configured with the VCS’s IP address. Caller ID You can specify whether the Caller ID displayed on the destination endpoint includes or excludes the prefix of the ISDN gateway when displaying the caller's E.164 number. Including the prefix allows the recipient to directly return the call. Configuring H.323

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance SIP About SIP on the VCS The VCS supports the SIP protocol. It can act as a: • SIP registrar • SIP proxy • 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, SIP mode must be enabled and at least one of the SIP transport protocols (UDP, TCP or TLS) must be active. Using the VCS as a SIP registrar For a SIP endpoint to be contactable via its registered alias, it must register its location with a SIP registrar. The VCS can act as a SIP registrar for up to 20 domains. SIP aliases always take the form username@domain. To make the VCS act as a SIP registrar, you must configure it with the SIP domains for which it will be authoritative. It will then accept registration requests for any endpoints attempting to register with an alias that includes that domain. If no domains are configured, the VCS will not act as a SIP registrar but it may proxy the request to another registrar depending upon the SIP registration proxy mode setting. Using the VCS as a SIP Presence Server The VCS supports the SIP-based SIMPLE protocol. It can act as a: • Presence Server • Presence User Agent for any of the SIP domains for which it is authoritative. For full information on how to use the VCS as a SIP Presence server, see the Presence section. Using the VCS as a SIP proxy server The VCS can act 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: • the SIP registration proxy mode setting • the presence of Route Set information in the request header • whether the proxy server from which the request was received is a neighbor of the VCS A Route Set specifies the path to take when requests are proxied between an endpoint and its registrar. For example, when a REGISTER request is proxied by a VCS, the VCS adds a path header component to the request. This signals that calls to that endpoint should be routed through the VCS. This is usually required in situations where firewalls exist and the signalling must follow a specified path to successfully traverse the firewall. For more information about path headers, see RFC 3327 [10]. When the VCS proxies a request that contains Route Set information, it forwards it directly to the URI specified in the path. Any call processing rules configured on the VCS are bypassed. This may present a security risk if the information in the Route Set cannot be trusted. For this reason, you can configure how the VCS proxies requests that contain Route Sets by setting the SIP registration proxy mode as follows: • Off: requests containing Route Sets are rejected. This setting provides the highest level of security. • Proxy to known only: requests containing Route Sets are proxied only if the request was received from a known zone. • 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 has no SIP domains configured, or it receives a registration request for a domain for which it is not acting as a Registrar, then the VCS may proxy the registration request. This depends on the SIP registration proxy mode setting, as follows: • Off: the VCS does not proxy any registration requests. They are rejected with a “403 Forbidden” message. • 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. • Proxy to any: this is the same as Proxy to known only but for all zone types i.e. it also includes ENUM and DNS zones. Accepting proxied registration requests If the VCS receives a proxied registration request, in addition to the VCS's standard registration controls, you can also control whether the VCS accepts the registration depending upon the zone through which the request was received. You do this through the Accept proxied registrations setting when configuring a zone. Proxied registrations are classified as belonging to the zone they were last proxied from. This is different from non-proxied registration requests which are assigned to a subzone within the VCS. SIP endpoint registration A SIP endpoint registers with the VCS (or another SIP registrar) to identify its current location and thus enable it to receive calls. To register your SIP endpoint with a SIP registrar, enter the IP address or FQDN of the SIP registrar into your SIP endpoint. To use the VCS as the SIP registrar for a particular endpoint, the VCS must be configured with the SIP domain used by the endpoint (VCS configuration > Protocols > SIP > Domains). Movi v2.0 (or later) clients As for any other SIP endpoint, the VCS acts as a SIP registrar and SIP proxy for TANDBERG Movi™ v2.0 (or later) clients - no other special support or configuration is required on the VCS. SIP overview

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance SIP The SIP page is used to enable and disable SIP system-wide on the VCS, and to configure SIP-specific ports and settings. To go to the SIP page: • VCS configuration > Protocols > SIP > Configuration To configure SIP using the CLI: • xConfiguration SIP Enabling SIP SIP support is On by default. To enable and disable SIP functionality (i.e. SIP registrar and SIP proxy services) on the VCS, use the SIP mode setting. SIP registration expiry SIP endpoints must periodically re-register with the SIP registrar in order to prevent their registration expiring. The Registration expire delta setting defines the interval within which SIP endpoints must register with the VCS. The default is 60. This applies only to endpoints registered with the VCS. It does not apply to endpoints whose registrations are proxied through the VCS. SIP registration proxy mode This specifies how proxied registrations and requests containing Route Sets are handled. Off: registration requests are not proxied (but are still permitted locally if the VCS is authoritative for that domain). Requests with existing Route Sets are rejected. Proxy to known only: registration requests are proxied in accordance with existing call processing rules, but only to known neighbor, traversal client and traversal server zones. Requests containing Route Sets are proxied only if they were received from a known zone. Proxy to any: registration requests are proxied in accordance with existing call processing rules to all known zones. Requests containing Route Sets are always proxied. The default is Off. SIP protocols and ports The VCS supports SIP over UDP, TCP and TLS transport protocols. You can configure whether or not incoming and outgoing connections using each protocol are supported, and if so, the ports on which the VCS listens for such connections. This is done using the Mode and Port settings for each protocol. The default Mode for each protocol is On; the default ports are: • UDP port: 5060 • TCP port: 5060 • TLS port: 5061 At least one of the transport protocols must be set to a Mode of On for SIP functionality to be supported. You can also specify the range of ports the VCS uses when TCP and TLS connections are established by configuring the TCP outbound port start and TCP outbound port end settings. The default range is 25000 to 29999. This range must be sufficient to support all required concurrent connections. Session timers You can configure SIP session expiry timers through the Session refresh interval and Minimum session refresh interval settings. For more information on session timers, refer to RFC 4028 [14]. SIP device interoperability You can configure the following device interoperability settings: Require UDP BFCP mode Controls whether the VCS requires the use of the com.tandberg. udp.bfcp extension for endpoints that support it. Require Duo Video mode Controls whether the VCS requires the use of the com.tandberg. .sdp.duo.enable extension for endpoints that support it. The default settings for these modes are not supported by some neighbor systems so make sure you select the appropriate Zone profile when configuring zones. Configuring SIP The Domains page lists the SIP domains for which the VCS is authoritative, and allows you to add, edit and delete SIP domains. To go to the Domains page: • VCS configuration > Protocols > SIP > Domains. To configure SIP domains using the CLI: • xCommand DomainAdd • xCommand DomainDelete • xConfiguration SIP Domains The VCS will act as a SIP registrar and Presence Server for all these domains, and will accept registration requests for any SIP endpoints attempting to register with an alias that includes any of these domains. SIP domains

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Interworking The VCS is able to act as a gateway between SIP and H.323, translating calls from one protocol to the other. This is known as “interworking”. By default, the VCS acts as a SIP-H.323 and H.323-SIP gateway but only if at least one of the endpoints that are involved in the call is locally registered. You can change this setting so that the VCS will act as a SIP-H.323 gateway regardless of whether the endpoints involved are locally registered. You also have the option to disable interworking completely. The VCS uses the protocol of the incoming call when searching a zone for a given alias. If the search is unsuccessful the VCS may then search the same zone again using the alternative protocol, depending on where the search came from and the Interworking mode (VCS configuration > Protocols > Interworking). If the request has come from a neighboring system and Interworking mode is set to RegisteredOnly, the VCS will search 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). If Interworking mode is set to On, or the request has come from a locally registered endpoint, the VCS will search the Local Zone and all external zones using both protocols. Calls for which the VCS acts as a SIP to H.323 gateway are traversal calls. They will therefore require a traversal call license. Overview Configuring interworking The Interworking page is used to configure whether or not the VCS acts as a gateway between SIP and H.323 calls. To go to the Interworking page: • VCS configuration > Protocols > Interworking To configure interworking using the CLI: • xConfiguration Interworking Mode H.323 <-> SIP interworking mode The options for this setting are: Off: the VCS will not act as a SIP-H.323 gateway. RegisteredOnly: the VCS will act as a SIP-H.323 gateway but only if at least one of the endpoints is locally registered. On: the VCS will act as a SIP-H.323 gateway regardless of whether the endpoints are locally registered. ! You are recommended to leave this setting as RegisteredOnly (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. Enabling SIP endpoints to dial H.323 numbers SIP endpoints can only make calls in the form of URIs - e.g. name@domain. If the caller does not specify a domain when placing the call, the SIP endpoint will automatically append its own domain to the number that is dialed. So if you dial 123 from a SIP endpoint, the search will be placed for 123@domain. If the H.323 endpoint being dialed is just registered as 123, then the VCS won't be able to locate the alias 123@domain and the call will fail. The solutions are to either: 1. Ensure all your endpoints, both H.323 and SIP, register with an alias in the form name@domain. 2. Create a pre-search transform on the VCS that strips the @domain portion of the alias for those URIs that are in the form of number@domain. Refer to the Pre-search transforms section for information on how to configure pre-search transforms, and to the Stripping @domain for dialing to H.323 numbers section for an example of how to do this.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control Endpoint registration For an endpoint to use the TANDBERG 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. Two separate mechanisms are provided: • a device authentication process based on the username and password supplied by the endpoint • a simple Registration Restriction Policy that uses Allow Lists or Deny Lists to specify which aliases can and cannot register with the VCS, and the ability to control registrations based on IP addresses and subnet ranges through the specification of subzone membership rules and subzone registration policies. It is possible to use both 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. This section gives an overview of how endpoints and other devices register with the VCS, and then describes the two mechanisms by which registrations can be restricted. For specific information about how registrations are managed across peers in a cluster, see the Sharing registrations across peers section. Registration overview 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. The TANDBERG MPS and TANDBERG Content Server (TCS) both support Expressway. They can therefore register directly with a VCS Expressway for firewall traversal. Registrations on a VCS Expressway If a traversal-enabled endpoint registers directly with a VCS Expressway, the VCS Expressway will provide the same services to that endpoint as a VCS Control, with the addition of firewall traversal. Traversal-enabled endpoints include all TANDBERG 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: • whether the endpoint is using SIP or H.323 • the endpoint’s position in relation to the firewall • whether there is a NAT in use • whether the endpoint is using a public IP address For example, if an endpoint is behind a NAT or firewall, it may not be able to receive incoming calls and may not be able to receive media for calls it has initiated. SIP endpoints can also work behind a NAT but can only receive video if they send it as well. To ensure firewall traversal will work successfully for H.323 endpoints behind a NAT, the endpoint must be traversal-enabled.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control Registration overview 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. SIP SIP endpoints must find a SIP Registrar with which to register. The SIP registrar maintains a record of the endpoint’s details against the endpoint’s Address of Record (AOR). When a call is received for that AOR, the SIP registrar refers to the record in order to find the endpoint to which it corresponds. (Note that the same AOR can be used by more than one SIP endpoint at the same time.) The SIP registrar will only accept registrations for domains for which it is authoritative. 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). • If the Server Discovery mode is set to automatic, the endpoint will send a REGISTER message to its SIP Server. This will be forwarded (via DNS if necessary) to the registrar 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 [email protected], the request will be sent to the registrar authoritative for the domain example.com. • If the Server Discovery mode is set to manual, the user must specify the IP address or FQDN of the registrar with which they wish to register, and the endpoint will attempt to register with that registrar only. The VCS is a SIP Server for endpoints in its local zone, and can also act as a SIP registrar. • If the VCS is acting as the endpoint’s SIP Server and SIP registrar, when the registration request is received from the endpoint it will be accepted by the VCS and the endpoint will be registered and able to receive inbound calls. See the Using the VCS as a SIP registrar section for more information. • If the VCS is acting as the endpoint’s SIP server but is not a SIP registrar, it will proxy the registration request. See the Proxying registration requests section for more information. H.323 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). • 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. • If the mode is set to manual, you must specify the IP address of the VCS with which you wish your endpoint to register, and the endpoint will attempt to register with that VCS only. Preventing automatic registrations You can prevent H.323 endpoints being able to register automatically with the VCS by disabling Auto Discovery on the VCS. This setting is accessed using: • VCS configuration > Protocols > H.323. You will be taken to the H.323 page. • xConfiguration H323 Gatekeeper AutoDiscovery The Auto Discovery setting determines whether the VCS responds to the Gatekeeper Discovery requests sent out by endpoints. The options are as follows: On: the VCS will respond to Gatekeeper discovery requests. Off: the VCS will reject Gatekeeper discovery requests. H.323 endpoints will be able to register with the VCS only if their Gatekeeper Discovery setting is Manual and they have entered the IP address of the VCS.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control Device authentication The Device authentication configuration page controls whether systems attempting to communicate with the VCS must authenticate with it first, and if so, the type of database used by the VCS to store the authentication credentials used by these systems. To go to the Device authentication configuration page: • VCS configuration > Authentication > Devices > Configuration To configure authentication using the CLI: • xConfiguration Authentication Authentication mode The VCS can be configured to use a username and password-based challenge-response scheme to determine whether it will permit communications from other systems. This process is known as authentication, and is controlled using the Authentication mode setting. The options are: On: systems attempting to communicate with the VCS, including endpoints attempting to send registration requests to the VCS, must first authenticate with it. For H.323, any credentials in the message are checked against the authentication database. The message is allowed if the credentials match, or if there are no credentials in the message. For SIP, any messages originating from an endpoint in a local domain will be authenticated. Off: incoming messages are not authenticated. The default is Off. ! Accurate timestamps play an important part in authentication, helping to guard against replay attacks. For this reason, if you are using authentication, both the VCS and the endpoints must use an NTP server to synchronize their system time. See the About the NTP server section for information on how to configure this for the VCS. Authentication database When Authentication mode is On, endpoints must authenticate with the VCS before they can register. In order to authenticate successfully, the endpoint must supply the VCS with a username. For TANDBERG endpoints using H.323, the username is the endpoint’s Authentication ID; for TANDBERG endpoints using SIP it is the endpoint’s Authentication username. For details of how to configure endpoints with a username and password, please consult the endpoint manual. To verify the identity of the device, the VCS needs access to a database on which all authentication credential information (usernames, passwords, and other relevant information) is stored. This database may be located either locally on the VCS, or on an LDAP Directory Server. The VCS looks up the endpoint’s username in the database and retrieves the authentication credentials for that entry. If the credentials match those supplied by the endpoint, the registration is allowed to proceed. The Database type setting determines which database the VCS will use during authentication: Local database: the local authentication database is used. You must configure the local authentication database to use this option. LDAP database: a remote LDAP database is used. You must configure the LDAP server to use this option. The default is LocalDatabase. ! If the VCS is a traversal server, you must ensure that each traversal client’s authentication credentials are entered into the selected database. The VCS supports the ITU H.235 specification [1] for authenticating the identity of H.323 network devices with which it communicates.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control Device authentication using LDAP Overview If the VCS is using an LDAP server for authentication, the process is as follows: 1. The endpoint presents its username and authentication credentials (these are generated using its password) to the VCS, and the aliases with which it wants to register. 2. The VCS looks up the username in the LDAP database and obtains the authentication and alias information for that entry. 3. If the authentication credentials match those supplied by the endpoint, the registration will continue. The VCS then determines which aliases the endpoint is allowed to attempt to register with, based on the alias origin setting. For H.323 endpoints, you can use this setting to override the aliases presented by the endpoint with those in the H.350 directory, or you can use them in addition to the endpoint’s aliases. For SIP endpoints, you can use this setting to reject a registration if the endpoint’s AOR does not match that in the LDAP database. Configuring the LDAP server directory The directory on the LDAP server should be configured to implement the ITU H.350 specification [2] to store credentials for devices with which the VCS communicates. The directory should also be configured with the aliases of endpoints that will register with the VCS. See the LDAP configuration for device authentication appendix for instructions on configuring LDAP servers. Configuring LDAP server settings The Device LDAP Configuration page is used to configure a connection to the LDAP database for device authentication. To go to the Device LDAP Configuration page: • VCS configuration > Authentication > Devices > LDAP configuration To configure these settings using the CLI: • xConfiguration LDAP • xConfiguration Authentication LDAP LDAP server The IP address or FQDN (or server address, if a DNS Domain Name has also been configured) of the LDAP server. Port The IP port of the LDAP server. The default is 389. Encryption Determines whether the connection to the LDAP server is encrypted using Transport Layer Security (TLS). TLS: TLS encryption is used for the connection to the LDAP server. Off: no encryption is used. The default is Off. The link Upload a CA Certificate file for TLS takes you to the Security certificates page, where you can upload a file containing the trusted CA certificate for the LDAP server. This is required for encrypted connections between the VCS and the LDAP server. See the Security certificates section for more information. User DN The user distinguished name used by the VCS when binding to the LDAP server. Password The password used by the VCS when binding to the LDAP server. Base DN The area of the directory on the LDAP server to search for credential information. This should be specified as the Distinguished Name (DN) in the LDAP directory under which the H.350 objects reside. Alias origin This setting determines the aliases with which the endpoint will attempt to register. The options are: LDAP: for SIP registrations the AOR presented by the endpoint is registered providing it is listed in the LDAP database for the endpoint's username. For H.323 registrations: • At least one of the aliases presented by the endpoint must be listed in the LDAP database for that endpoint's username. If none of the presented aliases are listed it is not allowed to register. • The endpoint will register with all of the aliases (up to a maximum of 20) listed in the LDAP database. Aliases presented by the endpoint that are not in the LDAP database will not be registered. • If no aliases are listed in the LDAP database, the endpoint will register with all the aliases it presented. • If no aliases are presented by the endpoint, it will register with all the aliases listed in the LDAP database for its username. MCUs are treated as a special case. They register with the presented aliases and ignore any aliases in the LDAP database. (This is to allow MCUs to additively register aliases for conferences.) Combined: the aliases presented by the endpoint are used in addition to any listed in the LDAP database for the endpoint’s username. In other words, this is the same as for LDAP, except that if an endpoint presents an alias that is not in the LDAP database, it will be allowed to register with that alias. Endpoint: the aliases presented by the endpoint are used; any in the LDAP database are ignored. If no aliases are presented by the endpoint, it is not allowed to register. The default is LDAP. To use the LDAP database for device authentication, you must also go to the Device authentication configuration page and select a Database type of LDAP database.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control Overview The local authentication database is included as part of your VCS system. The database can hold up to 2,500 entries, each consisting of a name and password. Name The username used by the endpoint when authenticating with the VCS. Password The password used by the endpoint when authenticating with the VCS. Configuring the local authentication database The Local authentication database page lists and allows you to manage the credentials stored in the local authentication database. To go to the Local authentication database page: • VCS configuration > Authentication > Devices > Local database To manage the local authentication database using the CLI: • xConfiguration Authentication Credential • xCommand CredentialAdd • xCommand CredentialDelete You can sort these entries by clicking on the Name column heading. View/Edit Click View/Edit to make changes to an existing entry. You are taken to the Edit credential page. Delete Click Delete to remove a credential from the list. New Select New to add a new entry to the local authentication database. You are taken to the Create credential page. The same credentials can be used by more than one endpoint - you do not need to have a separate entry in the database for each endpoint. Authentication using a local database Outbound connection credentials The Outbound connection credentials page is used to configure a username and password that the VCS will use whenever it is required to authenticate with external systems. For example, when the VCS is forwarding an invite from an endpoint to another VCS, that other system may have authentication enabled and will therefore require your local VCS to provide it with a username and password. Note that these settings are not used by traversal client zones. Traversal clients, which must always authenticate with traversal servers before they can connect, configure their connection credentials per traversal client zone. To go to the Outbound connection credentials page: • VCS configuration > Authentication > Outbound connection credentials To configure authentication using the CLI: • xConfiguration Authentication Password • xConfiguration Authentication UserName Authenticating with external systems

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control About alias registration After the authentication process (if required) has been completed, the endpoint will then attempt to register its alias(es) with the VCS. H.323 When registering, the H.323 endpoint presents the VCS with one or more of the following: • one or more H.323 IDs • one or more E.164 aliases • one or more URIs Users of other registered endpoints can then call the endpoint by dialing any of these aliases. 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. 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. 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. 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. The reasons for this could include: • two endpoints at different IP addresses are attempting to register using the same alias • a single endpoint has previously registered using a particular alias. The IP address allocated to the endpoint, or the port the endpoint uses to communicate with the VCS, then changes, and the endpoint is attempting to re-register using the same alias. You can determine how the VCS will behave in this situation by configuring the Registration Conflict Mode, using either: • VCS configuration > Protocols > H.323 You will be taken to the H.323 page. • xConfiguration H323 Gatekeeper Registration ConflictMode The options are: Reject: the registration from the new IP address will be rejected. This is useful if your priority is to prevent two users registering with the same alias. Overwrite: the existing registration will be overwritten using the new IP address. This is useful if your network is such that endpoints are often allocated new IP addresses, because it will prevent unwanted registration rejections. The default is Reject. 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, from the Registration details page (Status > Registrations > by Device and click a Name; or Status > Registrations > by Alias and click an Alias; or Status > Registrations > History and click an Alias) you will have an option to block the registration. This will add all the aliases used by that endpoint to the Deny List. Registering aliases

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control About Allow and Deny Lists When an endpoint attempts to register with the VCS it presents a list of aliases. You can control which endpoints are allowed to register by setting the Restriction Policy to Allow List or Deny List and then including 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 Registration 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 Registration 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. Allow and Deny Lists Activating use of Allow or Deny Lists The Registration Configuration page allows you to specify whether an Allow List or a Deny List should be used when determining which endpoints may register with the VCS. To go to the Registration Configuration page: • VCS configuration > Registration > Configuration. To configure this using the CLI: • xConfiguration Registration RestrictionPolicy The Restriction policy option specifies the policy to be used when determining which endpoints may register with the VCS. The options are: None: any endpoint may register. AllowList: only those endpoints with an alias that matches an entry in the Allow List may register. DenyList: all endpoints may register, unless they match an entry on the Deny List. The default is None. ! If you have elected to use an Allow List or a Deny List, you must also go to the appropriate configuration page (VCS configuration > Registration > Allow List or VCS configuration > Registration > Deny List) to create the list to be used. Removing existing registrations After an Allow List or Deny List 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 an Allow List or Deny List. To manually remove a registration, go to Status > Registrations > By device, select the registration(s) you want to remove, and click Unregister. 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: • 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 Allow List or Deny List. If this is the case, the registration will not expire at the end of the registration timeout period and must be removed manually. • SIP re-registrations contain the same information as the initial registrations so will be filtered by the Allow List and Deny List. 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 (VCS configuration > Protocols > SIP > Configuration) and the Time to Live setting for H.323 (VCS configuration > Protocols > H.323).

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Registration control Allow and Deny Lists Using the Allow and Deny Lists Allow List The Registration Allow List page lets you view and manage the entries in the Allow List. To go to the Registration Allow List page: • VCS configuration > Registration > Allow List. To manage the Allow List using the CLI: • xCommand AllowListAdd • xConfiguration Registration AllowList Deny List The Registration Deny List page lets you view and manage the entries in the Deny List. To go to the Registration Deny List page: • VCS configuration > Registration > Deny List. To manage the Deny List using the CLI: • xCommand DenyListAdd • xConfiguration Registration DenyList Managing entries in the Allow and Deny Lists The Registration Allow List and Registration Deny List pages both work in the same way: Pattern The pattern against which an alias is compared. Type The way in which the Pattern must match the alias for the registration to be allowed/denied. Options are: Exact: the alias must match the Pattern exactly. Prefix: the alias must begin with the Pattern. Suffix: the alias must end with the Pattern. Regex: the Pattern is a regular expression. See the Regular expression reference Appendix for further information. You can test whether a pattern matches a particular alias by using the Check pattern page (Maintenance > Tools > Check pattern). Description An optional free-form description of the entry. View/Edit Click View/Edit to make changes to an existing entry. New Click New to add a new entry to the list. Delete Click Delete to remove the pattern from the list. After configuring the Allow or Deny List, you must set the restriction policy (VCS configuration > Registration > Configuration) to either Allow List or Deny List for it to be activated.

This section begins with an overview of all the different types of subzones and zones and how these fit into the overall structure of your video communication network. It then provides information on the pages that appear under the Local Zone and Zones sub-menus of the VCS Configuration menu. These pages describe how to: • configure the VCS’s Local Zone (which is made up of subzones, including the Traversal Subzone and Default Subzone) • create and configure external zones to communicate with other systems and endpoints, including other VCSs, Gatekeepers, Border Controllers or SIP devices, and endpoints contactable via DNS or ENUM dialing • design a dial plan Zones and neighbors TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Introduction The most basic implementation of a TANDBERG video communications network is a single VCS connected to the internet with one or more endpoints registered to it. However, depending on the size and complexity of your enterprise the VCS may be part of a network of endpoints, other VCSs and other network infrastructure devices, with one or more firewalls between it and the internet. In such situations you may wish to apply restrictions to the amount of bandwidth used by and between different parts of your network. This section will give you an overview of the different parts of the video communications network and the ways in which they can be connected. This information should allow you to configure your VCS to best suit your own infrastructure. Example network diagram The diagram opposite shows the different components of a VCS (i.e. subzones and zones) and how they interrelate. Using a VCS Control as the example Local Zone, it shows that it is made up of a number of subzones which are all connected by links. The Local Zone is also connected to external VCSs and to the internet via different types of zones. All these components are described in more detail in the sections that follow. About your video communications network VCS CONTROL VCS EXPRESSWAY Internet VCS CONTROL LOCAL ZONE Traversal Subzone Default Subzone DNS Zone ENUM Zone Neighbor Zone Traversal Client Zone Neighbor Zone Traversal Server Zone Subzone Default Zone

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Local Zone and subzones The collection of all endpoints, gateways, MCUs and Content Servers registered with the VCS make up its Local Zone. The Local Zone is divided into subzones. These include an automatically created Default Subzone and up to 1000 manually configurable subzones. When an endpoint registers with the VCS it is allocated to an appropriate subzone based on subzone membership rules. These rules specify the range of IP addresses or alias pattern matches for each subzone. If an endpoint’s IP address or alias does not match any of the membership rules, it is assigned to the Default Subzone. The Local Zone may be independent of network topology, and may comprise multiple network segments. The VCS also has two special types of subzones: • the Traversal Subzone, which is always present (see the About the Traversal Subzone section for more information) • the Cluster Subzone, which is always present but only used when your VCS is part of a cluster (see the Cluster Subzone section for more information) Overview Bandwidth management The Local Zone’s subzones are used for bandwidth management. After you have set up your subzones you can apply bandwidth limits to: • individual calls between two endpoints within the subzone • individual calls between an endpoint within the subzone and another endpoint outside of the subzone • the total of calls to or from endpoints within the subzone For full details of how to create and configure subzones, and apply bandwidth limitations to subzones including the Default Subzone and Traversal Subzone, see the chapter on Bandwidth control. Local Zone searches One of the functions of the VCS is to route a call received from a locally registered endpoint or external zone to its appropriate destination. Calls are routed based on the address or alias of the destination endpoint. When searching for a destination endpoint, the VCS searches its Local Zone and external zones. You can prioritize the order in which these zones are searched, and filter the search requests sent to each zone, based on the address or alias being searched for. This allows you to reduce the potential number of search requests sent to the Local Zone and out to external zones, and speed up the search process. For further information on how to configure search rules for the Local Zone, see the Configuring search and zone transform rules section. Configuring the Local Zone and its subzones

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Local Zone and subzones Configuring the Traversal Subzone ports The VCS allows you to configure the range of ports used for the media in traversal calls. A single traversal call can consist of up to 5 types of media (audio, video, far end camera control, dual streams and BFCP) and each type of media may require a pair of ports – for example, audio and video each require one port for RTP, and one for RTCP. Separate pairs of ports are required for the inbound and outbound portions of a call. A single traversal call can therefore take up to 20 ports. The default range for the ports to be used for media is 50000 - 52399 UDP, but these can be changed to any values between 1024 and 65533. Ports are allocated from this range in pairs, with the first port number of each pair being an even number. Therefore the range must start with an even number and end with an odd number. To configure the ports used for media in traversal calls: • VCS configuration > Local Zone > Traversal Subzone • xConfiguration Traversal Media Port Start • xConfiguration Traversal Media Port End ! You must ensure that the port range is large enough to support the maximum number of traversal calls available on your VCS. A single traversal call can take up to 20 ports (5 pairs in each direction). So for example, if your VCS is licensed for 5 traversal calls you must ensure that the range of ports configured for traversal media is at least 100. If you add extra traversal calls to your system, you must also ensure that the range of ports available is sufficient. The Traversal Subzone is a conceptual subzone; no endpoints can be registered to it, but all traversal calls (calls for which the VCS takes the media in addition to the signaling) pass through it. The Traversal Subzone's purpose is to control the amount of bandwidth used by traversal calls, as these can be particularly resource-intensive. See the chapter on Bandwidth control and the section on Bandwidth consumption of traversal calls for more information on controlling the bandwidth of traversal calls. What are traversal calls? A traversal call is any call passing through the VCS that includes both the signaling (information about the call) and media (voice and video). The only other type of call is a non-traversal call, where the signaling passes through the VCS but the media goes directly between the endpoints (or between one endpoint and another VCS in the call route, or between two VCSs in the call route). The following types of calls require the VCS to take the media. They are classified as traversal calls and will always pass through the Traversal Subzone: • firewall traversal calls, where the local VCS is either the traversal client or traversal server • calls that are gatewayed (interworked) between H.323 and SIP on the local VCS • calls that are gatewayed (interworked) between IPv4 and IPv6 on the local VCS • for VCSs with Dual Network Interfaces enabled, calls that are inbound from one LAN port and outbound on the other • a SIP to SIP call when one of the participants is behind a NAT (unless both endpoints are using ICE for NAT traversal) All such calls require a traversal call license each time they pass through the Traversal Subzone. Traversal calls use more resource than non-traversal calls, and the numbers of each type of call are licensed separately. The VCS has one license for the maximum number of concurrent traversal calls it can take, and another for the maximum number of concurrent non-traversal calls. You can increase the number of each type of call available on your VCS by purchasing and installing the appropriate option key. Note that a non-traversal call on a VCS Expressway will consume a traversal license if there are no non-traversal call licenses available. A call is “traversal” or “non-traversal” from the point of view of the VCS through which it is being routed at the time. A call between two endpoints may pass through two or more VCSs. Some of these VCSs may just take the signaling, in which case the call will be a non-traversal call for that VCS. Other VCSs in the route may need to take the media as well, and so the call will count as a traversal call on that particular VCS. Traversal Subzone

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones A zone is a collection of endpoints, either all registered to a single system (for example a TANDBERG VCS, gatekeeper, or TANDBERG Border Controller), or located in a certain way such as via an ENUM or DNS lookup. Zones are used to: • control through links whether calls can be made between your local subzones and these other zones • manage the bandwidth of calls between your local subzones and endpoints in other zones • search for aliases that are not registered locally You can configure up to 1000 zones of five different types. The VCS also has a non- configurable Default Zone. See the Zone configuration sections for information on the configuration options available for all zone types. See the Configuring search and zone transform rules section for information on including zones as targets for search rules. About zones To traverse a firewall, the VCS must be connected with a traversal server (for example a TANDBERG VCS Expressway or a TANDBERG Border Controller). In this situation your local VCS is a traversal client, so you create a connection with the traversal server by creating a traversal client zone on your local VCS. You then configure the client zone with details of the corresponding zone on the traversal server. (The traversal server must also be configured with details of the VCS client zone.) After you have neighbored with the traversal server you can: • use the neighbor as a traversal server • query the traversal server about its endpoints • apply transforms to any queries before they are sent to the traversal server • control the bandwidth used for calls between your local VCS and the traversal server See the Configuring traversal client zones section for information on the specific configuration options available. A VCS Expressway is able to act as a traversal server, providing firewall traversal on behalf of traversal clients (for example, VCS Controls or gatekeepers). In order to act as a traversal server, the VCS Expressway must have a special type of two-way relationship with each traversal client. To create this connection, you create a traversal server zone on your local VCS Expressway and configure it with the details of the corresponding zone on the traversal client. (The client must also be configured with details of the VCS Expressway.) After you have neighbored with the traversal client you can: • provide firewall traversal services to the traversal client • query the traversal client about its endpoints • apply transforms to any queries before they are sent to the traversal client • control the bandwidth used for calls between your local VCS and the traversal client See the Configuring traversal server zones section for information on the specific configuration options available. Traversal client-server zone relationships must be two-way. For firewall traversal to work, the traversal server and the traversal client must each be configured with the other’s details. (See the Quick guide to VCS traversal client - server configuration section for more information.) The client and server will then be able to communicate over the firewall and query each other. A neighbor zone could be a collection of endpoints registered to another system (e.g. TANDBERG VCS, gatekeeper, or TANDBERG Border Controller), or it could be a SIP device (for example Microsoft Office Communications Server (OCS) 2007). The other system or SIP device is referred to as a neighbor. Neighbors can be part of your own enterprise network, part of a separate network, or even standalone systems. You create a neighbor relationship with the other system by adding it as a neighbor zone on your local VCS. After you have added it, you can: • query the neighbor about its endpoints • apply transforms to any requests before they are sent to the neighbor • control the bandwidth used for calls between your local VCS and the neighbor zone See the Configuring neighbor zones section for information on the specific configuration options available. Neighbor zone relationship definitions are one-way. Adding a system as a neighbor to your VCS does not automatically make your VCS a neighbor of that system. Inbound calls from any configured neighbor are identified as coming from that neighbor. Traversal client zone Traversal server zone Neighbor zone

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones DNS zones allow you to locate endpoints via a DNS lookup. You can create one or more search rules for DNS zones based on pattern matching of the endpoints’ aliases. After you have configured one or more DNS zones, you can: • apply transforms to alias search requests directed to that group of endpoints • control the bandwidth used for calls between your local VCS and each group of DNS endpoints See the Configuring DNS zones section for information on the configuration options available. ENUM zone Any incoming calls from endpoints or other devices that are not recognized as belonging to any of the existing configured zones are deemed to be coming from the Default Zone. The VCS comes pre-configured with the Default Zone and default links between it and both the Default Subzone and the Traversal Subzone. The purpose of the Default Zone is to manage incoming calls from unrecognized endpoints to the VCS. You can do this by: • deleting the default links; this prevents any incoming calls from unrecognized endpoints • applying pipes to the default links; this lets you control the bandwidth consumed by incoming calls from unrecognized endpoints The Default Zone has no configuration options. The default links can be reinstated at any time by using the command: xCommand DefaultLinksAdd ENUM zones allow you to locate endpoints via an ENUM lookup. You can create one or more search rules for ENUM zones based on the ENUM DNS suffix used and/or by pattern matching of the endpoints’ aliases. After you have configured one or more ENUM zones, you can: • apply transforms to alias search requests directed to that group of endpoints • control the bandwidth used for calls between your local VCS and each group of ENUM endpoints See the Configuring ENUM zones section for information on the configuration options available. See the ENUM dialing section for more information on the use of ENUM zones. DNS zone Default Zone

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Overview To neighbor with another system (such as another VCS or gatekeeper), create a connection over a firewall to a traversal server or traversal client, or discover endpoints via an ENUM or DNS lookup, you must configure a zone on the local VCS. When adding a new zone you must specify its Type. The zone type indicates the nature of the connection and determines which configuration options are available. For traversal server zones, traversal client zones and neighbor zones this includes providing information about the neighbor system such as its IP address and ports. The Zones page lists all the zones that have been configured on the VCS, and lets you add, edit or delete zones. To go to the Zones page: • VCS configuration > Zones. Click on the zone you want to configure (or click New to create a new zone, or click Delete to remove a zone). To add a new zone using the CLI: • xCommand ZoneAdd To configure existing zones using the CLI: • xConfiguration Zones Zone [1..1000] The following sections describe the various zone configuration settings that can be applied. Zone configuration TLS certificate verification of neighbor systems When a SIP TLS connection is established between a VCS and a neighbor system, the VCS can be configured to check the X.509 certificate of the neighbor system to verify its identity. You do this by configuring the zone’s TLS verify mode setting. If TLS verification is enabled, the neighbor system's FQDN or IP address, as specified in the Peer address field of the zone’s configuration, is used to verify against the certificate holder’s name contained within the X.509 certificate presented by that system. (The name has to be contained in either the Subject Common Name or the Subject Alternative Name attributes of the certificate.) The certificate itself must also be valid and signed by a trusted certificate authority. Note that for traversal server zones, the FQDN or IP address of the connecting traversal client is not configured, so the required certificate holder’s name is specified separately. If the neighbor system is another VCS, or it is a traversal client / traversal server relationship, the two systems can be configured to authenticate each other’s certificates. This is known as mutual authentication and in this case each VCS acts both as client and as a server and therefore you must ensure that each VCS’s certificate is valid both as a client and as a server. See the Security certificates section for more information on certificate verification and for instructions on uploading the VCS’s server certificate and uploading a list of trusted certificate authorities. Connections to neighbor systems over TCP and TLS Connections between the VCS and neighbor systems must be configured to use the same SIP transport type, that is they must both be configured to use TLS or both be configured to use TCP. ! In software versions prior to X5.1 a connection could be established if one system was configured to use TLS and the other used TCP. Note that any connection failures due to transport type mismatches are recorded in the Event Log. SIP authentication trust If a VCS is configured to use device authentication it will authenticate incoming SIP registration and INVITE requests. If the VCS then forwards the request on to a neighbor zone such as another VCS, that receiving system will also authenticate the request. In this scenario the message has to be authenticated at every hop. To simplify this so that a device’s credentials only have to be authenticated once (at the first hop), and to reduce the number of SIP messages in your network, you can configure neighbor zones to use the Authentication trust mode setting. Setting a zone’s Authentication trust mode to On means that if the VCS receives an authenticated SIP request from that zone it will trust that authentication and not challenge it again. If Authentication trust mode is Off the VCS will always challenge the request even if it has already been authenticated by the sending zone. Authentication trust only applies when device authentication is enabled. Note that authenticated SIP requests are identified by the presence of a P-Asserted-Identity field in the SIP message header as defined by RFC 3325 [35]. ! You are recommended to enable authentication trust only if the neighbor zone is part of a network of trusted SIP servers.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Configuring neighbor zones Common zone configuration options The zone configuration options depend upon the zone Type, however the following options apply to every zone type: Name The name acts as a unique identifier, allowing you to distinguish between zones of the same type. Type The nature of the specified zone, in relation to the local VCS: Neighbor: a connection to a neighbor system of the local VCS. Traversal client: the local VCS is a traversal client of the system being connected to, and there is a firewall between the two. Traversal server: the local VCS is a traversal server for the system being connected to, and there is a firewall between the two. ENUM: the zone contains endpoints discoverable by ENUM lookup. DNS: the zone contains endpoints discoverable by DNS lookup. After a zone has been created, the Type cannot be changed. Hop count The hop count is the number of times a request will be forwarded to a neighbor gatekeeper or proxy (see the Hop counts section for more information). This field specifies the hop count to use when sending a search request to this particular zone. If the search request was received from another zone and already has a hop count assigned, the lower of the two values is used. After creating a zone you must make it a target of at least one of your zone policy search rules. If the zone is not included as a target in your search rules, search requests will not be sent to that zone. See the Configuring search and zone transform rules section for more information. The sections that follow describe the specific additional configuration options that apply to each zone Type. Configuring zones The following options are available (in addition to the Name, Type and Hop count described in the Configuring zones section) when configuring a neighbor zone on the VCS. Neighbor zones are used to enable a connection from the local VCS to a neighbor system. ! Systems that are configured as cluster peers (formerly known as Alternates) must not be configured as neighbors to each other. H.323 Mode Determines whether H.323 calls are allowed to and from the neighbor system. Port Specifies the port on the neighbor system used for H.323 calls from the local VCS. This must be the same port number as that configured on the neighbor system as its H.323 UDP port. If the neighbor is another VCS, this is the port found under the VCS configuration > Protocols > H.323 in the Registration UDP Port field. SIP Mode Determines whether SIP calls are allowed to and from the neighbor system. Port Specifies the port on the neighbor system used for SIP connections from the local VCS. This must be the same port number as that configured on the neighbor system as its SIP TCP, SIP TLS or SIP UDP listening port (depending on which SIP transport mode is in use). Transport Determines which transport type is used for SIP calls to and from the neighbor system. The default is TLS. TLS verify mode Controls whether the VCS performs X.509 certificate checking against the neighbor system when communicating over TLS. If the neighbor system is another VCS, both systems can verify each other's certificate (known as mutual authentication). See TLS certificate verification of neighbor systems for more information. Authentication trust mode Controls whether authenticated SIP messages (ones containing a P-Asserted-Identity header) from this zone are trusted without further challenge. See SIP authentication trust for more information. Accept proxied registrations Controls whether proxied SIP registrations routed through this zone are accepted. This setting only applies to registration requests for a domain for which the VCS is acting as a Registrar. For requests for other domains the SIP Registration Proxy Mode setting applies. See Proxying registration requests for more information. Location Peer 1 to Peer 6 address The IP address or FQDN of the neighbor system. If the neighbor is a VCS cluster, this includes all of the peers in the cluster. See the Neighboring the local VCS to another VCS cluster section for more information. Advanced See the Zone configuration: advanced settings section for details on the Advanced settings. ! Do not use the Custom option or configure the individual Advanced settings except on the advice of TANDBERG customer support.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Configuring traversal client zones The following options are available (in addition to the Name, Type and Hop count described in the Configuring zones section) when configuring a traversal client zone on the VCS. Traversal client zones are used to enable a connection from the local VCS to a traversal server. For full details on how traversal client zones and traversal server zones work together to achieve firewall traversal, see the Firewall traversal section. An NTP server must be configured for traversal zones to work. Authentication username and password Traversal clients must always authenticate with traversal servers by providing their authentication credentials. Each traversal client zone must specify an Authentication username and Authentication password to be used for authentication with the traversal server. Multiple traversal client zones can be configured on a VCS, each with distinct credentials, to connect to one or more service providers. Note that the outbound connection credentials username and password are used for connections to all other (non traversal server) external systems. H.323 Mode Determines whether H.323 calls are allowed to and from the traversal server. Protocol Determines which of the two firewall traversal protocols (Assent or H.460.18) to use for calls to the traversal server. (See the H.323 firewall traversal protocols section for more information.) Port The port on the traversal server to use for H.323 calls to and from the local VCS. For firewall traversal to work via H.323, the traversal server must have a traversal server zone configured on it to represent this VCS, using this same port number. SIP Mode Determines whether SIP calls are allowed to and from the traversal server. Port The port on the traversal server to use for SIP calls to and from the VCS. Transport The transport type to use for SIP calls to and from the traversal server. The default is TLS. For firewall traversal to work via SIP, the traversal server must have a traversal server zone configured on it to represent this VCS, using this same transport type and port number. TLS verify mode Controls X.509 certificate checking and mutual authentication between this VCS and the traversal server when communicating over TLS. See TLS certificate verification of neighbor systems for more information. Accept proxied registrations Controls whether proxied SIP registrations routed through this zone are accepted. This setting only applies to registration requests for a domain for which the VCS is acting as a Registrar. For requests for other domains the SIP Registration Proxy Mode setting applies (see Proxying registration requests). Poison mode Determines if SIP requests sent to systems located via this zone are "poisoned" such that if they are received by this VCS again they will be rejected. Client settings Retry interval Specifies the interval in seconds with which a failed attempt to establish a connection to the traversal server should be retried. Location Peer 1 to Peer 6 address The IP address or FQDN of the traversal server. If the traversal server is a VCS Expressway cluster, this should include all of its peers. See the Neighboring the local VCS to another VCS cluster section for more information. If the traversal server is a TANDBERG Border Controller, this should include all its Alternates.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Configuring traversal server zones The following options are available (in addition to the Name, Type and Hop count described in the Configuring zones section) when configuring a traversal server zone on the VCS Expressway. Traversal server zones are used to enable a connection from the local VCS Expressway to a traversal client. For full details on how traversal client zones and traversal server zones work together to achieve firewall traversal, see the Firewall traversal section. An NTP server must also be configured in order for traversal zones to work. Client authentication username Traversal clients must always authenticate with traversal servers by providing their authentication credentials. The authentication username is the name that the traversal client must provide to the VCS Expressway. • If the traversal client is a VCS, this must be its Authentication Username. • If the traversal client is a TANDBERG Gatekeeper, this is its System Name. There must also be an entry in the VCS Expressway's local authentication database for the client’s authentication username and password. To check the list of entries and add it if necessary, go to the Local authentication database page. Either: • click on the Add/Edit local authentication database link • go to VCS configuration > Authentication > Local database See the Device authentication section for more information. H.323 Mode Determines whether H.323 calls are allowed to and from the traversal client. Protocol Determines the protocol (Assent or H.460.18) to use to traverse the firewall/NAT. (See the H.323 firewall traversal protocols section for more information.) Port The port on the local VCS Expressway to use for H.323 calls to and from the traversal client. H.460.19 demultiplexing mode Determines whether or not the same two ports are used for media by two or more calls. On: all calls from the traversal client use the same two ports for media. Off: each call from the traversal client uses a separate pair of ports for media. SIP Mode Determines whether SIP calls are allowed to and from the traversal client. Port The port on the local VCS Expressway to use for SIP calls to and from the traversal client. Transport Determines which transport type is used for SIP calls to and from the traversal client. The default is TLS. TLS verify mode and subject name Controls X.509 certificate checking and mutual authentication between this VCS and the traversal client. If TLS verify mode is enabled, a TLS verify subject name must be specified. This is the certificate holder's name to look for in the traversal client's X.509 certificate. See TLS certificate verification of neighbor systems for more information. Accept proxied registrations Controls whether proxied SIP registrations routed through this zone are accepted. This setting only applies to registration requests for a domain for which the VCS is acting as a Registrar. For requests for other domains the SIP Registration Proxy Mode setting applies (see Proxying registration requests). Poison mode Determines if SIP requests sent to systems located via this zone are "poisoned" such that if they are received by this VCS again they will be rejected. UDP/TCP probes UDP retry interval The frequency (in seconds) with which the client sends a UDP probe to the VCS Expressway if a keep alive confirmation has not been received. UDP retry count The number of times the client attempts to send a UDP probe to the VCS Expressway during call setup. UDP keep alive interval The interval (in seconds) with which the client sends a UDP probe to the VCS Expressway after a call is established, in order to keep the firewall’s NAT bindings open. TCP retry interval The interval (in seconds ) with which the traversal client sends a TCP probe to the VCS Expressway if a keep alive confirmation has not been received. TCP retry count The number of times the client attempts to send a TCP probe to the VCS Expressway during call setup. TCP keep alive interval The interval (in seconds) with which the traversal client sends a TCP probe to the VCS Expressway when a call is in place, in order to maintain the firewall’s NAT bindings. The default UDP and TCP probe retry intervals are suitable for most situations. However, if you experience problems with NAT bindings timing out, they may need to be changed.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Configuring DNS zones The following options are available (in addition to the Name, Type and Hop count described in the Configuring zones section) when configuring a DNS zone. DNS zones are used to enable the local VCS to locate endpoints and other systems by using DNS lookups. Full details of how to use and configure DNS zones are given in the Adding and configuring DNS zones section. H.323 mode Determines whether H.323 calls are allowed to systems and endpoints located using DNS lookups via this zone. SIP Mode Determines whether SIP calls are allowed to systems and endpoints located using DNS lookups via this zone. TLS verify mode Controls whether the VCS performs X.509 certificate checking against the destination system server returned by the DNS lookup. This setting only applies if the DNS lookup specifies TLS as required protocol. If TLS is not required then the setting is ignored. See TLS certificate verification of neighbor systems for more information. Advanced See the Zone configuration: advanced settings section for details on the Advanced settings. ! Do not configure the individual Advanced settings except on the advice of TANDBERG customer support. The following options are available (in addition to the Name, Type and Hop count described in the Configuring zones section) when configuring an ENUM zone. ENUM zones are used to enable ENUM dialing via the local VCS. Full details of how to use and configure ENUM zones are given in the ENUM dialing section. DNS suffix Specifies the domain to be appended to the transformed E.164 number to create an ENUM domain for which this zone is queried. H.323 mode Determines whether H.323 records are looked up for this zone. SIP mode Determines whether SIP records are looked up for this zone. Configuring ENUM zones

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones ! The table below describes the Advanced and Custom zone configuration options. Some of these settings only apply to specific zone types. You should only use the Custom zone profile settings on the advice of TANDBERG customer support. Setting Description Default Applicable to Zone profile Determines the configuration of the Advanced settings for this zone. The options are: Default: the VCS uses the default values for these settings. Preconfigured profiles: alternatively, choose one of the preconfigured profiles to automatically use the appropriate settings required for connections to that type of system. The options include: • Microsoft Office Communications Server 2007 (see TANDBERG Deployment Guide - VCS Control interworking with Microsoft OCS [24] for full details on how to configure the VCS and OCS to enable the two systems to work together) • Cisco Unified Communications Manager • Nortel Communication Server 1000 • TANDBERG Advanced Media Gateway Custom: lets you configure each Advanced setting individually. These settings are listed in the remainder of this table below. Default Neighbor zones DNS zones Searches are automatically responded to Determines what happens when the VCS receives a SIP search that originated as an H.323 search. Off: a SIP OPTION or SIP INFO message is sent. On: searches are responded to automatically, without being forwarded. This option should normally be left as the default Off. However, some systems such as Microsoft Office Communications Server (OCS) 2007 do not accept SIP OPTION messages, so for these zones it must be set to On. If you change this to On, you must also configure pattern matches to ensure that only those searches that actually match endpoints in this zone are responded to. If you do not, the search will not continue to other lower-priority zones, and the call will be forwarded to this zone even if it cannot support it. Off Neighbor zones DNS zones Empty INVITE allowed Determines whether the VCS generates a SIP INVITE message with no SDP to send via this zone. INVITES with no SDP mean that the destination device is asked to initiate the codec selection, and are used when the call has been interworked locally from H.323. On: SIP INVITEs with no SDP are generated. Off: SIP INVITEs are generated and a pre-configured SDP is inserted before the INVITEs are sent. In most cases this option should normally be left as the default On. However, some systems such as Microsoft OCS 2007 do not accept invites with no SDP, so for these zones this should be set to Off. The settings for the pre-configured SDP are configurable using the xConfiguration Zones Zone [1..1000] DNS Interworking SIP commands. They should only be changed on the advice of TANDBERG customer support. On Neighbor zones DNS zones Zone configuration: advanced settings

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Setting Description Default Applicable to SIP poison mode On: SIP requests sent to systems located via this zone are "poisoned" such that if they are received by this VCS again they will be rejected. Off: SIP requests sent out via this zone that are received by this VCS again will not be rejected; they will be processed as normal. Off Neighbor zones Traversal client zones Traversal server zones DNS zones SIP encryption mode Determines whether or not the VCS allows encrypted SIP calls on this zone. Auto: SIP calls are encrypted if a secure SIP transport (TLS) is used. Off: SIP calls are never encrypted. This option should normally be left as the default Auto. However, this must be set to Off for Microsoft Office Communications Server (OCS) 2007 zones. Auto Neighbor zones SIP SDP attribute line limit mode Determines whether requests containing SDP sent out to this zone have the length of a=fmtp lines restricted. On: the length is truncated to the maximum length specified by the SIP SDP attribute line limit length setting. Off: the length is not truncated. The SIP SDP attribute line limit option should normally be left as the default of Off. However, some systems such as Microsoft OCS 2007 cannot handle attribute lines longer than 130 characters, so it must be set to On for connections to these systems. Off Neighbor zones DNS zones SIP SDP attribute line limit length If SIP SDP attribute line limit mode is set to On, sets the maximum line length of a=fmtp SDP lines. 130 Neighbor zones DNS zones SIP multipart MIME strip mode Controls whether or not multipart MIME stripping is performed on requests from this zone. This option should normally be left as the default Off. However, it must be set to On for connections to a Microsoft OCS 2007 Release 2 system. Off Neighbor zones SIP UPDATE strip mode Controls whether or not the VCS strips the UPDATE method from the Allow header of all requests and responses received from this zone. This option should normally be left as the default Off. However, some systems such as Microsoft OCS 2007 do not support the UPDATE method in the Allow header, so for these zones this should be set to On. Off Neighbor zones Interworking SIP search strategy Determines how the VCS searches for SIP endpoints when interworking an H.323 call. Options: the VCS sends an OPTIONS request. Info: the VCS sends an INFO request. This option should normally be left as the default Options. However, some endpoints such as Microsoft Office Communicator (MOC) clients cannot respond to OPTIONS requests, so this must be set to Info for connections to a Microsoft OCS 2007 system. Options Neighbor zones Zone configuration: advanced settings

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones Setting Description Default Applicable to SIP UDP/BFCP filter mode Determines whether INVITE requests sent to this zone filter out UDP/BFCP. This option may be required to enable interoperability with SIP devices that do not support the UDP/BFCP protocol, so this must be set to On for connections to a Cisco Unified Communications Manager. On: any media line referring to the UDP/BFCP protocol is replaced with TCP/BFCP and disabled. Off: INVITE requests are not modified. Off Neighbor zones DNS zones SIP Duo Video filter mode Determines whether INVITE requests sent to this zone filter out Duo Video. This option may be required to enable interoperability with SIP devices that do not support Duo Video, so this must be set to On for connections to a Cisco Unified Communications Manager. On: the second video line in any outgoing INVITE request is removed. Off: INVITE requests are not modified. Off Neighbor zones DNS zones SIP record route address type Controls whether the VCS uses its IP address or host name in the record-route or path headers of outgoing SIP requests to this zone. IP: uses the VCS's IP address. Hostname: uses the VCS's Local host name (if it is blank the IP address is used instead). IP Neighbor zones DNS zones SIP Proxy-Require header strip list A comma separated list of option tags to search for and remove from Proxy-Require headers in SIP requests received from this zone. None Neighbor zones Include address record Determines whether, if no NAPTR (SIP) or SRV (SIP and H.323) records have been found for the dialed alias via this zone, the VCS will then query for A and AAAA DNS records before moving on to query lower priority zones. If A and AAAA records exist at the same domain for systems other than those that support SIP or H.323, this may result in the VCS believing the search was successful and forwarding calls to this zone, and the call will fail. On: the VCS queries for A or AAAA records. If any are found, the VCS will not then query any lower priority zones. Off: the VCS will not query for A and AAAA records and instead will continue with the search, querying the remaining lower priority zones. Off DNS zones Zone configuration: advanced settings

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Zones The table below shows the advanced zone configuration option settings that are automatically applied for each of the pre-configured profiles. Setting Microsoft Office Communications Server 2007 Cisco Unified Communications Manager Nortel Communication Server 1000 TANDBERG Advanced Media Gateway Searches are automatically responded to Off Off Off Off Empty INVITE allowed Off On On On SIP poison mode On Off Off Off SIP encryption mode Off On On On SIP SDP attribute line limit mode On Off Off Off SIP SDP attribute line limit length 130 130 130 130 SIP multipart MIME strip mode On Off Off Off SIP UPDATE strip mode On Off Off Off Interworking SIP search strategy Info Options Options Options SIP UDP/BFCP filter mode Off On Off Off SIP Duo Video filter mode On Off Off Off SIP record route address type Hostname IP IP IP SIP Proxy-Require header strip list "com.nortelnetworks.firewall" Zone configuration: pre-configured profile settings

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Dial plans About dial plans As you start deploying more than one VCS, it is useful to neighbor the systems together so that they can query each other about their registered endpoints. Before you start, you should consider how you will structure your dial plan. This will determine the aliases assigned to the endpoints, and the way in which the VCSs are neighbored together. The solution you choose will depend on the complexity of your system. Some possible options are described in the following sections. Flat dial plan The simplest approach is to assign each endpoint a unique alias and divide the endpoint registrations between the VCSs. Each VCS is then configured with all the other VCS as neighbor zones. When one VCS receives a call for an endpoint which is not registered with it, it will send out a Location Request to all the other neighbor VCSs. While conceptually simple, this sort of flat dial plan does not scale very well. Adding or moving a VCS requires changing the configuration of every VCS, and one call attempt can result in a large number of location requests. This option is therefore most suitable for a deployment with just one or two VCSs plus its peers. Structured dial plan An alternative deployment would use a structured dial plan where endpoints are assigned an alias based on the system they are registering with. If you are using E.164 aliases, each VCS would be assigned an area code. When the VCSs are neighbored together, each neighbor zone would have an associated search rule configured with its corresponding area code as a prefix (a Mode of Alias Pattern Match and a Pattern type of Prefix). That neighbor would then only be queried for calls to numbers which begin with its prefix. In a URI based dial plan, similar behavior may be obtained by configuring search rules for each neighbor with a suffix to match the desired domain name. It may be desirable to have endpoints register with just the subscriber number -- the last part of the E.164 number. In that case, the search rule could be configured to strip prefixes before sending the query to that zone. A structured dial plan minimizes the number of queries issued when a call is attempted. However, it still requires a fully connected mesh of all VCSs in your deployment. A hierarchical dial plan can simplify this. Hierarchical dial plan In this type of structure one VCS is nominated as the directory for the deployment, and all other VCSs are neighbored with it alone. The directory VCS is configured with: • each VCS as a neighbor zone • search rules for each zone that have a Mode of Alias Pattern Match and the target VCS's prefix (as with the structured dial plan) as the Pattern string Each VCS is configured with: • the directory VCS as a neighbor zone • a search rule with a Mode of Any Alias and a Target zone of the directory VCS There is no need to neighbor the VCSs with each other. Adding a new VCS now only requires changing configuration on the new VCS and the directory VCS. However, failure of the directory VCS in this situation could cause significant disruption to communications. Consideration should be given to the use of Clustering for increased resilience. ! For H.323 calls, if Optimal call routing is enabled you must ensure that all search rules are configured with a Source of Any. If the Source is configured to All zones (the default), H.323 calls will fail to connect. This is because the H.323 SETUP message, having followed the optimized route established by the original LRQ or ARQ, will appear to the target VCS as coming from an unknown zone. SIP calls, however, are successfully routed if the search rule Source is Any (because in SIP the search and call setup is combined into one message). Structuring your dial plan

This section describes how to set up a cluster of VCS peers. Clustering is used to increase the capacity of your VCS deployment and to provide resiliency. The section includes: • an overview of clustering • guidelines for configuring a cluster • a list of configuration that isn't replicated across cluster peers • a troubleshooting guide for cluster replication problems • how registrations and bandwidth are shared across peers • how clustering works with FindMe, Presence and TMS • the purpose of the cluster subzone • how to neighbor a local VCS or cluster to a remote VCS cluster Clustering and peers TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Clustering overview A VCS can be part of a cluster of up to six VCSs. Each VCS in the cluster is a peer of every other VCS in the cluster. Clusters are used to: • increase the capacity of your VCS deployment compared with a single VCS • provide redundancy in the rare case that a VCS becomes unavailable (for example, due to a network or power outage). Peers have identical configuration, and share information with each other about their use of bandwidth, registrations, and FindMe users. This allows the cluster to act as one large VCS Local Zone. The diagram opposite shows two separate clusters, both being monitored by TMS. About the configuration master All peers in a cluster must be configured identically for subzones, zones, links, pipes, authentication, bandwidth control and call policy. To achieve this, you define a cluster name and nominate one peer as the configuration master. Approximately every minute, all the other peers in the cluster request updated configuration information from the master, and overwrite their existing configuration with these new settings. ”Alternate” is an H.323 term for a system used to provide redundancy to a Primary gatekeeper, and prior to version X3.0 the VCS supported Alternates. From X3.0 onwards, redundancy (along with other features) is provided by clusters of peers, which support both H.323 and SIP and work as equals. However, peers may sometimes be referred to as Alternates. Also note that some versions of TMS refer to peers as "members". About clustering LOCAL ZONE Traversal Subzone Default DNS Zone ENUM Zone Neighbor Zone Traversal Client Zone Subzone Default Zone Peer 1 Cluster Subzone VCS Cluster South Subzone Peer 2 Peer 3 Peer 4 LOCAL ZONE Traversal Subzone Default DNS Zone ENUM Zone Neighbor Zone Traversal Client Zone Subzone Default Zone Cluster Subzone VCS Cluster North Subzone Peer 2 Peer 3 Peer 4 Peer 1 Peer 5 Peer 6 TANDBERG Management Suite (TMS)

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Cluster configuration Configuring clusters Setting up a cluster Before creating your cluster, ensure that all the VCSs to be added to the cluster: • are using TMS version 12.5 or later as their external manager • have the same software version and option keys installed • each have a different system name • are configured with a working NTP Server. • each have a different LAN configuration (a different IPv4 address and a different IPv6 address, where enabled) • have H.323 enabled (even if all endpoints in the cluster are SIP only, H.323 signaling is used for endpoint location searching and sharing bandwidth usage information with other peers in the cluster) • have SSH enabled (data replication between peers uses SSH) • have access to the root account via SSH enabled Configuring the master peer One of the VCSs in the cluster must act as the master peer for controlling updates to configuration data. 1. Decide which VCS is to be the master and configure it with the settings you want to apply to the entire cluster. 2. Go to the Clustering page (VCS configuration > Clustering) of the master VCS: a. Enter a Cluster name (see Cluster name, right). b. Enter the IP addresses of the master VCS and the other peers into the Peer IP address fields. c. Select the Configuration master to match the Peer IP address number of the master VCS. Running the clustering script On each peer in the cluster, log in as root and run the cluster configuration script. A full step-by-step guide on using the clustering script and configuring clusters is available in the Clustering deployment guide [27]. Maintaining a cluster The Clustering page lists the IP addresses of all the peers in the cluster, to which this VCS belongs, and identifies the master peer. To view the Clustering page: • VCS configuration > Clustering. To view this information from the CLI: • xConfiguration Alternates Setting configuration for the cluster You should make configuration changes on the master VCS. Any changes made on other peers are not reflected across the cluster, and will be overwritten the next time the master’s configuration is replicated across the peers. The only exceptions to this are: • some specific configuration items that are not replicated • user account details (you can maintain these on any peer — FindMe data uses a different replication mechanism) You may need to wait up to one minute before changes are updated across all peers in the cluster. Adding and removing peers from a cluster After a cluster has been set up you can add new peers to the cluster or remove peers from it. Instructions for this are also contained in the Clustering deployment guide [27]. ! Systems that are configured as peers must not also be configured as neighbors to each other, and vice versa. ! If peers are deployed on different LANs, there must be sufficient connectivity between the networks to ensure a low degree of latency between the peers - a maximum delay of 15ms one way, 30ms round-trip. Deploying all peers in a cluster on the same LAN means they can be configured with the same routing information such as local domain names and local domain subnet masks. Cluster name The Cluster name is used to identify one cluster of VCSs from another. Set it to the fully qualified domain name used in SRV records that address this VCS cluster, for example "cluster1.example.com". See the Clustering and FindMe section if you are using FindMe. Changing the master peer You should only need to change the Configuration master when: • The original master peer fails: in this case you must log in to every other VCS in the cluster and change the configuration master on each. Note that if the master fails, the remaining peers will continue to function normally, except they are no longer able to copy their configuration from the master so may become out of sync with each other. • You want to take the master VCS unit out of service: in this case you must log in to the master peer and change the configuration master to another peer. (If you use any other VCS to change the configuration master, this setting, like all other configuration, will be overwritten when that peer next replicates its configuration from the master.) To change the master peer: 1. Log into the current master VCS and go to the Clustering page. 2. Change the Configuration master to the peer you want to set as the new master (the numbers match against the Peer IP address fields underneath). 3. Click Save. You may need to wait up to one minute before the change is updated across all peers in the cluster. Monitoring the status of the cluster The status areas at the bottom of the Clustering page show you the current status of the cluster, and the time of the previous and next synchronization. From here you can also go to the TMS Agent replication status page. This shows the current status of the TMS Agent service and can be used to assist in troubleshooting replication problems.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Cluster configuration Which configuration is not replicated? Most items of configuration are replicated from the master to all peers, with the exceptions listed below. System name The system name is not replicated. It must be different for each peer in the cluster. Administrator accounts The password for the default admin administrator account is not replicated. Each peer can have a different password. Any other local administrator accounts and passwords are replicated from the master peer to all other peers. Option keys Option keys are not replicated. Each peer must have an identical set of option keys installed, but you must purchase these separately for each peer in the cluster. Ethernet speed The ethernet speed is not replicated. Each peer may have slightly different requirements for the connection to their ethernet switch. Conference Factory template The Template used by the Conference Factory application to route calls to the MCU is not replicated, as it must be unique for each peer. DNS configuration DNS servers are not replicated across peers - each peer can use a different set of DNS servers. However, the DNS domain name is replicated across peers. IP configuration LAN configuration is not replicated across peers. Each peer must have a different IPv4 address and a different IPv6 address. IP gateway configuration is not replicated. Each peer can use a different gateway. IP routes (also known as static routes) are not replicated. If these are used, they can be different for each peer. Note that the IP protocol is replicated, because each peer must support the same protocol(s). Logging The Event Log and Configuration Log on each peer will only report activity for that particular VCS. We recommend that you set up a remote syslog server to which the logs of all peers can be sent. This will allow you to have a global view of activity across all peers in the cluster. See the About remote logging section for further details. Certificates The security certificates and certificate revocation lists (CRLs) used by the VCS must be uploaded individually per peer. ! Configuration data that is replicated across peers should not be modified on non-master peers. At best it will result in the changes being overwritten from the master; at worst it will cause cluster replication to fail. Troubleshooting cluster replication problems Cluster replication can fail for a variety of reasons. The most common problems are listed below, followed by instructions for resolving the problem: NTP servers not configured and active on each cluster peer 1. For each peer in the cluster, go to the System configuration > Time page. 2. Ensure the peer has a correctly configured and active NTP server. Some peers have a different master peer defined 1. For each peer in the cluster, go to the VCS configuration > Clustering page. 2. Ensure each peer identifies the same Configuration master. Cluster configuration script has not been run against each peer 1. For each peer in the cluster, go to the VCS configuration > Clustering page. 2. Enter the address of each of peer into the Peer IP address fields and configure the Configuration master. Ensure each peer identifies the same Configuration master peer. 3. Log in to each peer as root (by default you can only do this using a serial connection or SSH) and run the cluster configuration script (full details on running this script and configuring clusters is available in the Clustering deployment guide [27]). Cluster replication warnings can appear briefly while the cluster is initially being set up. These warnings are removed after the data has completed synchronizing and the cluster has stabilized. This takes approximately 3 minutes. Unable to reach the cluster configuration master peer The VCS operating as the master peer could be unreachable for many reasons, including: • network access problems • VCS unit is powered down • incorrectly configured IP addresses "Manual synchronization of configuration is required" warnings are raised on peer VCSs 1. Log in to the peer as admin through the CLI (available by default over SSH and through the serial port). 2. Type xCommand ForceConfigUpdate. This will delete the non-master VCS configuration and force it to update its configuration from the master VCS. ! Never issue this command on the master VCS, otherwise all VCS configuration for the cluster will be lost.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Managing clusters and peers When one VCS in a cluster receives a search request (such as an LRQ, ARQ or an INVITE), it checks its own and its peers' registration databases before responding. This allows all endpoints in the cluster to be treated as if they were registered with a single VCS. Peers are periodically queried to ensure they are still functioning. To prevent delays during call setup, any non- functioning peers do not receive LRQs. H.323 registrations All the peers in a cluster share responsibility for their H.323 endpoint community. When an H.323 endpoint registers with one peer, it receives a registration response which contains a list of Alternate gatekeepers, populated with a randomly ordered list of the IP addresses of all the other peers in that cluster. If the endpoint loses contact with the initial peer, it will seek to register with one of the other peers. The random ordering of the list of alternate peers ensures that endpoints that can only store a single alternate peer will failover evenly across the cluster. ! When using a cluster, you should change the registration Time to live on all peers in the cluster from the default 30 minutes to just a few minutes. This setting determines how often endpoints are required to re-register with their VCS, and reducing this to just a few minutes ensures that if one VCS becomes unavailable, the endpoint will quickly failover to one of its peers. To change this setting, go to VCS configuration > Protocols > H.323 > Gatekeeper > Time to live. SIP registrations Failover re-registration to a peer applies to H.323 re-registrations only. The SIP standard currently has no direct equivalent, but some SIP UAs including TANDBERG Movi™ v2.0 (or later) clients support similar functionality. If you configure such endpoints with a SIP server address that is an FQDN, and configure this FQDN to resolve to a round-robin DNS record populated with the IP addresses of all the peers in the cluster, then this could allow the endpoint to re-register with another peer if its connection to the original peer was lost. Sharing registrations across peers Sharing bandwidth across peers When clustering has been configured, all peers share the bandwidth available to the cluster. Peers must be configured identically for all aspects of bandwidth control including subzones, links and pipes. Peers share their bandwidth usage information with all other peers in the cluster, so when one peer is consuming part or all of the bandwidth available within or from a particular subzone, or on a particular pipe, this bandwidth will not be available for other peers. For general information on how the VCS manages bandwidth, see the Bandwidth control section. Upgrades and downgrades The clustering feature was introduced to the VCS in software release X3.0. Upgrading from versions prior to X3.0 If you are upgrading from VCS software versions prior to X3.0 and want to implement clustering, you must: 1. Remove any existing Alternate configuration. 2. Upgrade all VCSs to be added to the cluster to the latest VCS software version. 3. Follow the steps outlined in the Configuring clusters section. Downgrading See the Downgrade procedure section for details on restoring system configuration details. Backup and restore The Backup and restore process saves all configuration information for a particular VCS. You are recommended to regularly backup not just the master peer but all peers in the cluster. This ensures that peer-specific configuration information (see the Which configuration is not replicated? section) is saved and can be restored individually for each peer. ! Do not restore a backup made on one peer to another peer.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Managing clusters and peers Clustering supports the use of Presence. All peers in the cluster must have identical SIP domain, Presence Server and Presence User Agent (PUA) configuration. If peers in the cluster have the PUA enabled, each peer publishes information about its own local registrations. This information is routed to a Presence Server authoritative for the cluster’s domain. If peers have the Presence Server enabled, the Presence database is replicated across all peers in the cluster. When viewing presence status on a peer in a cluster: • Publishers will show all presentities across the cluster for whom presence information is being published. • Presentities will show any presentity for whom a subscription request has been received on the local VCS only. • Subscribers will show each endpoint from which a subscription request has been received on the local VCS only. Clustering and Presence Overview Clustering supports the use of FindMe. Each peer has its own FindMe database containing all user account information for the cluster. When a user account is created or edited on one peer, that peer shares the information about the changes to all other peers in the cluster, which then update their own FindMe databases accordingly. There is a limit of 10,000 FindMe user accounts per VCS cluster. Multiple clusters are required if you have more than 10,000 users. Note that the replication of FindMe database information uses a different mechanism (the TMS Agent) to that used to replicate configuration information. Configuration information must be changed on the master peer only, but changes to FindMe information can be made on any peer and will be shared with all other peers. If you are part of a large enterprise with, for example, TMS managing several VCS clusters, the FindMe database may contain details of users and devices in other VCS clusters. Different clusters are distinguished by their Cluster name (see below). You cannot modify the details of accounts that are not managed in your cluster. Cluster name You must define a Cluster name if you are using FindMe, even if the VCS is not part of a cluster. If you change the cluster name after creating your user accounts you will have to reconfigure those accounts to associate them with the new cluster name. You can do this by running the transferfindmeaccounts script. Instructions for how to do this are contained in the FindMe Deployment Guide [29]. Alterntively, if you try to edit an account that belongs in a different cluster the system gives you an option to Move this account to local cluster. Selecting this option updates that particular account so that it now belongs to your local VCS cluster and hence lets you edit that account's details. See Configuring clusters for more information on configuring the cluster name. Clustering and FindMe Clustering and TMS Clusters can be monitored from TANDBERG Management Suite (TMS). For full information, refer to the TMS documentation. • TMS version 12.5 or later is required when setting up a cluster. • When a cluster is up and running, TMS is only mandatory if you are using FindMe or Device Provisioning, however it is still recommended. If you were using TMS to manage a cluster running a version of the VCS software prior to X5, refer to the TANDBERG Deployment Guide - Creating a Cluster of VCS peers [27] for upgrade instructions. In previous VCS releases, replication between peers was managed by TMS. From VCS version X4 onwards, replication is managed by the VCSs themselves.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Managing clusters and peers Configuration To neighbor your local VCS (or VCS cluster) to a remote VCS cluster, you create a single zone to represent the cluster and configure it with the details of all the peers in that cluster: 1. On your local VCS (or, if the local VCS is a cluster, on the master peer), create a zone of the appropriate type. This zone will represent the connection to the cluster. 2. In the Location section, enter the IP address or FQDN of each peer in the remote cluster in the Peer 1 to Peer 6 address fields. To do this using the CLI: • Zones Zone [1..1000] Neighbor Peer [1..6] Address • Zones Zone [1..1000] TraversalClient Peer [1..6] Address Ideally you should use IP addresses in these fields. If you use FQDNs instead, each FQDN must be different and must resolve to a single IP address for each peer. The order in which the peers in the remote VCS cluster are listed here does not matter. Whenever you add an extra VCS to a cluster (to increase capacity or improve redundancy, for example) you will need to modify any VCSs which neighbor to that cluster to let them know about the new cluster peer. Neighboring the local VCS to another VCS cluster Overview You can neighbor your local VCS (or VCS cluster) to a remote VCS cluster; this remote cluster could be a neighbor, traversal client, or traversal server to your local VCS. In this case, when a call is received on your local VCS and is passed via the relevant zone to the remote cluster, it will be routed to whichever peer in that neighboring cluster has the lowest resource usage. That peer will then forward the call as appropriate: • to one of its locally registered endpoints (if the endpoint is registered to that peer) • to one of its peers (if the endpoint is registered to another peer in that cluster) • one of its external zones (if the endpoint has been located elsewhere). When configuring a connection to a remote cluster, you create a single zone and configure it with details of all the peers in the cluster. Adding this information to the zone will ensure that the call is passed to that cluster regardless of the status of the individual peers. Note that when you are configuring a connection to a remote cluster, you need to enter the IP address of all peers in the remote cluster when the connection is via a neighbor or traversal client zone. You do not do this for traversal server zones, as these connections are not configured by specifying the remote system's IP address. ! Systems that are configured as peers must not also be configured as neighbors to each other, and vice versa. Cluster Subzone When two or more VCSs are clustered together, a new subzone is created within the cluster’s Local Zone. This is the Cluster Subzone (shown in the diagram in the Clustering overview section). Any calls between two peers in the cluster will briefly pass via this subzone during call setup. The Cluster Subzone is (like the Traversal Subzone) a virtual subzone used for call routing only, and endpoints cannot register to this subzone. After a call has been established between two peers, the Cluster Subzone will no longer appear in the call route and the call will appear as having come from (or being routed to) the Default Subzone. The two situations in which a call will pass via the Cluster Subzone are: • Calls between two endpoints registered to different peers in the cluster. For example, Endpoint A is registered in the Default Subzone to Peer 1. Endpoint B is also registered in the Default Subzone, but to Peer 2. When A calls B, the call route is shown on Peer 1 as Default Subzone -> Cluster Subzone, and on Peer 2 as Cluster Subzone -> Default Subzone. • Calls received from outside the cluster by one peer, for an endpoint registered to another peer. For example, we have a single VCS for the Branch Office, which is neighbored to a cluster of 4 VCSs at the Head Office. A user in the Branch Office calls Endpoint A in the Head Office. Endpoint A is registered in the Default Subzone to Peer 1. The call is received by Peer 2, as it has the lowest resource usage at that moment. Peer 2 then searches for Endpoint A within the cluster’s Local Zone, and finds that it is registered to Peer 1. Peer 2 then forwards the call to Peer 1, which forwards it to Endpoint A. In this case, on Peer 2 the call route will be shown as Branch Office -> Default Subzone -> Cluster Subzone, and on Peer 1 as Cluster Subzone -> Default Subzone. If Call routed mode is set to Optimal and the call is H.323, the call will not appear on Peer 2, and on Peer 1 the route will be Branch Office > DefaultSubzone.

This section provides information on the pages that appear under the Calls, Search rules, Transforms, Call Policy and Advanced Media Gateway sub-menus of the VCS Configuration menu. These pages are used to configure the way in which the VCS receives and processes calls. This section includes the following: • an overview of how the VCS searches for the destination endpoint • the different types of addresses that can be dialed to initiate a call • how hop counts affect the search process • the searching and transform process • how to use Call Policy to manage calls • routing calls via the Advanced Media Gateway • how to set up your network to handle incoming and outgoing calls made via URI dialing and ENUM dialing • call configuration options • how to identify calls • how to disconnect calls Call processing TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Introduction VCS search process The process followed by the VCS when attempting to locate a destination endpoint is shown in the diagram opposite. 1. The user enters into their endpoint the alias or address of the destination endpoint. This alias or address can be in a number of different address types. 2. The destination address is sent from the caller’s endpoint to its local VCS (i.e. the VCS to which it is registered). 3. The VCS applies any pre-search transforms to the alias. 4. The VCS applies any Call Policy to the (transformed) alias. If this results in a new alias, the process starts again with the new alias checked against the pre- search transforms. 5. The VCS applies any User Policy (if FindMe is enabled) to the alias. If the alias is a FindMe ID that resolves to one or more new aliases, the process starts again with all the resulting aliases checked against pre-search transforms and Call Policy. 6. The VCS then applies its search rules in priority order. At each priority, zones are searched first in the native protocol and then, if the VCS interworking configuration allows, the alternative protocol. If the alias matches an ENUM zone, this may return a URI. If so, the process starts again; the URI is checked against any pre-search transforms, Call Policy and User Policy. 7. If the alias is found within the Local Zone or in one of the external zones, the VCS attempts to place the call to that zone. 8. If the alias is not found, the VCS responds with a message to say that the call has failed. Search process One of the functions of the VCS is to route calls to their appropriate destination, based on the address or alias received from a locally registered endpoint or external zone. There are a number of steps involved in determining the destination of a call, and some of these steps can involve transforming the alias or redirecting the call to other aliases. It is important to understand the process before setting up your dial plan so you can avoid circular references, where an alias is transformed from its original format to a different format, and then back to the original alias. The VCS is able to detect circular references. If it identifies one it will terminate that branch of the search and return a “policy loop detected” error message.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Dialing by address types The destination address that is entered using the caller’s endpoint can take a number of different formats, and this will affect the specific process that the VCS follows when attempting to locate the destination endpoint. The address types supported by the VCS are: • IP address e.g. 10.44.10.1 or 3ffe:80ee:3706::10:35 • H.323 ID e.g. john.smith or [email protected] (note that an H.323 ID can be in the form of a URI) • E.164 alias e.g. 441189876432 or 6432 • URI e.g. [email protected] • ENUM e.g. 441189876432 or 6432 Each of these address types may require some configuration of the VCS in order for them to be supported. The following sections describe the configuration required for each address type. Dialing by IP address is necessary when the destination endpoint is not registered with any system (such as a VCS, gatekeeper or Border Controller). If the destination endpoint is registered with one of these systems, it may be possible to call it using its IP address but the call may not succeed if the endpoint is on a private network or behind a firewall. For this reason we recommend that, where possible, calls to registered endpoints are placed using one of the other address types, such as its AOR or H.323 ID. For the same reason we do not recommend that callers outside your network are given IP addresses to use to contact endpoints within your network The Calls to Unknown IP addresses setting determines how the VCS will handle calls made to IP addresses which are not on its local network, or registered with it or one of its neighbors. See the Calls to unknown IP addresses section for full details on this setting. Endpoints registered to a VCS Expressway Calls made by dialing the IP address of an H.323 endpoint registered directly with a VCS Expressway will be forced to route through the VCS Expressway. The call will therefore be subject to any restrictions configured on that system. About the different address types No special configuration is required to place a call using an H.323 ID or E.164 alias. The VCS follows the usual search process, applying any transforms and then searching the Local Zone and external zones for the alias, according to the search rules. SIP endpoints will always register using an AOR in the form of a URI. We recommend that H.323 endpoints also register with an H.323 ID in the form of a URI to facilitate interworking. When a user places a call using URI dialing, they will typically dial [email protected]. If the destination endpoint is locally registered or registered to a neighbor system, no special configuration is required for the call to be placed. The VCS follows the usual search process, applying any transforms and then searching the Local Zone and external zones for the alias, according to the search rules. If the destination endpoint is not locally registered, URI dialing may make use of DNS to locate the destination endpoint. To support URI dialing via DNS, you must configure the VCS with at least one DNS server and at least one DNS zone. Full instructions on how to configure the VCS to support URI dialing via DNS (both outbound and inbound) are given in the URI dialing section. ENUM dialing allows an endpoint to be contacted by a caller dialing an E.164 number - a telephone number - even if that endpoint has registered using a different format of alias. The E.164 number is converted into a URI by the DNS system, and the rules for URI dialing are then followed to place the call. The ENUM dialing facility allows you to retain the flexibility of URI dialing whilst having the simplicity of being called using just a number - particularly important if any of your callers are restricted to dialing using a numeric keypad. In order to support ENUM dialing on the VCS you must configure it with at least one DNS server and the appropriate ENUM zone(s). Full instructions on how to configure the VCS to support ENUM dialing (both outbound and inbound) are given in the ENUM dialing section. Dialing by IP address Dialing by H.323 ID or E.164 alias Dialing by H.323 or SIP URI Dialing by ENUM !

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Hop counts Hop counts are configured on a zone basis. To configure the hop count for a zone: 1. Go to the Zones page. VCS configuration > Zones 2. Click on the name of the zone you want to configure. You are taken to the Edit zone page. 3. In the Configuration section, in the Hop Count field, enter the hop count value you want to use for this zone. To configure the hop count using the CLI: • xConfiguration Zones Zone [1..1000] HopCount For full details on other zone options, see the Zone configuration section. Each search request is assigned a hop count value by the system that initiates the search. Every time the request is forwarded to another neighbor gatekeeper or proxy, the hop count value is decreased by a value of 1. When the hop count reaches 0, the request will not be forwarded on any further and the search will fail. For search requests initiated by the local VCS, the hop count assigned to the request is configurable on a zone-by-zone basis. The zone’s hop count applies to all search requests originating from the local VCS that are sent to that zone. Search requests received from another zone will already have a hop count assigned. When the request is subsequently forwarded on to a neighbor zone, the lower of the two values (the original hop count or the hop count configured for that zone) is used. For H.323, the hop count only applies to search requests. For SIP, the hop count applies to all requests sent to a zone, affecting the Max-Forwards field in the request. The hop count value can be between 1 and 255. The default is 15. ! If your hop counts are set higher than necessary, you may risk introducing loops into your network. In these situations a search request will be sent around the network until the hop count reaches 0, consuming resources unnecessarily. This can be prevented by setting the Call loop detection mode to On. When dialing by URI or ENUM, the hop count used is that for the associated DNS or ENUM zone via which the destination endpoint (or intermediary SIP proxy or gatekeeper) was found. About hop counts Configuring hop counts

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms About searches One of the VCS’s functions is to process incoming requests to search for a particular alias. These search requests are received from: • locally registered endpoints • neighboring systems, including neighbors, traversal clients and traversal servers • endpoints on the public internet You can configure how the VCS searches its Local Zone and external zones by setting up search rules that let you: • define alias, IP address and pattern matches to filter searches to specific zones • define the order (priority) in which the search rules are applied and stop applying any lower-priority search rules once a match is found; this lets you reduce the potential number of search requests sent out, and speed up the search process • set up different rules according to the source of the query (such as the Local Zone, or any known zone) • apply zone transforms to modify an alias You can configure up to 2000 search rules. The VCS uses the protocol (SIP or H.323) of the incoming call when searching a zone for a given alias. If the search is unsuccessful the VCS may then search the same zone again using the alternative protocol, depending on where the search came from and the Interworking mode (VCS configuration > Protocols > Interworking). If the request has come from a neighboring system and Interworking mode is set to RegisteredOnly, 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). 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. About transforms The VCS lets you transform the alias in a search request if it matches certain criteria. This transformation can be applied to the alias at two points in the search process: as a pre-search transform, and as a zone transform. Pre-search transform Pre-search transforms are applied before any Call Policy, User Policy or search rules are applied (see the Pre-search transforms section for more details). Zone transform Zone transforms are applied after Call Policy, User Policy and the search rules have been applied, and let you change the alias being searched for before a search request is sent to the Local Zone or out to an external zone (see the Zone searching and transform process, right). Zone transforms are specified as a part of the search rules configuration. You can transform an alias by removing or replacing its prefix, suffix, or the entire string, and by the use of regular expressions. Transforms support the use of Regular Expressions in both the Pattern String and Replace String fields.  See the Regular expression reference Appendix for more information. Multiple search rules can refer to the same target zone. This means that you can specify different sets of search criteria and zone transforms for each zone. For full information about configuring search rules, see the Configuring search and zone transform rules section. Zone searching and transform process Zone searching takes place after all pre-search transforms, Call Policy and User Policy have been applied. The search rules and zone transform process is as follows: 1. The VCS applies the search rules in priority order (all rules with a priority of 1 are processed first, then priority 2 and so on) to see if the given alias matches the rules criteria based on the Source of the query and the rule Mode. 2. If the match is successful, any associated zone transform (where the Mode is Alias Pattern Match and the Pattern Behavior is Replace) is applied to the alias. 3. The search rule's Target zone is queried (with the revised alias if a zone transform has been applied) using the same protocol (SIP or H.323) as the incoming call request. Note that if there are many successful matches for multiple search rules at the same priority level, every applicable Target zone is queried. • If the alias is found, the call is forwarded to that zone. If the alias is found by more than one zone, the call is forwarded to the zone that responds first. • If the alias is not found using the native protocol, the query is repeated using the interworked protocol, depending on the Interworking mode. 4. If the alias is not found, the search rules with the next highest priority are applied (go back to step 1) until: • the alias is found, or • all target zones associated with search rules that meet the specified criteria have been queried, or • a search rule with a successful match has an On successful match setting of Stop searching Note the difference between a successful match (where the alias matches the search rule criteria) and an alias being found (where the query sent to the target zone is successful). The Stop searching option provides better control over the network's signaling infrastructure. For example, if searches for a particular domain should always be routed to a specific zone this option lets you make the search process more efficient and stop the VCS from searching any other zones unnecessarily. Overview of searches and transforms

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms About pre-search transforms The pre-search transform function allows you to modify the alias in an incoming search request. The transformation is applied by the VCS before any searches take place, either locally or to external zones. It applies to all incoming search requests received from locally registered endpoints, neighbor, traversal client and traversal server zones, and endpoints on the public internet. It does not apply to requests received from peers (which are configured identically and therefore will have already applied the same transform). Each pre-search transform defines a string against which an alias is compared, and the changes to make to the alias if it matches that string. After the alias has been transformed, it remains changed and all further call processing is applied to the new alias. Pre-search transforms are not applied to GRQ or RRQ messages received from endpoints registering with the VCS; endpoints will be registered with the alias(es) as presented in these messages. Pre-search transforms are applied prior to any possible CPL modification and Zone transforms. All peers in a cluster should be configured identically, including any pre-search transforms. A VCS in a cluster treats search requests from any of its peers as having come from its own Local Zone, and does not re-apply any pre-search transforms on receipt of the request. Pre-search transform process Up to 100 pre-search transforms can be configured. Each transform must have a unique priority number between 1 and 65534. Every incoming alias is compared with each transform in order of priority, starting with that closest to 1. If and when a match is made, the transform is applied to the alias and no further pre-search checks and transformations of the new alias will take place. The new alias is then used for the remainder of the search process. Further transforms of the alias may take place during the remainder of the search process. This may be as a result of Call Policy (also known as Administrator Policy) or User Policy (if FindMe is enabled). If this is the case, the pre-search transforms are re-applied to the new alias. Refer to the search process diagram for more information. If you add a new pre-search transform that has the same priority as an existing transform, all transforms with a lower priority (those with a larger numerical value) will have their priority incremented by one, and the new transform will be added with the specified priority. However, if there are not enough “slots” left to move all the priorities down, you will get an error message. Pre-search transforms

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Configuring pre-search transforms The Transforms page lists all the pre-search transforms currently configured on the VCS. It is used to create, edit, delete, enable and disable transforms. To go to the Transforms page: • VCS configuration > Transforms. To configure pre-search transforms using the CLI: • xConfiguration Transform [1..100] Click on the transform you want to configure (or click New to create a new transform, or click Delete to remove a transform). If you hover your mouse pointer over a transform, the transform description (if one has been defined) appears as a tooltip. Enabling and disabling transforms When you are making or testing configuration changes to your transforms, you may want to temporarily enable or disable certain transforms. You can do this by selecting the transform's check box and clicking Enable or Disable as appropriate. Any disabled transforms still appear in the transforms list but are ignored by the VCS when processing search requests. Configuration options The configurable options are: Priority Assigns a priority to this transform. Priority can be from 1 to 65534, with 1 being the highest priority. Transforms are applied in order of priority, and the priority must be unique for each transform. Description An optional free-form description of the transform. Pattern type The way in which the Pattern string must match the alias. Options are: Exact: the string must match the alias character for character. Prefix: the string must appear at the beginning of the alias. Suffix: the string must appear at the end of the alias. Regex: treats the string as a regular expression. Pattern string Specifies the pattern against which the alias is compared. Pattern behavior Specifies how the matched part of the alias is modified. Options are: Strip: the matching prefix or suffix is removed. Replace: the matching part of the alias is substituted with the text in the Replace string. Add Prefix: prepends the Additional text to the alias. Add Suffix: appends the Additional text to the alias. Replace string (Applies if Pattern Behavior is Replace.) The string to be used as a substitution for the part of the alias that matched the pattern. Additional text (Applies if Pattern Behavior is Add Prefix or Add Suffix.) The string to add as a prefix or suffix. State Indicates if the transform is enabled or not. Pre-search transforms support the use of Regular Expressions in both the Pattern String and Replace String fields. See the Regular expression reference Appendix for more information. You can test whether a pattern will match a particular alias and be transformed in the expected way by using the Check pattern tool (Maintenance > Tools > Check pattern). Note that the transforms also apply to any Publication, Subscription or Notify URIs handled by the Presence Services. Pre-search transforms (continued)

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Fallback alias The VCS could receive a call that is destined for it but which does not specify an alias. This could be because: • the caller has dialed the IP address of the VCS directly • the caller has dialed a domain name belonging to the VCS (either one of its configured SIP domains, or any domain that has an SRV record that points at the IP address of the VCS), without giving an alias as a prefix Normally such calls would be disconnected. However, the VCS allows you to specify an alias to which all such calls should be routed. This alias is known as the fallback alias and is configured on the Search rules configuration page (VCS configuration > Search rules > Configuration). To configure this setting using the CLI: • xConfiguration Call Services Fallback Alias If no fallback alias is configured, calls that do not specify an alias will be disconnected. Some endpoints do not allow users to enter an alias and an IP address to which the call should be placed. Example usage You may want to configure your fallback alias to be that of your receptionist, so that all calls that do not specify an alias are still answered personally and can then be redirected appropriately. For example, Example Inc. has the domain of example.com. The endpoint at reception has the alias [email protected]. They configure their VCS with a fallback alias of reception@ example.com. This means that any calls made directly to example.com (i.e. without being prefixed by an alias), are forwarded to [email protected], where the receptionist answers the call and directs it appropriately. Search configuration Calls to unknown IP addresses Although the VCS supports dialing by IP address, it is sometimes undesirable for a VCS to be allowed to place a call directly to an IP address that is not local. Instead, you may want a neighbor to place the call on behalf of the VCS, or not allow such calls at all. The VCS lets you configure how it behaves when receiving a call for an IP address that is not local through the Calls to Unknown IP addresses setting on the Search rules configuration page (VCS configuration > Search rules > Configuration). To configure this setting from the CLI: • xConfiguration Call Services CallsToUnknownIPAddresses About unknown IP addresses The VCS considers an IP address to be "known" if it either: • is the IP address of a locally registered endpoint • falls within the IP address range of one of the subzone membership rules configured on the VCS Calls to these IP addresses are not affected by the Calls to Unknown IP addresses setting - the VCS will always attempt to place the call (providing there is a search rule for Any IP Address against the Local Zone). All other IP addresses are considered to be "unknown" and are handled by the VCS according to its Calls to Unknown IP addresses setting. About unregistered endpoints An unregistered endpoint is any device that is not registered with an H.323 gatekeeper or SIP registrar (e.g. VCS, gatekeeper or TANDBERG Border Controller). Although most calls are made between endpoints that are registered with such systems, it is sometimes necessary to place a call to an unregistered endpoint. There are two ways to call to an unregistered endpoint: • by dialing its URI (this requires that the local VCS is configured to support URI dialing, and a DNS record exists for that URI that resolves to the unregistered endpoint's IP address) • by dialing its IP address Calls to Unknown IP addresses settings The options for the Calls to Unknown IP addresses setting are: Direct: the VCS attempts to place the call directly to the unknown IP address without querying any neighbors. Indirect: the VCS forwards the search request to its neighbors in accordance with its normal search process, meaning any zones that are the target of search rules with an Any IP Address mode. If a match is found and the neighbor’s configuration allows it to connect a call to that IP address, the VCS will pass the call to that neighbor for completion. Off: the VCS will not attempt to place the call, either directly or to any of its neighbors. This setting applies to the call's destination address prior to any zone transforms, but after any pre-search transforms, Call Policy or User Policy rules have been applied. In addition to controlling calls, this setting also determines the behavior of provisioning and presence messages to SIP devices, as these messages are routed to IP addresses. Recommended configuration for firewall traversal When the VCS Expressway is neighbored with a VCS Control for firewall traversal, you should typically set Calls to unknown IP addresses to Indirect on the VCS Control and Direct on the VCS Expressway. When a caller inside the firewall attempts to place a call to an IP address outside the firewall, it will be routed as follows: 1. The call will go from the endpoint to the VCS Control with which it is registered. 2. As the IP address being called is not registered to that VCS, and its Calls to unknown IP addresses setting is Indirect, the VCS will not place the call directly. Instead, it will query its neighbor VCS Expressway to see if that system is able to place the call on the VCS Control’s behalf. 3. The VCS Expressway receives the call and because its Calls to unknown IP addresses setting is Direct, it will make the call directly to the called IP address.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Configuring search and zone transform rules The Search rules page lists all the existing search rules. It is used to add, edit, delete, enable and disable rules. Each rule specifies the criteria used to match an alias in the source query before sending the query on to a target zone. The rule also specifies any zone transforms to apply to the alias. To go to the Search rules page: • VCS configuration > Search rules > Rules. To configure search rules using the CLI: • xConfiguration Zones Policy SearchRules Note that you can click on a column heading to sort the list, for example by Target zone or Priority. If you hover your mouse pointer over a search rule, the rule description (if one has been defined) appears as a tooltip. Click on the rule you want to configure (or click New to create a new rule, or click Delete to remove a rule). Enabling and disabling search rules When you are making or testing configuration changes to your search rules, you may want to temporarily enable or disable certain rules. You can do this by selecting the rule's check box and clicking Enable or Disable as appropriate. Any disabled rules still appear in the search rules list but are ignored by the VCS when processing search requests. Configuration options The configurable options are: Rule name A descriptive name for the search rule. Description An optional free-form description of the search rule. Priority The order in the search process that this rule is applied, when compared to the priority of the other search rules. All Priority 1 search rules are applied first, followed by all Priority 2 search rules, and so on. More than one rule can be assigned the same priority, in which case any matching target zones are queried simultaneously. Different default priorities are assigned depending on the type of the Target zone: • Local Zone: 50 • Neighbor, traversal client or traversal server zone: 100 • ENUM or DNS zone: 150 This default configuration means that the Local Zone is searched first for all aliases. If the alias is not found locally, all neighbor, traversal client and traversal server zones are searched, and if they cannot locate the alias the request is sent to any DNS and ENUM zones. Source Specifies the sources of the requests for which this rule applies. Any: locally registered devices, neighbor or traversal zones, and any non-registered devices. All zones: locally registered devices plus neighbor or traversal zones. Local Zone: locally registered devices only. Mode Determines whether a query is sent to the Target zone, based on the given alias. Alias Pattern Match: queries the zone only if the alias matches the corresponding Pattern type and Pattern string. Any Alias: queries the zone for any alias (but not IP address). Any IP Address: queries the zone for any given IP address (but not alias). Zone searching and zone transforms

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Pattern type How the pattern string must match the alias for the rule to be applied. (Applies only if the Mode is Alias Pattern Match.) Exact: the entire string must exactly match the alias character for character. Prefix: the string must appear at the beginning of the alias. Suffix: the string must appear at the end of the alias. Regex: treats the string as a regular expression. Pattern string The pattern against which the alias is compared. (Applies only if the Mode is Alias Pattern Match.) Pattern behavior Determines whether the matched part of the alias is modified before being sent to the target zone. (Applies only if the Mode is Alias Pattern Match.) Leave: the alias is not modified. Strip: the matching prefix or suffix is removed from the alias. Replace: the matching part of the alias is substituted with the text in the Replace string. The Target zone is then queried using the revised alias. Note that if you want to transform the alias before applying search rules you must use pre-search transforms. Replace string The string to substitute for the part of the alias that matches the pattern. (Applies only if the Pattern behavior is Replace.) On successful match Controls the ongoing search behavior if the alias matches the search rule. Continue: continue applying the remaining search rules (in priority order) until the endpoint identified by the alias is found. Stop: do not apply any more search rules, even if the endpoint identified by the alias is not found in the target zone. Note that if Stop is selected, any rules with the same priority level as this rule are still applied. Target zone The zone to query if the alias matches the search rule. State Indicates if the search rule is enabled or not. You can test whether a pattern matches a particular alias and is transformed in the expected way by using the Check pattern tool. You can test whether the VCS can find an endpoint identified by a given alias, without actually placing a call to that endpoint by using the Locate tool. Zone searching and zone transforms (continued)

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Examples Stripping @domain for dialing to H.323 numbers SIP endpoints can only make calls in the form of URIs - for example 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 registered as 123, the VCS will be unable to locate the alias 123@ domain and the call will fail. If you have a deployment that includes both SIP and H.323 endpoints that register using a number, you will need to set up the following pre-search and zone transforms. This will let users place calls from SIP and H.323 endpoints to H.323 endpoints registered using their H.323 E164 number only. Explanation The pre-search transform (example, below) takes any number-only dial string (such as 123) and appends the domain used in endpoint AORs and URIs in your deployment. This ensures that calls made by SIP and H.323 endpoints result in the same URI. Search rules (right) for the Local Zone then ensure that both the E164 number and full URI are searched for, so that endpoints can still be reached whether they have registered with an H.323 number (123) or a full URI (123@domain): • The first search rule takes any aliases in the format number@domain and transforms them into the format number. • To ensure that any endpoints that have actually registered with an alias in the format number@domain can also still be reached, a second search rule must be configured at a lower priority that places calls to number@ domain without transforming the alias.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Examples Transforms for alphanumeric H.323 ID dial strings This example builds on the example from the previous page. The previous example caters for number-only dial strings, however H.323 IDs do not have to be purely numeric; they can contain alphanumeric (letters and digits) characters. This example follows the same model as the previous example — a pre-search transform and two search rules to ensure that endpoints can be reached whether they have registered with an H.323 ID or a full URI — but uses a different regex (regular expression) that supports alphanumeric characters. Explanation The pre-search transform (example, below) takes any alphanumeric dial string (such as 123abc) and appends the domain used in your deployment to ensure that calls made by SIP and H.323 endpoints result in the same URI. Search rules (right) for the Local Zone then ensure that both the E164 ID and full URI are searched for, so that endpoints can still be reached whether they have registered with an H.323 ID (123abc) or a full URI (123abc@ domain): • The first search rule takes any aliases in the format string@domain and transforms them into the format string. • To ensure that any endpoints that have actually registered with an alias in the format string@domain can also still be reached, a second search rule must be configured at a lower priority that places calls to string@ domain without transforming the alias.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Combining match types and priorities By using the Any Alias and Alias Pattern Match modes when defining search rules, and applying the same or different priorities to each rule, you will have a great deal of flexibility in determining if and when the target zone is queried and whether any transforms are applied. Some example configurations are given here. The Any Alias mode does not support alias transforms. If you want to always query a zone using a different alias to that received, you need to use a mode of Alias Pattern Match in combination with a regular expression. Always query a zone with original alias (no transforms) To configure a zone so that it is always sent search requests using the original alias, set up a search rule for that zone with a mode of Any Alias. Configuring a zone for incoming calls only To configure a zone so that it is never sent an alias search request (for example if you only want to receive incoming calls from this zone), do not define any search rules that have that zone as its target. In this scenario, when viewing the zone, you can ignore the warning that no search rules exist. Examples

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Examples Filter queries to a zone without transforming It is possible to filter the search requests sent to a zone so that it is only queried for aliases that match certain criteria. For example, assume all endpoints in your regional sales office are registered to their local VCS with a suffix of @sales.example.com. In this situation, it makes sense for your Head Office VCS to query the Sales Office VCS only when it receives a search request for an alias with a suffix of @sales.example.com. Sending any other search requests to this particular VCS would take up resources unnecessarily. To achieve this, on your Head Office VCS create a zone to represent the Sales Office VCS, and set up an associated search rule with a Mode of Alias Pattern Match mode and a Pattern type of Suffix. It would also be wasteful of resources to send search requests for aliases that match this pattern to any other zone (there may be other lower priority search rules defined that would also apply to these aliases). In which case setting On successful match to Stop means that the VCS will not apply any further (lower priority) search rules. Allowing calls to IP addresses only if they come from known zones In addition to aliases, calls can be made to specified IP addresses. To pass on such calls to the appropriate target zones you must set up search rules with a mode of Any IP Address. To provide extra security you can set the rule's Source option to All Zones. This means that the query is only sent to the target zone if it originated from any configured zone or the Local Zone.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Examples Query a zone for original and transformed alias You may want to query a zone for the original alias at the same time as you query it for a transformed alias. To do this, configure one search rule (example top, right) with a mode of Any Alias, and a second search rule (example bottom, right) with a mode of Alias Pattern Match along with details of the transform to be applied. Both searches must be given the same Priority level. For example, you may want to query a neighbor zone for both a full URI and just the name (the URI with the domain removed). To achieve this, on your local VCS configure the two search rules that target the zone representing the neighbor VCS as shown.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Searches and transforms Examples Query a zone for two or more transformed aliases Zones are queried in order of priority of the search rules configured against them. It is possible to configure multiple search rules for the same zone each with, for example, the same Priority and an identical Pattern String to be matched, but with a different replacement patterns. In this situation, the VCS queries that zone for each of the new aliases simultaneously. (Any duplicate aliases produced by the transforms are removed prior to the search requests being sent out.) If any of the new aliases are found by that zone, the call is forwarded to the zone. It is then up to the controlling system to determine the alias to which the call will be forwarded. The example search rules shown here both look for aliases with a suffix of example.com. The top example then replaces the suffix with example.co.uk and the bottom example replaces it with example.net.

TANDBERG VIDEO COMMUNICATION SERVER ADMINISTRATOR GUIDE Introduction Overview and status System configuration VCS configuration Zones and neighbors Clustering and peers Call processing Bandwidth control Firewall traversal Appendices Applications Maintenance Call Policy The VCS lets you set up rules to control which calls are allowed, which calls are rejected, and which calls are to be redirected to a different destination. These rules are known as Call Policy (or Administrator Policy). If Call Policy is enabled and has been configured, each time a call is made the VCS will execute the policy in order to decide, based on the source and destination of the call, whether to • proxy the call to its original destination • redirect the call to a different destination or set of destinations • reject the call. When enabled, Call Policy is executed for all calls going through the VCS. You can set up Call Policy in two ways: • by configuring basic Call Policy using the web interface (note that this only lets you Allow or Reject specified calls) • by uploading a script written in the Call Processing Language (CPL) Only one of these two methods can be used at any one time to specify Call Policy. If a CPL script has been uploaded, this will disable use of the web interface to configure Call Policy. To use the web interface, you must delete the CPL script that has been uploaded. Use Call Policy to determine which callers can make or receive calls via the VCS. Use Allow and Deny lists to determine which aliases can or cannot register with the VCS. Call Policy uses the source and destination of a call to determine the action to be taken. Policy interacts with authentication when considering the source alias of the call. If your VCS is part of a secure environment, any policy decisions based on the source of the call should only be made when that source can be authenticated. Whether or not the VCS considers an endpoint to be authenticated depends on the Authentication Mode setting of the VCS. Authentication mode off When Authentication Mode is set to Off, calls will be accepted from any endpoint or neighbor. The assumption is that the source alias is trusted, so authentication is not required. Authentication mode on When Authentication mode is set to On, all endpoints and neighbors are required to authenticate with it before calls will be accepted. If a call is received from an unauthenticated source (e.g. neighbor or endpoint) the call’s source aliases will be removed from the call request and replaced with an empty field before the Call Policy is executed. This is because there is a possibility that the source aliases could be forged and therefore they should not be used for policy decisions in a secure environment. This means that, when Authentication Mode is On and you configure policy based on the source alias, it will only apply to authenticated sources. The VCS determines whether or not an endpoint is authenticated as follows: H.323 When Authentication mode is set to On, for the purposes of Call Policy, an H.323 endpoint is considered to be authenticated if either of the following conditions apply: • it is a locally registered endpoint. (Because Authentication Mode is On, the registration will have been accepted only after the endpoint authenticated successfully with the VCS.) • it is a remote endpoint that is registered to and authenticated with a VCS that is a neighbor, traversal client or traversal server of the local VCS, and that remote VCS has in turn authenticated with the local VCS. An H.323 endpoint is considered to be unauthenticated when: • it is a remote endpoint registered to a neighbor and that neighbor has not authenticated with the VCS. This is regardless of whether or not the endpoint authenticated with the neighbor. SIP When Authentication mode is set to On, for the purposes of Call Policy a SIP endpoint is considered to be authenticated when: • it falls within one of the domains for which the VCS is authoritative and has successfully responded to an authentication challenge. This endpoint could be registered to the local VCS or a VCS that is a traversal server or traversal client of the local VCS, as long as it is authoritative for the domain in the endpoint's AOR. A SIP endpoint is considered to be unauthenticated if any of the following conditions apply: • it does not fall within one of the domains for which the VCS is authoritative, or • it has failed to successfully respond to an authentication challenge, or • it has successfully responded to an authentication challenge but its From or Reply-To addresses are not compatible with the alias origin settings. About Call Policy Call Policy and authentication