Polycom Unified Communications in RealPresence Access Director System Environments

Transcription

1 Solution Deployment Guide Version 4.1 December E Polycom Unified Communications in RealPresence Access Director System Environments

2 Copyright 2014, Polycom, Inc. All rights reserved. No part of this document may be reproduced, translated into another language or format, or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc America Center Drive San Jose, CA USA Trademarks Polycom, the Polycom logo and the names and marks associated with Polycom products are trademarks and/or service marks of Polycom, Inc. and are registered and/or common law marks in the United States and various other countries. All other trademarks are property of their respective owners. No portion hereof may be reproduced or transmitted in any form or by any means, for any purpose other than the recipient's personal use, without the express written permission of Polycom. End User License Agreement By installing, copying, or otherwise using this product, you acknowledge that you have read, understand and agree to be bound by the terms and conditions of the End User License Agreement for this product. The EULA for this product is available on the Polycom Support page for the product. Patent Information The accompanying product may be protected by one or more U.S. and foreign patents and/or pending patent applications held by Polycom, Inc. Open Source Software Used in this Product This product may contain open source software. You may receive the open source software from Polycom up to three (3) years after the distribution date of the applicable product or software at a charge not greater than the cost to Polycom of shipping or distributing the software to you. To receive software information, as well as the open source software code used in this product, contact Polycom by at OpenSourceVideo@polycom.com. Disclaimer While Polycom uses reasonable efforts to include accurate and up-to-date information in this document, Polycom makes no warranties or representations as to its accuracy. Polycom assumes no liability or responsibility for any typographical or other errors or omissions in the content of this document. Limitation of Liability Polycom and/or its respective suppliers make no representations about the suitability of the information contained in this document for any purpose. Information is provided "as is" without warranty of any kind and is subject to change without notice. The entire risk arising out of its use remains with the recipient. In no event shall Polycom and/or its respective suppliers be liable for any direct, consequential, incidental, special, punitive or other damages whatsoever (including without limitation, damages for loss of business profits, business interruption, or loss of business information), even if Polycom has been advised of the possibility of such damages. Customer Feedback We are striving to improve our documentation quality and we appreciate your feedback. your opinions and comments to DocumentationFeedback@polycom.com. Polycom Support Visit the Polycom Support Center for End User License Agreements, software downloads, product documents, product licenses, troubleshooting tips, service requests, and more. 2

3 Contents Conventions Used in Polycom Guides Information Elements Typographic Conventions About This Guide RealPresence Access Director System Editions Related Documentation Required Skills Unified Communications with the Polycom RealPresence Access Director Solution Overview of the Polycom RealPresence Access Director System Solution RealPresence Access Director System Solution Deployment Models Deployment with One Firewall and a Single Network Interface Deployment in a DMZ Environment with One or More Network Interfaces Integration with an F5 Load Balancer Deployment in a Two-System Tunnel Configuration Other Deployment Models Supported Call Scenarios Remote User Connections (SIP and H.323) Guest User Connections (SIP and H.323) Federated or Neighbored Trust Connections (SIP and H.323) Products Supported in this Solution Deploying the RealPresence Access Director System in a Corporate DMZ Environment Configure the DNS Service Task 1: Create DNS A and PTR records on the external DNS server Task 2: Create a DNS SRV record on the external DNS server Task 3: Create DNS A and PTR records on the internal DNS server Task 4: Create DNS SRV records on the internal DNS server Task 5: Validate DNS settings on the external DNS server Polycom, Inc. 3

4 Task 6: Validate DNS settings on the internal DNS server Configure Firewalls and Ports Firewalls with SIP/H.323 ALG Outside Firewall Configuration Inside Firewall Configuration Port Mapping Install and Configure the RealPresence Access Director System Task 1: Perform Basic Installation Task 2: Configure Time Settings Task 3: Activate the License Appliance Edition Virtual Edition Task 4: Configure Network Settings Configure the RealPresence Resource Manager System Configure the RealPresence Access Director System Task 1: Configure Access Proxy Settings Task 2: Configure Basic Access Control List Settings Task 3: Configure System Certificates Task 4: Provision the RealPresence Access Director System Configure the Polycom RealPresence DMA System Task 1: Enable SIP Device Authentication Task 2: Configure an External SIP Peer to Support SIP Open B2B Calls Task 3: Configure SIP Settings for Guest Users SIP Settings for Guest Users on the Polycom DMA System SIP Settings for Guest Users on the RealPresence Access Director System Task 4: Configure SIP Settings for Remote Users SIP Settings for Remote Users on the RealPresence Access Director System Configure Polycom Endpoint Systems Task 1: Configure Polycom HDX Series Endpoints Task 2: Configure the Polycom Group Series System Task 3: Configure Polycom RealPresence Mobile or Desktop Endpoints Professional Mode Sign-In Settings Configure the Polycom RealPresence Collaboration Server Integrate Two or More Systems with an F5 Load Balancer F5 Load Balancer Configuration Requirements F5 Load Balancer Impacts on other RealPresence Access Director System Features.. 38 Deploying Two RealPresence Access Director Systems in a Tunnel Configuration 39 Configure the DNS Service for the Two-System Tunnel Polycom, Inc. 4

5 Configure Firewalls and Ports Outside Firewall Configuration Inside Firewall Configuration Install and Configure the RealPresence Access Director Systems Task 1: Perform Basic Installation Task 2: Synchronize the Time and Set the Time Zones Task 3: Activate the System Licenses for Appliance Edition Servers Task 4: Configure Network Settings for the Tunnel Server Task 5: Configure Network Settings for the Tunnel Client Task 6: Configure Two-Box Tunnel Settings on the Tunnel Server Task 7: Configure Two-Box Tunnel Settings on the Tunnel Client Task 8: Configure System Certificates Task 9: Configure Access Control List Rules and Rule Settings Configure the RealPresence Resource Manager System Configure the Polycom RealPresence DMA System Configure Additional Polycom Components Federation Between RealPresence Access Director Systems Federation in a SIP Environment Task 1: Create Additional DNS SRV Records on the External DNS Server Task 2: Configure the RealPresence Access Director Systems to Support Federated SIP Calls Task 3: Configure the Polycom RealPresence DMA Systems to Support Federated SIP Calls 49 Federation in an H.323 Environment Task 1: Configure the RealPresence Access Director Systems to Support Neighbored H.323 calls Task 2: Configure the Polycom RealPresence DMA Systems to Support Federated H.323 Calls Federation Between RealPresence Access Director and Other Systems Federation in an H.323 Environment with Polycom VBP-E Systems Task 1: Create an Additional DNS A Record on the External DNS Server Task 2: Create Additional DNS SRV Records on the External DNS Server Task 3: Configure the RealPresence Access Director Systems to Support Neighbored H.323 calls Task 4: Configure the Polycom RealPresence DMA System to Support Federated H.323 Calls Task 5 (Conditional): Configure the CMA System to Support Federated H.323 Calls Task 6 (Conditional): Configure the VBP-5300E System to Support Federated H.323 Calls. 55 Task 7 (Conditional): Configure the VBP-5300E System in Embedded Gatekeeper Mode to Polycom, Inc. 5

6 Support Federated H.323 Calls Federation in a SIP Environment with Acme Packet Verifying Deployment Verifying Access Proxy Verifying Call Success Verifying Certificates Required Ports Management Access Management Access Ports SIP Signaling SIP WAN Ports SIP LAN Ports H.323 Signaling H.323 and WAN Ports H.323 and LAN Ports Access Proxy Access Proxy WAN Ports Access Proxy LAN Ports Media Media WAN Ports Media LAN Ports Two-System Tunnel Communication Comparison of Two-box Tunnel Deployment and Standard Deployment Ports Network Interface Configurations Single Firewall Deployment with One Network Interface DMZ Deployment with One or More Network Interfaces Standard Configuration LAN-WAN Configuration Two-System Tunnel Deployment Tunnel Server Network Interface Configuration Tunnel Client Network Interface Configuration Polycom, Inc. 6

7 Conventions Used in Polycom Guides Polycomguides contains terms, graphical elements, and a few typographic conventions. Familiarizing yourself with these terms, elements, and conventions will help you successfully perform tasks. Information Elements Polycom guides may include any of the following icons to alert you to important information. Icons Used in Polycom Guide Name Icon Description Note Caution Warning Web Info The Note icon highlights information of interest or important information needed to be successful in accomplishing a procedure or to understand a concept. The Caution icon highlights information you need to know to avoid a hazard that could potentially impact device performance, application functionality, or successful feature configuration. The Warning icon highlights an action you must perform (or avoid) to prevent issues that may cause you to lose information or your configuration setup, and/or affect phone or network performance. The Web Info icon highlights supplementary information available online such as documents or downloads on support.polycom.com or other locations. Polycom, Inc. 7

8 Conventions Used in Polycom Guides Typographic Conventions A few typographic conventions, listed next, are used in Polycom guides to distinguish types of in-text information. A Typographic Conventions Convention Bold Italics Blue Text Courier Description Highlights interface items such as menus, menu selections, window and dialog names, soft keys, file names, and directory names when they are involved in a procedure or user action. Also used to highlight text to be entered or typed. Used to emphasize text, to show example values or inputs (in this form: <example>), and to show titles of reference documents available from the Polycom Support website and other reference sites. Used for cross references to other sections within this document and for hyperlinks to external sites and documents. Used for code fragments and parameter names. Polycom, Inc. 8

9 About This Guide This guide describes the Polycom RealPresence Access Director system solution and the process of deploying the products in the solution. The solution provides firewall traversal for the connections required for the supported deployment architecture, models, and user scenarios. RealPresence Access Director System Editions The RealPresence Access Director system is available in an Appliance Edition (packaged with a system server) and a Virtual Edition (packaged as software only). Most of the functionality described in this document applies to both editions, and so the product references are general that is, the RealPresence Access Director system. However, when information applies to a specific edition, the reference will be specific that is, RealPresence Access Director, Virtual Edition or RealPresence Access Director, Appliance Edition. Related Documentation This guide is meant to supplement the associated product documentation, not replace it. When deploying the systems in this solution, please have the product documentation accessible, specifically. Polycom RealPresence Access Director System Release Notes Polycom RealPresence Access Director System, Appliance Edition Getting Started Guide or Polycom RealPresence Access Director System, Virtual Edition Getting Started Guide Polycom RealPresence Access Director System Administrator Guide Polycom RealPresence Platform Director System Administrator Guide In addition, you will need the product documentation for the other infrastructure products required for this solution, including: Polycom RealPresence DMA System Operations Guide Polycom RealPresence Resource Manager System Operations Guide Polycom RealPresence Collaboration Server System Administrator Guide Required Skills Integrating Polycom infrastructure and endpoint systems with the RealPresence Access Director system requires planning and elementary knowledge of Polycom video conferencing and video conferencing administration. Polycom, Inc. 9

10 This is not a training document. Polycom assumes those deploying this solution have a solid understanding of networking, firewalls, Network Address Translation (NAT), Domain Name Systems (DNS), H.323, and SIP concepts. Polycom, Inc. 10

11 Unified Communications with the Polycom RealPresence Access Director Solution In this solution, Polycom s integrated suite of video conferencing systems includes the RealPresence Access Director system, which: Secures the borders to the enterprise IP network, the private VPN, and the Internet for video collaboration within and beyond the firewall. Enables high-quality and secure unified communications between divisions or enterprises, remote users, and guest users. Combines remote, guest, open, and B2B calling scenarios with SIP and H.323 (AVC and SVC) capabilities. Provides secure scalability for a mobile workforce. The following topics describe the Polycom solution that includes the RealPresence Access Director system as the session border controller (SBC) for a site s IP network. Overview of the Polycom RealPresence Access Director System Solution RealPresence Access Director System Solution Deployment Models Supported Call Scenarios Products Supported in this Solution Overview of the Polycom RealPresence Access Director System Solution The Polycom video infrastructure integrates with the RealPresence Access Director system to provide video conferencing management for remote, guest, federated, and unfederated users with secure firewall traversal for all of the required connections. The following table describes the network traversal services this solution secures. Component HTTPS Access Proxy XMPP Access Proxy Description Enables remote and guest users via designated video endpoints to make HTTPS connections to the RealPresence Access Director system, which are then proxied to the internal Polycom RealPresence Resource Manager system, the RealPresence Content Sharing Suite, and other HTTPS application servers, including the Polycom RealPresence CloudAXIS Suite Experience Portal (MEA) and the RealPresence CloudAXIS Services Portal (WSP). Enables XMPP signaling from remote users via designated video endpoints to traverse the firewall to the internal XMPP servers you specify in configuration settings. XMPP access proxy also enables sending of outgoing XMPP signaling to remote endpoints. Polycom, Inc. 11

12 Component LDAP Access Proxy HTTP Tunnel Proxy SIP Signaling Description Enables remote and guest users via designated video endpoints to make LDAP connections to the RealPresence Access Director system, which are then proxied to the internal LDAP servers you specify in configuration settings. used by the RealPresence Resource Manager system, or other LDAP application servers. An HTTP tunnel proxy enables CloudAXIS suite SIP guest users to attend video conferences in your enterprise s CloudAXIS suite Experience Portal. Some restrictive networks block outgoing UDP-based traffic and can limit outgoing TCP traffic to ports 80 and 443. In these situations, if a CloudAXIS suite SIP guest cannot establish a native SIP/RTP connection to a video conference, the RealPresence Access Director system can act as a web proxy to tunnel the SIP guest call on port 443. Once the SIP guest is connected to a meeting, the RealPresence Access Director system continues to tunnel TCP traffic, including SIP signaling, media, and Binary Floor Control Protocol (BFCP)/TCP content. Enables: Firewall traversal for SIP traffic from remote and guest users with supported video endpoints to the internal SIP server. SIP open business-to-business (B2B) calling, which supports calls from external SIP endpoints that are not registered or are not members of a federated enterprise or division. Outbound SIP signaling to registered, guest and open B2B endpoints. Use of separate interfaces for external and internal SIP signaling traffic. Modifying SIP signaling to direct media through the media relay when required. H.323 Signaling Enables: Firewall traversal for H.323 traffic from remote and guest users with supported video endpoints to the internal gatekeeper. H.323 open business-to-business (B2B) calling, which supports calls from external H.323 endpoints that are not registered or are not members of a neighbored enterprise or division. Outbound H.323 signaling to registered, guest and open B2B endpoints. Use of separate interfaces for external and internal H.323 signaling messages Functionality to understand and manipulate all H.323 Annex O dialing messages. Functionality to route all H.323 messages from guest users to and from the internal gatekeeper. Media Relay Static Routing Enables firewall traversal for media to and from remote and guest users with supported video endpoints. The media relay functions as a Session Border Controller (SBC)-based relay. Enables use of static routes to route traffic to the correct network destination. One or more static routes may be defined for each network interface H.460 Support The RealPresence Access Director system enables videoconference participants with H.460-enabled endpoints to register to a Polycom RealPresence Distributed Media Application (RealPresence DMA system), which acts as an H.323 gatekeeper, and place and receive H.323 calls across firewalls/nats. Polycom, Inc. 12

13 Component Access Control Lists Configurable Port Ranges Two-System (Two-box) Tunnel Deployment F5 Load Balancer Support Description The RealPresence Access Director system supports the use of access control lists for SIP and H.323 calls that come through the external signaling ports. Access control list rules define whether the RealPresence Access Director system allows or denies a specific type of SIP or H.323 request from a public network, which provides increased protection against external security threats. The RealPresence Access Director system allows you to configure port range settings to decrease the number of dynamic ports that need to be open on your enterprise s firewall. When you specify a beginning port range number for signaling, media, or access proxy dynamic source ports, the RealPresence Access Director system automatically calculates the end port range number for that service, based on the number of calls on your system license. Two RealPresence Access Director systems can be deployed to tunnel traffic to and from your inside enterprise network. One RealPresence Access Director system is deployed in the enterprise back-to-back DMZ between the inside and outside firewall and the other system is deployed behind the inside firewall. Two or more RealPresence Access Director systems can be deployed behind an F5 Networks load balancer to increase network capacity (concurrent users) and improve overall performance by decreasing the burden on any one RealPresence Access Director system. Appliance Edition and Virtual Edition The RealPresence Access Director system is available in an Appliance Edition, packaged with a system server for an appliance based infrastructure. It is also available in a Virtual Edition, packaged as software only for deployment in a virtualized datacenter. Both editions provide the same firewall traversal functionality and can be integrated with other Polycom RealPresence Platform components to provide a seamless video collaboration experience. Polycom RealPresence Platform, Virtual Edition products such as the RealPresence Access Director, Virtual Edition require the Polycom RealPresence Platform Director to deploy the software and to manage licensing. The RealPresence Platform Director provides the flexibility to deploy, license, and monitor the RealPresence Platform, Virtual Edition products using general purpose hardware in an organization's datacenter or in the cloud. The RealPresence Platform Director is available at no charge from Polycom s support website (support.polycom.com). Before you install or upgrade your software, install the RealPresence Platform Director system and verify that your product is licensed. The RealPresence Platform Director system requires VMware vcenter Server. For complete instructions on how to deploy the RealPresence Access Director system, Virtual Edition, see the Polycom RealPresence Access Director System, Virtual Edition, Getting Started Guide and the Polycom RealPresence Platform Director System Administrator Guide. RealPresence Access Director System Solution Deployment Models The RealPresence Access Director system solution can be deployed based on several different models: Polycom, Inc. 13

14 Deployment with One Firewall and a Single Network Interface Deployment in a DMZ Environment with One or More Network Interfaces Deployment in a Two-System Tunnel Configuration Other Deployment Models See Network Interface Configurations for diagrams of the deployment models and configuration details for the network interfaces. Deployment with One Firewall and a Single Network Interface In this simple model, the RealPresence Access Director system is deployed at the DMZ of the single firewall. All signaling, media, access proxy, and management traffic use one network interface and IP. Deployment in a DMZ Environment with One or More Network Interfaces In general, Polycom recommends that the RealPresence Access Director system be deployed in a corporate back-to-back DMZ; that is, deployed between an outside (also referred to as public or external) firewall and inside (also referred to as private or internal) firewall. Polycom Unified Communications with the RealPresence Access Director System Standard Deployment illustrates a standard deployment. Polycom Unified Communications with the RealPresence Access Director System Standard Deployment In this implementation: The outside firewall, which resides between the WAN (Untrust) and the RealPresence Access Director system in the DMZ, must be in Destination NAT mode. In this mode: When inbound packets from the WAN pass through the firewall, it translates the destination IP to that of the RealPresence Access Director system. Polycom, Inc. 14

15 When outbound packets from the enterprise network pass through the firewall, it translates the source IP to the outside IP of the firewall system. A static and direct 1:1 NAT mapping is recommended for the outside firewall. The inside firewall, which resides between the RealPresence Access Director system in the DMZ and the LAN (Trust), must be in Route mode. In this mode, the firewall does not change the destination or source IP, so no translation is required or supported. For details on how to configure the network interfaces, see DMZ Deployment with One or More Network Interfaces. Deployment in a DMZ environment takes advantage of the firewall s security functionality. However, because all media and signaling traffic flows through the firewall, performance can be affected. A RealPresence Access Director system that uses at least two network interfaces can be deployed in a two-legged configuration. In this scenario, signaling and media traffic are split between the interfaces to separate external and internal traffic. Integration with an F5 Load Balancer Two or more RealPresence Access Director systems can be deployed behind an F5 Networks load balancer to increase network capacity (concurrent users) and improve overall performance by decreasing the burden on any one RealPresence Access Director system. The F5 load balancer acts upon data in the transport layer and serves as a TCP or UDP reverse proxy to distribute (balance) incoming sign-in, registration, and call requests across multiple RealPresence Access Director systems. When the F5 load balancer receives a request, it distributes that request to a particular RealPresence Access Director system according to the Round Robin algorithm. An F5 load balancer can help to ensure RealPresence Access Director system reliability and availability by sending requests only to systems that can respond in a timely manner. The configuration of the F5 load balancer s routing policy must support persistence. Persistence ensures that all requests from the same source IP during a session are distributed to the same RealPresence Access Director system. A heartbeat connection between the F5 load balancer and all RealPresence Access Director systems ensures that requests are routed only to an accessible system. The F5 load balancer must be configured to integrate with your RealPresence Access Director systems, but no configuration is necessary on the RealPresence Access Director systems. See Integrate Two or More Systems with an F5 Load Balancer. Deployment in a Two-System Tunnel Configuration Two RealPresence Access Director systems can be deployed in a tunnel configuration (see The RealPresence Access Director System Two-System Tunnel Deployment). In this model, one system acts as the tunnel server and is deployed in the corporate back-to-back DMZ. The other system serves as a tunnel client and is deployed behind the inside firewall. Communication between the tunnel server and the tunnel client is through UDP transmission. In a tunnel configuration, port mapping on the inside firewall between the tunnel server and the tunnel client is not required. Instead, when you enable the tunnel feature on the tunnel server, the tunnel port is open and listening for communication from the tunnel client. When you enable the tunnel feature on the tunnel client, the client then registers to the tunnel server through the listening tunnel port. Polycom, Inc. 15

16 The RealPresence Access Director System Two-System Tunnel Deployment Other Deployment Models If you have a three-legged firewall (one with at least three network interfaces), the same firewall can separate the RealPresence Access Director system in the DMZ from both the internal LAN and the Internet. Note that in this configuration, not all firewall traffic goes through the RealPresence Access Director system. The three-legged firewall configuration requires a static and direct 1:1 NAT mapping between the WAN (untrust) and the DMZ, and Route mode between the DMZ and the LAN (trust). Network Interface Configurations includes diagrams and the recommended network interface configurations supported for this solution. Supported Call Scenarios The deployment models for this Polycom solution support the following user scenarios: Remote User Connections (SIP and H.323) Guest User Connections (SIP and H.323) Federated or Neighbored Trust Connections (SIP and H.323) Remote User Connections (SIP and H.323) A remote user is an enterprise user with a managed Polycom SIP or H.323 endpoint that lies outside of the enterprise network. In this user scenario: Remote users can participate in video calls with other enterprise users as if they were inside the enterprise network. Remote users can receive calls as if they were inside the network. Remote users can receive management services including endpoint provisioning, user directory, and XMPP contact list and presence services, as well as SIP and H.323 calling, calendaring, and scheduling services. All RealPresence Access Director system deployment models support this user scenario. Guest User Connections (SIP and H.323) A guest user is a user with a non-managed SIP or H.323 endpoint that lies outside of the enterprise network. In this user scenario: Guest users can participate in video calls with division or enterprise users without being members of the site. Enterprise users can place H.323 calls out to guest users. Polycom, Inc. 16

17 Enterprise users can place SIP calls out to guest users. Guest users do not have access to any management services such as endpoint provisioning, user directory, XMPP contact list and presence services, or calendaring and scheduling services. All RealPresence Access Director system deployment models support this user scenario. Federated or Neighbored Trust Connections (SIP and H.323) Enterprise users from one division or enterprise can call enterprise users from another division or enterprise when: Both division or enterprise users have supported and managed SIP or H.323 endpoints. Both division or enterprise sites have implemented a RealPresence Access Director system or other access solution for federation. The federated sites are connected by a mutually trusted connection. For SIP systems, this trust relationship is a SIP trunk. For H.323 systems, this trust relationship is mutually neighbored gatekeepers. The sites have established and supported dial plans. In this user scenario, each user has access to their site s provisioning, directory, presence, and calling services, as well as contact lists. All RealPresence Access Director system deployment models support this user scenario. Additionally, you must complete the deployment processes described in the appropriate section for your deployment model: Federation Between RealPresence Access Director Systems. Federation Between RealPresence Access Director and Other Systems. Products Supported in this Solution The following products are supported in this RealPresence Access Director system solution. Polycom Product Version Function in Solution NAT, Firewall, Session Border Controllers Polycom RealPresence Access Director Polycom Video Border Proxy (VBP) 5300E 4.1 Provides secure access to H.323 and SIP video services for small- to medium-sized federated enterprises In some solution models, provides border control functionality for federated enterprises. Acme Packet Net-Net ESD Testing was carried out specifically with the Acme Packet Net-Net ESD-3820 platform running S-CX6.3.MR-2 GA (B\build 385) software. Other Acme Packet E-SBCs such as Net-Net ESD-4500, Net-Net ESD-SE and Net-Net ESD-VME also run the same line of C-series software. These other products can also be used in this Polycom RealPresence solution. Management Systems and Recorders Polycom RealPresence Resource Manager Provisions and manages remote endpoints, and enables directory and presence services Polycom, Inc. 17

18 Polycom Product Version Function in Solution Polycom RealPresence Content Sharing Suite Microsoft Active Directory Gatekeepers, Gateways, and MCUs Polycom RealPresence Collaboration Server (RMX) 1500, 2000, and 4000 Polycom RealPresence Distributed Media Application (DMA) 7000 Endpoints Polycom HDX 7000, 8000, and 9000 series x Provides content sharing interoperability between Microsoft Lync 2010 and 2013 clients and Polycom video conferencing solutions Directory service that authenticates and authorizes all registered users and devices Provides bridge capability for SIP and H.323 conferences, including support for content over video Functions as SIP proxy/registrar, H.323 gatekeeper, SIP and H.323 gateway, and bridge virtualizer Video conferencing endpoint systems Polycom RealPresence Mobile 3.2 Serves as client application for supported mobile devices Polycom RealPresence Desktop Serves as desktop client application Polycom RealPresence Group Series 300/ Video conferencing endpoint systems Cisco C20 Codec TC7.1.1 Video conferencing endpoint system Cisco C40 Codec TC7.1.1 Video conferencing endpoint system Cisco EX60 Desktop System TC7.1.1 Video conferencing endpoint system Cisco EX90 Desktop System TC7.1.1 Video conferencing endpoint system Cisco 1700 MXP Desktop System F9.3.1 Video conferencing endpoint system Polycom Solution Polycom RealPresence CloudAXIS Suite Polycom RealPresence Platform Director 1.6.x Provides two virtualized server components that enable users to schedule and participate in video conferences accessed from a web browser or other hardware and software video endpoints, including the Polycom RealPresence Mobile application. Provides the ability to deploy, license, and monitor the RealPresence Platform, Virtual Edition products in an organization's data center or in the cloud. Polycom, Inc. 18

19 Deploying the RealPresence Access Director System in a Corporate DMZ Environment This chapter describes the general configuration processes required for deploying the RealPresence Access Director system in a DMZ Environment with one or more network interfaces. The chapters that follow describe additional configuration processes required for the specific deployment models. The following cross-functional flow chart identifies the tasks you must perform. See these topics for detailed information about each of the tasks: Configure the DNS Service Configure Firewalls and Ports Install and Configure the RealPresence Access Director System Configure the RealPresence Resource Manager System Polycom, Inc. 19

20 Configure the RealPresence Access Director System Configure the Polycom RealPresence DMA System Configure Polycom Endpoint Systems Configure the Polycom RealPresence Collaboration Server Integrate Two or More Systems with an F5 Load Balancer Configure the DNS Service This section describes creating domain name system (DNS) records to enable this solution. Note: If necessary, get help with configuring the DNS records If you re not familiar with DNS administration, the creation of various kinds of DNS resource records, and your enterprise s DNS implementation, please consult with someone who is. Task 1: Create DNS A and PTR records on the external DNS server Create a DNS A () record and associated reverse PTR (pointer) record on the external DNS server. The A record maps the FQDN of the RealPresence Access Director system to its public IP for signaling and access proxy. The PTR record for reverse lookup resolves the public IP of the RealPresence Access Director to its FQDN. If the RealPresence Access Director system has the FQDN name rpad.example.com, add an A record as follows: rpad.example.com IN A Where: FQDN = rpad.example.com Class = IN (Internet) A = Record type = RealPresence Access Director system IP If your DNS management tool does not automatically create the PTR record that corresponds to the A record, add the PTR record manually as follows: in-addr.arpa. Where: in-addr.arpa. = the RealPresence Access Director system IP stored as the reverse DNS domain name, which points back to rpad.example.com If you have deployed the RealPresence Content Sharing Suite or RealPresence CloudAXIS suite as part of your RealPresence Access Director solution, create a DNS A record and a PTR record on the external DNS server for the host(s) in that system. The A records will resolve to the RealPresence Access Director system s public IP for signaling and access proxy; the PTR records will resolve to the RealPresence Access Director system s FQDN. Polycom, Inc. 20

21 Task 2: Create a DNS SRV record on the external DNS server Create DNS service records (SRV records) on the external DNS server to map the SRV service es for dynamic endpoint provisioning, SIP registrar, and gatekeeper services to the FQDN of the RealPresence Access Director system.» If the RealPresence Access Director system has the FQDN name rpad.example.com, add these SRV records: _cmaconfig._tcp.example.com IN SRV rpad.example.com(this SRV record is required by the Auto Find Provisioning Server feature of dynamically-managed endpoints.) _sip._tcp.example.com IN SRV rpad.example.com _sip._udp.example.com IN SRV rpad.example.com _sip._tls.example.com IN SRV rpad.example.com _sips._tcp.example.com IN SRV rpad.example.com _h323cs._tcp.example.com IN SRV rpad.example.com _h323ls._udp.example.com IN SRV rpad.example.com Where, for example: Service = _sip Protocol = _tcp Priority = 0 Weight = 100 Port = 5060 Host offering this service = rpad.example.com Task 3: Create DNS A and PTR records on the internal DNS server Create three DNS A records on the internal DNS server as identified in the following sections. The RealPresence Resource Manager system, the RealPresence DMA system, and the RealPresence Access Director system in the internal network each need one A record on the internal DNS server to map their FQDNs to their respective IP es. Each system also needs a corresponding PTR record to resolve their IP es to their FQDNs. For example: 1 If the FQDN of RealPresence Resource Manager system is rprm.example.com, and its IP is , create an A record: rprm.example.com IN A If the FQDN of the RealPresence DMA system is dma.example.com, and its IP is , create an A record: dma.example.com IN A If the FQDN of RealPresence Access Director system is rpad.example.com, and its IP is , create an A record: rpad.example.com IN A Polycom, Inc. 21

22 Task 4: Create DNS SRV records on the internal DNS server The RealPresence Resource Manager system requires a DNS SRV record on the internal DNS server to dynamically provision endpoints. The DNS SRV record maps the SRV service to the FQDN of the RealPresence Resource Manager system. If the FQDN of the RealPresence Resource Manager system is rprm.example.com, and its IP is , create an SRV record as follows: _cmaconfig._tcp.example.com IN SRV rprm.example.com The RealPresence DMA system requires several DNS SRV records on the internal DNS server to map the SRV service for SIP registrar and gatekeeper services to the FQDN of the RealPresence DMA system. If the FQDN of the RealPresence DMA system is dma.example.com, and its IP is , create these SRV records: _sip._tcp.example.com IN SRV dma.example.com _sip._udp.example.com IN SRV dma.example.com _sip._tls.example.com IN SRV dma.example.com _sips._tcp.example.com IN SRV dma.example.com _h323cs._tcp.example.com IN SRV dma.example.com _h323ls._udp.example.com IN SRV dma.example.com Task 5: Validate DNS settings on the external DNS server The following steps use the Windows nslookup commands as an example. The procedure is similar on Mac and Linux. To validate the DNS settings on the external DNS server: 1 From a Windows computer located on the Internet network, open a command line. 2 Type nslookup rpad.example.com to check the A record of the RealPresence Access Director system. The response should include the corresponding RealPresence Access Director system's public IP. 3 Type nslookup -type=srv _cmaconfig._tcp.example.com to check the SRV record. The response should include the FQDN of each RealPresence Access Director system. Task 6: Validate DNS settings on the internal DNS server The following steps use the Windows nslookup commands as an example. The procedure is similar on Mac and Linux. To validate the DNS settings on the internal DNS server: 1 From a Windows computer located on the internal network, open a command line. 2 Type nslookup rprm.example.com to check the A record of the RealPresence Resource Manager system. The response should include the corresponding RealPresence Resource Manager system's IP. 3 Type nslookup dma.example.com to check the A record of the RealPresence DMA system. The response should include the corresponding DMA system's IP. Polycom, Inc. 22

23 4 Type nslookup rpad.example.com to check the A record of the RealPresence Access Director system. The response should include the corresponding RealPresence Access Director system's internal IP. 5 Type nslookup -type=srv _cmaconfig._tcp.example.com to check the SRV record of the RealPresence Resource Manager system. The response should include the FQDN of RealPresence Resource Manager system. 6 Type the following commands to check the SRV records of the RealPresence DMA system: nslookup -type=srv _sip._tcp.example.com nslookup -type=srv _sip._udp.example.com nslookup -type=srv _sip._tls.example.com nslookup _sips._tcp.example.com nslookup _h323cs._tcp.example.com nslookup _h323ls._udp.example.com IN SRV Each response should include the FQDN of the RealPresence DMA system. Configure Firewalls and Ports For greater security, Polycom recommends that you disable SSH and web access connectivity from the Internet, and enable SSH and web access connectivity from the LAN. Caution: If necessary, get help with firewall settings If you re not familiar with firewall concepts and administration and your enterprise s firewall implementation, please consult with someone who is. Firewalls with SIP/H.323 ALG Some firewalls and routers have SIP and H.323 ALG capabilities. These enable the firewall or router to identify, inspect, and sometimes modify the payload of SIP and H.323 traffic as it traverses the firewall or router. Modifying the payload helps the SIP or H.323 application from which the message originated to traverse NAT. While many firewalls have perfectly operational SIP and H.323 ALG functions, they are generally limited in scope, and are not intended to properly handle complex, enterprise-grade needs. The following examples describe more complex implementations in which a SIP or H.323 ALG function on a router or firewall can cause problems with proper operation rather than assisting. Routed-mode gatekeeper services Multiple-session calls (for example, H.239/BFCP for content; far end camera control) Call encryption (TLS for SIP, Advanced Encryption Standard (AES) for H.323) Large capability-sets of modern video-conferencing devices, which cause SIP and H.323 communications to span multiple datagrams (H.323 H.245 terminal capability exchange, SIP Invite with SDP) Remote-firewall traversal techniques (H.460) In addition to complex SIP and H.323 implementations, SIP and H.323 standards are in constant development. These factors make it unlikely that a firewall will meet all requirements to correctly perform ALG functions for SIP and H.323 traffic. Polycom, Inc. 23

24 When you deploy the RealPresence Access Director system, you must disable all predefined services, such as SIP ALG and H.323 ALG, in your firewall. After these services are disabled, create port and protocol rules that use only source IP, destination IP, port, and transport protocol attributes (See Required Ports). When correct operation is confirmed without the predefined services, you can enable them according to your information security policy and work with your firewall vendor to resolve any performance issues. Use the guidelines that follow to configure your firewalls and ports. Outside Firewall Configuration Implement a WAN (untrusted) and LAN (trusted) configuration Configure 1:1 NAT Set interface mode to NAT Disable H.323 and SIP ALG (Application Layer Gateway) Disable any H.323 helper services on the firewall (for example, Cisco H.323 Fixup). Inside Firewall Configuration Implement a WAN (untrusted) and LAN (trusted) configuration Disable H.323 and SIP ALG Set interface mode to Route Disable the port NAT. Disable any H.323 helper services on the firewall (for example, Cisco H.323 Fixup). Port Mapping To enable firewall traversal for external clients, the RealPresence Access Director system uses ports for provisioning, presence, directory, call signaling, media, and content. The specific ports and port ranges configured in the RealPresence Access Director system must match the ports configured on your firewall. If you change any port settings within the system, you must also change them on your firewall. Incoming traffic from external clients uses static ports you define in the RealPresence Access Director system user interface. Outbound traffic from the RealPresence Access Director system uses dynamic source and destination ports from a range of port numbers (a port pool). The total number of ports available for use is based on the number of licensed calls on your system license. The RealPresence Access Director system automatically calculates dynamic port ranges based on your number of licensed calls. A port range for a specific function (for example, internal SIP signaling dynamic source ports) indicates the number of ports for that function that must be available to accommodate the number of calls on your system license. You can change the beginning port ranges (within certain parameters) if necessary. If you do so, the RealPresence Access Director system will automatically calculate the end ranges. See Required Ports for detailed port settings and refer to the Polycom RealPresence Access Director System Administrator Guide for instructions on configuring static ports and dynamic port ranges. Polycom, Inc. 24

25 Install and Configure the RealPresence Access Director System Task 1: Perform Basic Installation Perform the basic installation and network configuration as documented in the RealPresence Access Director System, Appliance Edition or Virtual Edition, Getting Started Guide. Polycom RealPresence Platform products such as the RealPresence Access Director system, Virtual Edition require the RealPresence Platform Director system to deploy the software and to manage licensing. See the Polycom RealPresence Platform Director System Administrator Guide for detailed instructions on deploying the RealPresence Access Director system, Virtual Edition. Task 2: Configure Time Settings The RealPresence Access Director system displays two different time settings: Client date and time: In the upper right corner of the Time Settings window, next to your user name, the system displays the date and time of your local machine. These values change only if you revise the date and time on your local machine. Server time: Server Time (Refresh every 10 seconds) indicates the server time. If you change the System time zone or Manually set the system time, the Server Time (Refresh every 10 seconds) field displays the correct server time. After initial installation of the RealPresence Access Director system, the default time zone is GMT (UTC). After you launch the system for the first time, you must specify the time zone of your geographic location. Polycom strongly recommends that you select the time zone of your specific geographic location, for example, America/Denver, instead of a generic GMT offset (such as GMT+7). If you choose a generic GMT offset, the time displays with the Linux/Posix convention for specifying the number of hours ahead of or behind GMT. Therefore, the generic equivalent of America/Denver (UTC-07:00) is GMT+07, not GMT-07. Consider the following information when configuring the time settings: You can configure up to three NTP server IP es from the RealPresence Platform Director system when you deploy an instance of the RealPresence Access Director system, Virtual Edition. Changing the time settings requires a system restart, which logs all users out of the system. Changing the time settings can affect the number of days available for a trial period license. If you plan to install an identity certificate provided by a certificate authority (CA), the date, time, and time zone configured in your system must be correct for the certificate to function correctly. If you plan to use your system to support calls between endpoints in your enterprise and endpoints in a separate but federated or neighbored (trusted) division or enterprise that has its own RealPresence Access Director system, both systems and the CA server should be in the same time zone. If the time difference between the two RealPresence Access Director systems and the CA server is too great, TLS connections may fail. To set the time zone: 1 Go to Admin > Time Settings > System time zone. Polycom, Inc. 25

26 2 Select the time zone of your specific geographic location, for example, America/Denver, instead of a generic GMT offset (such as GMT+7). 3 Click Update. 4 Click OK to accept your settings and restart the system. The Server Time (Refresh every 10 seconds) value refreshes based on the new settings. To configure the time settings: 1 Go to Admin > Time Settings. 2 Complete the following fields as needed for your system: Field System time zone Auto adjust for Daylight Saving Time Manually set system time NTP servers Description The time zone in which your RealPresence Access Director system is located. Note: After initial installation of the RealPresence Access Director system, the default time zone is GMT (UTC). You must select the time zone of your geographic location immediately after installation of the system. Automatically determined in accordance with the system time zone. If the system time zone you select observes Daylight Saving Time, this setting is enabled. Note: The administrator cannot change this setting. Note: Polycom strongly recommends that you do not set the time and date manually. Manually setting system time removes Network Time Protocol (NTP) server information and sets the manually entered time for the selected time zone instead of for the current system UTC offset. The IP es or FQDNs of the NTP servers. For Appliance Editions, the NTP servers may be provisioned by the Polycom RealPresence Resource Manager system or you can enter them manually. For Virtual Editions, you can configure up to three NTP servers when you create an instance of the RealPresence Access Director system from the RealPresence Platform Director system. You can later edit these server es as needed. Note: Polycom recommends that you specify at least two NTP servers for synchronizing system time. 3 Click Update. If you change the System time zone or Manually set the system time, the Server Time (Refresh every 10 seconds) value refreshes based on the new settings. Caution: Changing time settings requires a system restart Changing the time settings requires a system restart, which terminates active calls and logs all users out of the system. Polycom, Inc. 26

27 Task 3: Activate the License Licenses for the Appliance Edition and Virtual Edition of the RealPresence Access Director system are managed differently. Refer to the following sections based on the edition you deployed. Appliance Edition To activate the license for your system, you must first obtain an activation key code from Polycom Support at support.polycom.com. For instructions, see the Polycom RealPresence Access Director System Administrator Guide. After you have an activation key code, you must activate the license from the RealPresence Access Director system, Appliance Edition web user interface. To activate a license: 1 Go to Maintenance > License. 2 Enter the Activation key for the license and click Update. The system restarts. Virtual Edition The RealPresence Access Director, Virtual Edition is deployed and licensed through Polycom RealPresence Platform Director. Through the RealPresence Platform Director interface, you can activate a new instance of the RealPresence Access Director, Virtual Edition. After installation, the RealPresence Access Director system, Virtual Edition periodically obtains updated license information from the license server. Contact your Polycom sales representative to obtain a license for the RealPresence Access Director Virtual Edition. You must install a license before deploying each new instance of the product. Refer to the Polycom RealPresence Platform Director Administrator Guide for additional details on licensing a virtual instance. Task 4: Configure Network Settings You must configure the network settings for the RealPresence Access Director system based on the deployment model you implement. For more information about the deployment models, see RealPresence Access Director System Solution Deployment Models. For more information about RealPresence Access Director system network settings, see the Polycom RealPresence Access Director System Administrator Guide. To configure the initial network settings for the RealPresence Access Director system, Appliance Edition, follow the instructions in the Polycom RealPresence Access Director, Appliance Edition, Getting Started Guide. To configure the initial network settings for the RealPresence Access Director system, Appliance Edition, follow the instructions in the Polycom RealPresence Access Director, Virtual Edition, Getting Started Guide. After you configure the initial network settings for the eth0 network interface, you can configure the settings for additional network interfaces as needed. For complete instructions, see the Polycom RealPresence Access Director System Administrator Guide. Polycom, Inc. 27

28 To configure one or more network interfaces: 1 Go to Admin > Network Settings > Configure Network Setting. 2 In the Step 1 of 3: General Network Settings window, confirm or reconfigure the general network settings for eth0 and click Next. 3 In the Step 2 of 3: Advanced Network Settings window, click each of the network interfaces to configure and complete the following fields: IPv4 Address IPv4 Subnet Mask IPv4 Default Gateway 4 Click Next. 5 In the Step 3 of 3: Service Network Settings window, select the IP of the network interface to assign to each type of traffic, as described in the following table: Settings Field SIP/H.323 External signaling IP Internal signaling IP Media Relay External relay IP Internal relay IP Management IP Management IP Access Proxy External Access Proxy IP From the Available IP list, select an IP and click the right arrow to move the IP to the External Access Proxy IP list. You can select up to four interface IP es to act as external IP es for access proxy. See the chapter on Network Interface Configurations in Deploying Polycom Unified Communications in RealPresence Access Director System Environments for recommended settings based on the number of network interfaces. Internal Access Proxy IP Note: You can assign one to four network interfaces as external access proxy IP es. Only one interface can be assigned as the internal access proxy IP. DMZ If Deployed behind Outside Firewall/NAT is enabled, complete these fields: Signaling relay Media relay Note: Changing some network settings requires a new CA certificate for your system You must create a certificate signing request to apply for a new CA-provided identity certificate for the RealPresence Access Director system if one or both of the following situations is true: You change the host name of the system You revise the signaling relay and some registered or guest endpoints use an IP instead of an FQDN to establish a TLS connection to the RealPresence Access Director system. Polycom, Inc. 28

29 6 Click Done > Commit and Reboot Now to save the network settings. Configure the RealPresence Resource Manager System If you deploy your RealPresence Access Director system with a Polycom RealPresence Resource Manager system, the RealPresence Resource Manager system can provision some RealPresence Access Director system settings and dynamically manage (provision, upgrade, and manage) select remote endpoints. Provisioning of the RealPresence Access Director system is optional. If not provisioned, you must manually configure all system settings. The following table describes the settings that the RealPresence Resource Manager system can provision for the RealPresence Access Director system. Field Time Server Primary Time Server Address Secondary Time Server Address Enable IP H.323 Gatekeeper Address Enable SIP Proxy Server Registrar Server Transport Protocol Description Configures whether the RealPresence Access Director system uses a time server to synchronize system time. The IP of the primary time server that the system will use to synchronize time. The IP of the secondary time server that the system will use to synchronize time. Configures the system to enable or disable H.323 call forwarding. The IP of the internal gatekeeper to which the RealPresence Access Director system forwards gatekeeper registration or H.323 call requests from external endpoints. Configures the system to enable or disable SIP call forwarding. The IP of the internal SIP proxy server to which the RealPresence Access Director system forwards SIP calls from external endpoints. (This is the signaling IP of the RealPresence DMA system) The IP of the internal SIP registrar server to which the RealPresence Access Director system forwards SIP registration requests from external endpoints. (This is the signaling IP of the RealPresence DMA system) The protocol the system uses for SIP signaling. The following list provides a high-level summary of the tasks you must complete to configure the RealPresence Resource Manager system to provision a RealPresence Access Director system and to provision endpoints that request provisioning through a RealPresence Access Director system. For detailed instructions, see The Polycom RealPresence Resource Manager System Operations Guide for your version of the RealPresence Resource Manager system. Create a site for the RealPresence Access Director system Polycom, Inc. 29

30 Create a RealPresence Access Director system provisioning profile Create a network provisioning profile for endpoints Create a provisioning rule and associate it with all related profiles Create a user account for the RealPresence Access Director system Configure the RealPresence Access Director System Once the RealPresence Resource Manager system has been configured to integrate with and provision the RealPresence Access Director system, you can finish configuring the RealPresence Access Director system, as described in the following tasks: Task 1: Configure Access Proxy Settings Task 2: Configure Basic Access Control List Settings Task 3: Configure System Certificates Task 4: Provision the RealPresence Access Director System See the Polycom RealPresence Access Director System Administrator Guide for detailed information about each of these tasks. The following sections provide specific information as it relates to this solution. Task 1: Configure Access Proxy Settings The access proxy feature in the RealPresence Access Director system provides reverse proxy services for external devices. You can configure access proxy settings to enable firewall/nat traversal for login, registration, and call requests. When the RealPresence Access Director system receives a request from a remote user, the system accepts or denies the request, based on your basic Access Control List (ACL) settings (see Task 2: Configure Basic Access Control List Settings.) If the request is accepted, the RealPresence Access Director system sends a new request on behalf of the remote user to the appropriate application server. The RealPresence Access Director system is configured with three default reverse proxies that route communication requests based on the type of target application server: HTTPS_proxy HTTPS servers that provide management services (RealPresence Resource Manager system, Polycom RealPresence Content Sharing Suite), and web-based video conferencing services (RealPresence CloudAXIS Suite) LDAP_proxy LDAP servers that provide directory services XMPP_proxy XMPP servers that provide message, presence, or other XMPP services In addition to the default proxies, you can create an HTTP tunnel proxy in the RealPresence Access Director system. An HTTP tunnel proxy enables RealPresence CloudAXIS Suite SIP guest users to attend video conferences in an enterprise s CloudAXIS Suite Experience Portal. Due to restrictive firewall rules, if a CloudAXIS Suite client cannot establish a native SIP/RTP connection to a video conference, the RealPresence Access Director system can act as a web proxy to tunnel the SIP guest call on port 443. Once the SIP guest is connected to a meeting, the RealPresence Access Director system continues to tunnel TCP traffic, including SIP signaling, media, and Binary Floor Control Protocol (BFCP) content. Polycom, Inc. 30

31 To configure access proxy settings 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring access proxy settings. Then in the RealPresence Access Director system user interface, go to Configuration > Access Proxy Settings. 2 Configure the access proxy settings as needed for your deployment. Task 2: Configure Basic Access Control List Settings When you install a new RealPresence Access Director system, the following basic Access Control List (ACL) settings are enabled by default: Enable registration policy Allow registration from provisioned devices Enable call policy Allow call from registered devices Note that when you configure Basic ACL Settings, you must specify the login, registration, or call requests to allow. If not specifically allowed, the system will deny requests. To ensure that the default settings function as intended, be sure to configure your access proxy settings to enable provisioning of endpoints. See the Polycom RealPresence Access Director System Administrator Guide for instructions. To configure basic Access Control List settings 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring basic Access Control List settings. Then in the RealPresence Access Director system user interface, go to Configuration > Basic ACL Settings. 2 Configure the Registration Policy and Call Policy settings to allow access to your network. You must specifically configure which registration and call requests to allow; otherwise, the RealPresence Access Director system will deny requests. 3 Click Update. If you need to configure advanced rules and settings to limit access to your network, see the Define Advanced Access Control List Rules topic in the Polycom RealPresence Access Director System Administrator Guide for specific instructions. Task 3: Configure System Certificates The RealPresence Access Director system is delivered with a self-signed certificate at installation. You can replace the self-signed certificate with a signed certificate issued by a certificate authority. When you complete the certificate signing request, be sure to specify the following details: Enhanced Key Usage of the certificate must indicate both Server Authentication and Client Authentication. The RealPresence Access Director system may act as either a server or client, therefore both Server Authentication and Client Authentication are mandatory to enable a mutual TLS connection between two session border controllers. Key Usage must include Digital Signature and Key Encipherment. You should configure certificates before configuring automatic provisioning of the RealPresence Access Director system and before federating or neighboring your RealPresence Access Director system with another enterprise. For more information about certificates and creating certificate signing requests, see the Polycom RealPresence Access Director System Administrator Guide. Polycom, Inc. 31

32 Task 4: Provision the RealPresence Access Director System Configuring your RealPresence Access Director system to be provisioned by a RealPresence Resource Manager system is optional. If you choose to have your system provisioned, you must connect to the RealPresence Resource Manager system from the RealPresence Access Director user interface. Once connected, your system will be automatically provisioned with the information you configured in the RealPresence Resource Manager system. Note: Provisioning not supported in the RealPresence Access Director, Virtual Edition The RealPresence Access Director system, Virtual Edition cannot be provisioned by a RealPresence Resource Manager system. You must manually configure all access proxy settings. Note that the RealPresence Access Director system, Virtual Edition does enable endpoint provisioning by a RealPresence Resource Manager system. Specifically, automatic provisioning configures the following settings: An NTP server for system time (Appliance Edition) SIP and H.323 signaling settings Caution: Disconnect before manually changing provisioned settings After you connect to a Polycom RealPresence Resource Manager system for provisioning, you cannot update the provisioned information manually in the RealPresence Access Director system until you disconnect. To connect to the RealPresence Resource Manager system for automatic provisioning: 1 From the RealPresence Access Director user interface, go to Admin > Polycom Management System. 2 Enter the Login Name, Password, and RealPresence Resource Manager IP for the RealPresence Access Director system user account for provisioning, and click Connect. When connected, the RealPresence Resource Manager system automatically provisions the RealPresence Access Director system. Configure the Polycom RealPresence DMA System Task 1: Enable SIP Device Authentication Device authentication enhances security by requiring devices registering with or calling through the RealPresence DMA system to provide credentials that the system can authenticate. In turn, the RealPresence DMA system may need to authenticate itself to an external SIP peer or neighbored gatekeeper. Caution: Enabling SIP device authentication may cause some calls to fail If your RealPresence DMA system is peered with other SIP devices, enabling SIP device authentication may cause inbound calls to the RealPresence DMA system from those SIP peers to fail. Multiple solutions exist for resolving these issues with dial plan and network design. If necessary, please contact your Polycom field representative. Polycom, Inc. 32

33 All authentication configurations are supercluster-wide, but note that the default realm for SIP device authentication is the cluster s FQDN, enabling each cluster in a supercluster to have its own realm for challenges. Caution: If Device Authentication is enabled, disable some RealPresence Resource Manager settings If Device Authentication is enabled on the RealPresence DMA system, you must disable Use Endpoint Provisioning Credentials on the RealPresence Resource Manager system. To enable SIP authentication for ALL internal and external endpoints: 1 See the Polycom RealPresence DMA System Operations Guide for detailed information about enabling SIP device authentication. Then go to Admin > Local Cluster > Signaling Settings and in the SIP Settings section, select Enable authentication. 2 To add a device s authentication credentials to the list of device credential entries that the Call Server checks, click Add and enter the user Name, Password, and Confirm Password credentials. These are the credentials you set up in the RealPresence Resource Manager system to enable endpoint provisioning. They provide authentication of the endpoint s provisioning request. To disable SIP authentication for a specific endpoint: 1 Go to Network > Endpoints. 2 Select the endpoint for which to disable authentication. 3 Click Edit. 4 Clear Device Authentication. Task 2: Configure an External SIP Peer to Support SIP Open B2B Calls To enable calls between enterprise users and external SIP endpoints that are not registered or are not members of a federated enterprise or division, you must add the RealPresence Access Director system as an external SIP peer on the RealPresence DMA system and then specify the default SIP contact ports on the RealPresence Access Director system for each transport protocol. When the RealPresence Access Director system receives a SIP request on the default contact port from a SIP endpoint that is not registered or is not a member of a federated enterprise or division, the system routes the call to the appropriate destination. To configure an external SIP peer on the RealPresence DMA system: 1 See the Polycom RealPresence DMA System Operations Guide for detailed information about adding an external SIP peer. Then go to Network > External SIP Peers > Add. 2 In the External SIP Peers settings, enter the internal signaling IP of the RealPresence Access Director system as the Next hop. 3 In the Postliminary settings under Request URI options, select the format Use original request URI (RR). Polycom, Inc. 33

34 4 Go to Admin > Call Server > Dial Rules > Add and in the Action field, select Resolve to external SIP peer. This enables the RealPresence DMA system to send an INVITE message outbound to the RealPresence Access Director system. To configure the default local SIP contact port on the RealPresence Access Director system: The RealPresence Access Director system routes SIP open B2B calls only if you specify a valid default contact port for each type of transport. 1 See the Polycom RealPresence Access Director System Administrator Guide for details about configuring the default contact port, then go to Configuration > SIP Settings. 2 Enter the default contact port the RealPresence Access Director system uses to receive SIP traffic from endpoints that are not registered or are not members of a federated or neighbored enterprise or division. For each type of transport (TCP, UDP, TLS), you can specify any external port not in use as the default contact port. If you are deploying a RealPresence Access Director system for the first time, the default contact ports have been pre-configured as follows: TCP/UDP: 5060 TLS: 5061 Only one default contact port can be specified for each type of transport. Task 3: Configure SIP Settings for Guest Users To support SIP guest calls, you must configure the RealPresence DMA system with a dial rule prefix that corresponds to the prefix used for guests on the RealPresence Access Director system. Additionally, you must configure an external SIP port on the RealPresence Access Director system for remote (registered) users. Polycom recommends the configurations described in the following sections: SIP Settings for Guest Users on the Polycom DMA System SIP Settings for Guest Users on the RealPresence Access Director System SIP Settings for Remote Users on the RealPresence Access Director System SIP Settings for Guest Users on the Polycom DMA System Configure these RealPresence DMA settings to correspond with guest call settings on the RealPresence Access Director system. To configure the RealPresence DMA system to support SIP guest calls: 1 See the Configure Signaling section of the Polycom RealPresence DMA System Operations Guide for detailed information about this process. Then on the RealPresence DMA system, go to Admin > Local Cluster > Signaling Settings. 2 Add a guest dial rule prefix (SIP Settings > Unauthorized prefixes> Add) and enable Strip prefix. 3 Configure the required information so that it matches the prefix for guest calls added in the RealPresence Access Director system. 4 Go to Admin > Call Server > Dial Rules and add dial rules to handle the incoming unauthorized guest calls, one for each type of call resolution. Polycom, Inc. 34

35 5 Go to Admin > Call Server > Domains and add a domain to the domain list for the host specified for guest port configuration. SIP Settings for Guest Users on the RealPresence Access Director System Configure these settings to enable the RealPresence Access Director system to forward SIP guest calls to the RealPresence DMA system. To configure the RealPresence Access Director system external SIP port 5060 for guests: 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring SIP settings. Then on the RealPresence Access Director system, go to Configuration > SIP Settings. 2 Enable SIP signaling and then configure external port 5060 for SIP guest users (External Port Settings > Edit) with the required information. In this case: Port name: Defaults to Unencrypted port. Transport: UDP/TCP. Enable Dial string policy and enter a dial string prefix (Prefix of Userinfo) that does not interfere with your dial plan and will be stripped by the RealPresence DMA system. In Host, enter the host IP or FQDN to use in the dial string. If a SIP guest user calls a domain name that differs from the Host, the RealPresence Access Director system changes the domain name and adds the Prefix of Userinfo to the dial string. For example, if a SIP guest user calls 8222@polycom.com, but the host is configured as example.com and the prefix is 77, the system will change the user s dial string to @example.com. To configure the RealPresence Access Director system external SIP port 5061 for guests: 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring SIP settings. Then on the RealPresence Access Director system, go to Configuration > SIP Settings. 2 Enable SIP signaling and then configure external port 5061 for SIP guest users (External Port Settings > Edit) with the required information. In this case: Port name: Defaults to Encrypted port. Transport: TLS. Enable Dial string policy and enter a dial string prefix (Prefix of Userinfo) that does not interfere with your dial plan and will be stripped by the RealPresence DMA system. In Host, enter the host IP or FQDN to use in the dial string. If a SIP guest user calls a domain name that differs from the Host, the RealPresence Access Director system changes the domain name and adds the Prefix of Userinfo to the dial string. For example, if a SIP guest user calls 8222@polycom.com, but the host is configured as example.com and the prefix is 77, the system will change the user s dial string to @example.com. Task 4: Configure SIP Settings for Remote Users Configure these settings to enable remote users to register with the RealPresence DMA system. SIP Settings for Remote Users on the RealPresence Access Director System If you configure the external SIP ports 5060 and 5061 for guest users, you must add a non-standard external SIP port in the RealPresence Access Director system for remote users. Polycom, Inc. 35

36 To configure a RealPresence Access Director system non-standard external SIP port to support remote user calls: 1 On the RealPresence Access Director system, go to Configuration > SIP Settings. 2 Enable SIP signaling and then configure a port for SIP registered users (External Port Settings > Add) with the required information. In this case: Port number: Any non-standard port number that is not already in use. Port name: RegisteredUser (for example). Transport: Polycom suggests using TCP but UDP, UDP/TCP, or TLS may also be used. The transport protocol entered here must match the transport protocol for the RealPresence Access Director system site in the RealPresence Resource Manager system. Configure Polycom Endpoint Systems This solution supports the Polycom endpoint systems identified in Products Supported in this Solution. Task 1: Configure Polycom HDX Series Endpoints Polycom HDX series endpoints do not require any special set up for this solution. Polycom recommends automatic provisioning because it enables easy setup and access to advanced features. See the Polycom HDX system documentation available at support.polycom.com for more information about configuring the endpoints for automatic provisioning. Task 2: Configure the Polycom Group Series System See the RealPresence Group Series 300 or 500 user documentation at support.polycom.com for configuration information. Suzanne Task 3: Configure Polycom RealPresence Mobile or Desktop Endpoints For specific information on configuring RealPresence Mobile or Desktop software in this solution, refer to the online help and the Release Notes for the RealPresence Mobile or RealPresence Desktop software version you are using, available at support.polycom.com. Professional Mode Sign-In Settings You can choose to use your RealPresence Mobile or Desktop system in Professional Mode. In this mode, your system is automatically provisioned/configured by the RealPresence Resource Manager system. Polycom recommends automatic provisioning because it enables easy setup and access to advanced features. The product online help describes how to configure your system for professional mode. When setting up professional mode, you must enter the user name and password configured in the RealPresence Resource Manager system to enable endpoint provisioning. Polycom, Inc. 36

37 Configure the Polycom RealPresence Collaboration Server To ensure that a RealPresence Mobile client can send content to a conference, on the RealPresence Collaboration Server, go to Setup > System Configuration > System Flags and set the value of the NUM_OF_INITIATE_HELLO_MESSAGE_IN_CALL_ESTABLISHMENT system flag to at least 3. For information about adding system flags, see "Manually Adding and Deleting System Flags in the Polycom RMX System Administrator Guide. After the change, you must restart the RMX system. Integrate Two or More Systems with an F5 Load Balancer Two or more RealPresence Access Director systems can be deployed behind an F5 Networks load balancer to increase network capacity (concurrent users) and improve overall performance by decreasing the burden on any one RealPresence Access Director system. The F5 load balancer acts upon data in the transport layer and serves as a TCP or UDP reverse proxy to distribute (balance) incoming sign-in, registration, and call requests across multiple RealPresence Access Director systems. An F5 load balancer can help to ensure RealPresence Access Director system reliability and availability by sending requests only to systems that can respond in a timely manner. The F5 load balancer must be configured to integrate with your RealPresence Access Director systems, but no configuration is necessary on the RealPresence Access Director systems. F5 Load Balancer Configuration Requirements To ensure that an F5 load balancer operates correctly with your RealPresence Access Director systems, the F5 system configuration must meet the following requirements: The F5 system terminates traffic flow on the transport layer and works as a UDP or TCP reverse proxy. A port-based virtual server should be defined on the load balancer to support the following port assignments: Protocol Port H.323 RAS 1719 H.323 Call Signaling 1720 SIP 5060, 5061, other SIP ports HTTPS Proxy 443 LDAP Proxy 389 XMPP Proxy 5222 The F5 system uses the Round Robin algorithm for load balancing and failovers. Polycom, Inc. 37

38 The F5 system routes only incoming sign-in, registration, and call requests. The load balancer does not affect the outgoing calls from the enterprise network to the Internet. The F5 load balancer must have a heartbeat connection between all RealPresence Access Director systems to ensure that requests are routed only to an accessible system. During a failover, the load balancer routes requests to a different RealPresence Access Director system, based on the RealPresence Access Director system priority group. The routing policy of the F5 load balancer must support persistence. Persistence ensures that all requests from the same source IP during a session are distributed to the same RealPresence Access Director system. At a minimum, the F5 load balancer should support the following scenarios: Remote endpoint (EP) login to the RealPresence Resource Manager system Remote SIP EP registration to the RealPresence DMA system (TLS/TCP) Remote SIP EP incoming call Remote H.323 EP registration to the RealPresence DMA system (H.460/ non-h.460) Remote H.323 EP incoming call Guest SIP EP incoming call Guest H.323 EP incoming call Trusted H.323 B2B incoming call RealPresence CloudAXIS suite incoming HTTP tunnel call F5 Load Balancer Impacts on other RealPresence Access Director System Features Some RealPresence Access Director system functions may not operate correctly when the systems are deployed with an F5 load balancer. The following features are affected: When HTTPS, LDAP, and XMPP requests pass through the F5 system, the RealPresence Access Director system does not know the source IP of the remote device. As a result, the following settings do not function: Enable access proxy white list authentication for LDAP and XMPP access. See Admin > Security Settings in the RealPresence Access Director system web user interface. Allow registration from provisioned devices. See Configuration > Basic ACL Settings) in the web user interface. Note that other basic ACL settings may not function correctly. The RealPresence Access Director system treats a trusted B2B call as a guest call because the source IP is unknown. To configure the RealPresence Access Director system to allow a trusted H323 B2B call, you must enable the Allow any incoming LRQ option. See Configuration > H.323 Settings. Polycom, Inc. 38

39 Deploying Two RealPresence Access Director Systems in a Tunnel Configuration Two RealPresence Access Director systems can be deployed in a tunnel configuration. In this model, one system is deployed as the tunnel server in the corporate back-to-back DMZ and the other system is deployed as the tunnel client inside your enterprise network. All traffic to and from the Internet flows through the tunnel server, while all traffic to and from the enterprise network flows through the tunnel client. Communication between the tunnel server and tunnel client traverses the enterprise firewall inside the tunnel. The exception is management traffic. Each system has a management network interface so management traffic does not traverse the tunnel. Note: Two-system tunnel deployment requires two licenses Each RealPresence Access Director system requires an individual license. Although each system can be licensed for a different number of calls, the system with the fewest licensed calls determines the total number of calls that can traverse the tunnel. If you deploy two RealPresence Access Director, Appliance Edition systems, activate the license for each server before enabling the two-system tunnel. See Task 3: Activate the System Licenses for Appliance Edition Servers. In a tunnel configuration, port mapping on the firewall between the tunnel server and the tunnel client is not required. Instead, when you enable the tunnel feature on the tunnel server, the tunnel port automatically listens for communication from the tunnel client. When you enable the tunnel feature on the tunnel client, the client then registers to the tunnel server through the listening tunnel port. During the registration process, the tunnel server detects the IP of the tunnel client. Additionally, the tunnel client sends the internal signaling, media, and access proxy IP to the tunnel server. The tunnel client uses this IP to communicate with the internal RealPresence DMA system. After the tunnel client registration is complete, the tunnel server establishes a secure tunnel connection and stops listening on the tunnel port. In a two-system tunnel deployment, certain IP es are reserved for internal system use. The IP you define for each system must differ from the following IP es: Non-encrypted tunnel: Encrypted tunnel: The tunnel connection between the two systems uses a self-signed certificate that is dedicated for tunnel use. Caution: Compatibility with an HTTP tunnel proxy If you deploy two systems in a tunnel configuration, the HTTP tunnel proxy feature within access proxy is not supported. If you configure an HTTP tunnel proxy before you enable the two-system tunnel, the option to enable the two-system tunnel is not available. Polycom, Inc. 39

40 See these topics for detailed information about tunnel configuration settings: Configure the DNS Service for the Two-System Tunnel Configure Firewalls and Ports Install and Configure the RealPresence Access Director Systems Configure the RealPresence Resource Manager System Configure the Polycom RealPresence DMA System Configure Additional Polycom Components Configure the DNS Service for the Two-System Tunnel For complete DNS service configuration instructions, see Chapter 6, Deploying the RealPresence Access Director System in a Corporate DMZ Environment, Configure the DNS Service in this guide. For a tunnel deployment, the IP to use when you create the RealPresence Access Director system DNS A record for the internal DNS server depends on whether the tunnel client has one or two network interfaces. Use the following information to determine the correct IP for the DNS A record: One network interface: The IP of the tunnel client. This IP matches the Local tunnel client field in the tunnel client settings. Two network interfaces: The internal signal and media IP of the tunnel client. This IP matches the Internal signaling/media/access proxy IP of tunnel client field in the tunnel client settings. The example below assumes your tunnel client has two network interfaces. If the FQDN of the RealPresence Access Director system is rpad.example.com, and the internal signaling and media IP of the tunnel client is , create an A record as shown below: rpad.example.com IN A Configure Firewalls and Ports Follow these guidelines for configuring your firewalls. Caution If you re not familiar with firewall concepts and administration and your enterprise s firewall implementation, please consult with someone who is. For greater security, Polycom recommends that you disable SSH and web access connectivity from the Internet, and enable SSH and web access connectivity from the LAN. Outside Firewall Configuration Implement a WAN (untrusted) and LAN (trusted) configuration Configure 1:1 NAT Set interface mode to NAT Disable H.323 and SIP ALG Polycom, Inc. 40

41 Disable any H.323 helper services on the firewall (for example, Cisco H.323 Fixup). Inside Firewall Configuration Implement a WAN (untrusted) and LAN (trusted) configuration Disable H.323 and SIP ALG Disable any H.323 helper services on the firewall (for example, Cisco H.323 Fixup). Caution: Disable predefined services in your firewall When you deploy the RealPresence Access Director system, you must disable all predefined services, such as SIP ALG and H.323 ALG, in your firewall. After these services are disabled, create port and protocol rules for the functionality you need in your implementation. See Required Ports. Install and Configure the RealPresence Access Director Systems Task 1: Perform Basic Installation Perform the basic installation and network configuration of two RealPresence Access Director systems as documented in the RealPresence Access Director System, Appliance Edition, Getting Started Guide or the RealPresence Access Director System, Virtual Edition, Getting Started Guide. Task 2: Synchronize the Time and Set the Time Zones After initial installation of the RealPresence Access Director systems, configure the time settings as follows: Synchronize the time on the tunnel server and tunnel client to the same Network Time Protocol (NTP) server before encrypting the tunnel between the two systems (if applicable). Select the time zone of your geographic location on the two systems. To configure the time settings: 1 From a browser, go to the IP of the tunnel server. 2 Go to Admin > Time Settings. 3 In System time zone, select the time zone of your specific geographic location. 4 In NTP servers, enter the IP or FQDN of the NTP server with which to synchronize. Polycom recommends that you configure at least two NTP servers. If you deploy two RealPresence Access Director, Virtual Edition systems, you can configure up to three NTP servers from the RealPresence Platform Director system.. 5 Click Update and OK to accept your settings and restart the system. 6 Repeat the above steps from the user interface of the tunnel client. Polycom, Inc. 41

42 Task 3: Activate the System Licenses for Appliance Edition Servers If you deploy two RealPresence Access Director Appliance Edition systems in a tunnel configuration, you must activate the license for each system. The license with the fewest number of calls reflects the total number of licensed calls that can traverse the two-system tunnel. After activating both licenses, you can view the number of licensed calls from the Dashboard of both the tunnel server and the tunnel client. To activate the tunnel server license: 1 From a browser, go to the IP of the tunnel server. 2 Log into the RealPresence Access Director system user interface and go to Maintenance > License. 3 Enter the Activation key for the tunnel server license and click Update. The system restarts. To activate the tunnel client license: 1 From a browser, go to the IP of the tunnel client. 2 Log into the RealPresence Access Director system user interface and go to Maintenance > License. 3 Enter the Activation key for the tunnel client license and click Update. The system restarts. Task 4: Configure Network Settings for the Tunnel Server Network settings for the tunnel server can be configured for one to four network interfaces. To configure network settings for the tunnel server: 1 See the Polycom RealPresence RealPresence Access Director System Administrator Guide for detailed information about configuring network settings for the tunnel server. Then from your web browser, enter the IP of the RealPresence Access Director system that will act as the tunnel server and log into the user interface. 2 Go to Admin > Network Settings > Configure Network Setting. 3 In the Step 1 of 3: General Network Settings window, confirm the general network settings for eth0 and click Next. 4 In the Step 2 of 3: Advanced Network Settings window, click each of the network interfaces to configure and enter the following information. IPv4 Address IPv4 Subnet Mask IPv4 Default Gateway Polycom, Inc. 42

43 5 In the Step 3 of 3: Service Network Settings window, select the IP of the network interface to assign to each type of traffic and to the tunnel itself between the tunnel server and tunnel client: External Signaling IP: The IP of the network interface used for SIP and H.323 signaling traffic between the RealPresence Access Director system and external networks. External Relay IP: The IP of the network interface used for media relay between the RealPresence Access Director system and external networks. Management IP: The IP of the network interface used for management traffic, including management through the web-based user interface, SSH, DNS, NTP, remote syslog, and OCSP. If you use three or four network interfaces on the tunnel server, you can assign different network interfaces for tunnel communication traffic between the two systems and for management traffic. In this case, select the network interface used for management traffic in the Management IP field. Configure the interface for tunnel communication between the two systems in the Two-box Tunnel Settings (see Task 6: Configure Two-Box Tunnel Settings on the Tunnel Server). External Access Proxy IP: If the appropriate IP does not already display in this field, select it from the Available IP list, then click the right arrow to move the IP to the External Access Proxy IP list. 6 Select Deployed behind Outside Firewall/NAT and enter the following information: Signaling relay : The RealPresence Access Director system s public IP for signaling traffic. This IP must be mapped on the outside firewall. Media relay : The RealPresence Access Director system s public IP for media traffic. This IP must be mapped on the outside firewall. Depending on your network interface configuration, the Signaling relay and the Media relay may be the same IP. 7 Click Done > Commit and Reboot Now to save the network settings. Task 5: Configure Network Settings for the Tunnel Client Network settings for the tunnel client can be configured for one to three network interfaces. To configure network settings for the tunnel client: 1 See the Polycom RealPresence RealPresence Access Director System Administrator Guide for detailed information about configuring network settings for the tunnel client. Then from your web browser, enter the IP of the RealPresence Access Director system that will act as the tunnel client and log into the user interface. 2 Go to Admin > Network Settings > Configure Network Setting. 3 In the Step 1 of 3: General Network Settings window, confirm the general network settings for eth0 and click Next. 4 In the Step 2 of 3: Advanced Network Settings window, click each of the network interfaces to configure and enter the following information. IPv4 Address IPv4 Subnet Mask IPv4 Default Gateway Polycom, Inc. 43

44 5 In the Step 3 of 3: Service Network Settings window, select the network interface to assign as the Management IP. The network interface that handles management traffic is based on the number of network interfaces configured on the tunnel client. See Tunnel Client Network Interface Configuration. 6 Click Done > Commit and Reboot Now to save the network settings. If the tunnel client uses more than one network interface, go to Configure > Tunnel Settings to specify the IP of the network interface that the tunnel client uses for internal signaling, media, and access proxy communication with the RealPresence DMA system. See the Internal signaling/media/access proxy IP of tunnel client field in Task 7: Configure Two-Box Tunnel Settings on the Tunnel Client. Task 6: Configure Two-Box Tunnel Settings on the Tunnel Server If your license supports tunnel encryption, you must first synchronize the time on the tunnel server and the tunnel client to the same Network Time Protocol (NTP) server before encrypting the tunnel. See Task 2: Synchronize the Time and Set the Time Zones. Note: Tunnel encryption not available for some installations Due to legal requirements in some countries related to the encryption of data, the option to encrypt the two-box tunnel is not available in all installations of the RealPresence Access Director system. To configure settings on the tunnel server: 1 Go to Configuration > Two-box Tunnel Settings. 2 Use the information in the following table to configure the settings for your system. An asterisk (*) indicates a required field. Field Enable Tunnel Description Select to enable the two-system tunnel feature. Settings Server Client Encrypted tunnel Select Server to enable the system to operate as a tunnel server. When selected, communications between the tunnel server and tunnel client are encrypted. Note: This option displays only if you purchase a license that supports encryption of the tunnel between two systems. Select this option to encrypt the tunnel communications. This setting must be the same on both the tunnel server and tunnel client. Polycom, Inc. 44

45 Field Performance profile Description If you enable tunnel encryption, select a performance profile. Premium: 10 CPU cores are allocated to tunnel processes. Maximum tunnel throughput: 600M Regular: 6 CPU cores are allocated to tunnel processes. Maximum tunnel throughput: 400M Base: 2 CPU core are allocated to tunnel processes. Maximum tunnel throughput: 200M The profiles on the tunnel server and client must match. * Local tunnel server The IP and port number of the tunnel server. Default port: 1194 Note: Polycom recommends that you use the default port number 1194, but you can use any value from or Click Update. The system restarts. Task 7: Configure Two-Box Tunnel Settings on the Tunnel Client If your license supports tunnel encryption, ensure that the time settings on the tunnel server and the tunnel client have been synchronized to the same NTP server before encrypting the tunnel. See Task 2: Synchronize the Time and Set the Time Zones. To configure two-box tunnel settings on the tunnel client: 1 Go to Configuration > Two-box Tunnel Settings. 2 Use the information in the following below to configure the settings for your system. An asterisk (*) indicates a required field. Field Enable Tunnel Description The tunnel feature is enabled if you have configured the tunnel server. Settings Server Client Encrypted tunnel Select Client to enable the system to operate as the tunnel client. When selected, communications between the tunnel server and tunnel client are encrypted. Note: This option displays only if you purchase a license that supports encryption of the tunnel between two systems. Select this option to encrypt the tunnel communications. This setting must be the same on both the tunnel server and tunnel client. Polycom, Inc. 45

46 Field Performance profile Description If you enable tunnel encryption, select a performance profile. Premium: 10 CPU cores are allocated to tunnel processes. Maximum tunnel throughput: 600M Regular: 6 CPU cores are allocated to tunnel processes. Maximum tunnel throughput: 400M Base: 2 CPU core are allocated to tunnel processes. Maximum tunnel throughput: 200M The profiles on the tunnel server and client must match. * Local tunnel client The IP and port number of the tunnel client. Default port: 1194 Note: Polycom recommends that you use the default port number 1194, but you can use any value from or * Remote tunnel server The IP and port number of the tunnel server. Default port: 1194 * Internal signaling/media/access proxy IP of tunnel client The IP of the network interface that the tunnel client uses for internal signaling, internal media, and internal access proxy communication with the RealPresence DMA system. 3 Click Update. The system restarts and the two-system tunnel connection status displays on the user interface Dashboard on both the tunnel server and tunnel client. Task 8: Configure System Certificates The tunnel connection between the tunnel server and client uses a default self-signed certificate dedicated for tunnel use. This certificate cannot be changed but can be refreshed when it expires. In addition to the tunnel certificate, you must add a certificate authority s public certificate and create a certificate signing request to obtain a signed certificate for the RealPresence Access Director system. For instructions, see the Polycom RealPresence Access Director System Administrator Guide. You should configure certificates before federating your RealPresence Access Director system with other enterprises. Task 9: Configure Access Control List Rules and Rule Settings See Task 2: Configure Basic Access Control List Settings in Deploying the RealPresence Access Director System in a Corporate DMZ Environment. Configure the RealPresence Resource Manager System In a two-box tunnel configuration, the RealPresence Resource Manager system does not provision the tunnel server or tunnel client but does provision endpoints through the RealPresence Access Director system. Polycom, Inc. 46

47 To enable endpoint provisioning, configure the following information in the RealPresence Resource Manager system. For detailed instructions, see The Polycom RealPresence Resource Manager System Operations Guide. Create a site for the RealPresence Access Director system Create an RPAD server provisioning profile Create a network provisioning profile for endpoints Create a provisioning rule and associate it with all related profiles Create a user account for the RealPresence Access Director system Configure the Polycom RealPresence DMA System See Configure the Polycom RealPresence DMA System in Deploying the RealPresence Access Director System in a Corporate DMZ Environment. Configure Additional Polycom Components Refer to the following sections in Deploying the RealPresence Access Director System in a Corporate DMZ Environment to configure additional Polycom components. Configure Polycom Endpoint Systems Configure the Polycom RealPresence Collaboration Server Polycom, Inc. 47

48 Federation Between RealPresence Access Director Systems This chapter describes how to configure this solution to support calls between endpoint users in two separate but federated (trusted) divisions or enterprises. In the deployment solution described in this chapter, each division or enterprise must have a RealPresence Access Director system. In this chapter, we assume you have already performed the standard deployment as documented in Deploying the RealPresence Access Director System in a Corporate DMZ Environment. Federation in a SIP Environment To configure this solution to support calls between endpoint users in two separate but federated (trusted) divisions or enterprises in a SIP environment, each division or enterprise must have a RealPresence Access Director system that is configured: To trust the other s certificate With mutual TLS enabled With a default route to the other s Real Presence Access Director system. In addition, the federated enterprises must: Have a dial plan to route traffic to and from specific ports using specified protocols Directed to the designated port To support SIP calls from federated divisions or enterprises, perform the following deployment tasks: Task 1: Create Additional DNS SRV Records on the External DNS Server Task 2: Configure the RealPresence Access Director Systems to Support Federated SIP Calls Task 3: Configure the Polycom RealPresence DMA Systems to Support Federated SIP Calls Task 1: Create Additional DNS SRV Records on the External DNS Server Configure the DNS Service describes the basic DNS setup required for this solution. Federating sites requires additional DNS configuration as described in this section. Note: Complete DNS records for the two sites being federated Complete this process on the DNS systems for the two sites being federated. If you re not familiar with DNS administration, the creation of various kinds of DNS resource records, and your enterprise s DNS implementation, please consult with someone who is. Polycom, Inc. 48

49 Create an SRV record on the external DNS server you specified in Admin > Network Settings in the RealPresence Access Director system. This SRV record maps the SRV service to the FQDN of the RealPresence Access Director system. The SRV record is required by the Auto Find Provisioning Server feature of dynamically-managed endpoints. So if the RealPresence Access Director system has the FQDN name rpad.example.com, add an SRV record as follows. _sips._tcp.example.com. IN SRV rpad.example.com. Task 2: Configure the RealPresence Access Director Systems to Support Federated SIP Calls Complete the following configuration steps on each enterprise s or division s RealPresence Access Director system. To configure the federated sites RealPresence Access Director systems to support SIP calls: 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring SIP settings. Then go to Configuration > SIP Settings. 2 Enable SIP signaling and add a port for SIP users (External Port Settings > Add) and configure the required information. Transport protocol must be TLS (mutual TLS). Require certificate from remote endpoint must be selected. 3 Go to Configuration > Federation Settings > Add and configure the required information for the federated sites. Enter the FQDN or IP of the federated site s RealPresence Access Director system. 4 Go to Admin > Certificates and verify that the federated site s certificate is in the Trusted Store. Task 3: Configure the Polycom RealPresence DMA Systems to Support Federated SIP Calls Each enterprise s or division s RealPresence DMA system must be configured to support SIP federated calls. Use the following steps to configure both RealPresence DMA systems. To configure the federated sites RealPresence DMA systems to support federated SIP calls: 1 See the Polycom RealPresence DMA System Operations Guide for detailed information about adding an external SIP peer. Then go to Network > External SIP Peer > Add. 2 On the External SIP Peer tab, enter the following information: Next hop : the internal signaling IP of the RealPresence Access Director system. Port: the internal SIP port of the RealPresence Access Director system used for communication between the RealPresence Access Director system and the RealPresence DMA system. 3 On the Postliminary tab, set Request URI options to Use original request URI (RR). Polycom, Inc. 49

50 4 On the Authentication tab, click Add and add the federated site s authentication information. 5 Go to Admin > Call Server > Device Authentication and add the federated site s authentication credentials to the list of device credential entries that your call server should check. 6 Select the Inbound Authentication tab, click Add and add the local system s authentication information for inbound messages. 7 Select the Shared Outbound Authentication tab, click Add and add the federated site s authentication information for outbound messages. 8 Go to Admin > Local Cluster > Signaling Settings and in the SIP Settings section, select Enable SIP signaling and Enable authentication. 9 Go to Admin > Call Server > Dial Rules and add a dial rule for federated site s RealPresence Access Director system that resolves to external SIP peer, so the RealPresence DMA system can send the INVITE message out to the RealPresence Access Director system. 10 Go to Admin > Call Server > Domains and add the local RealPresence Access Director system to the domain list. Federation in an H.323 Environment To configure this solution to support calls between endpoint users in two separate but neighbored (trusted) divisions or enterprises in an H.323 environment, each division or enterprise must have a RealPresence Access Director system that is configured: With a dial plan to route E.164 aliases properly between the enterprises To be directed to the designated port To support H.323 calls from neighbored divisions or enterprises, perform the following deployment tasks: Task 1: Configure the RealPresence Access Director Systems to Support Neighbored H.323 calls Task 2: Configure the Polycom RealPresence DMA Systems to Support Federated H.323 Calls Task 1: Configure the RealPresence Access Director Systems to Support Neighbored H.323 calls Each enterprise s or division s RealPresence Access Director system must be configured to support neighbored H.323 neighbored calls. Use the following steps to configure both RealPresence Access Director systems. To configure the neighbored enterprises RealPresence Access Director systems to support H.323 calls: 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring H.323 settings. Then go to Configuration > H.323 Settings. 2 Enable H.323 signaling and configure the required information. Gatekeeper (next hop) is the RealPresence DMA system IP. CIDR IP es are based on the RealPresence DMA system configurations: If the RealPresence DMA system is set to direct mode, the CIDR IP es must include all internal endpoints and the same side s SBC IP es. Polycom, Inc. 50

51 If two RealPresence DMA systems are configured as a cluster, the CIDR IP es should include all gatekeeper es. If the RealPresence Access Director system is deployed for registration, the SBC net of the RealPresence DMA system s site setting should have the RealPresence Access Director system s IP for open B2B. 3 Go to Configuration > Federation Settings > Add and configure the required information for the federated enterprise. Enter the IP of the federated site s system. Note: Port used during call is returned by DNS SRV search Generally, you will not need to configure the remote RAS port and H.225 signaling ports. The port used during the call will be returned by the DNS SRV search. Task 2: Configure the Polycom RealPresence DMA Systems to Support Federated H.323 Calls Each enterprise s or division s RealPresence DMA system must be configured to support neighbored H.323 calls. Use the following steps to configure both RealPresence DMA systems. To configure the neighbored enterprises RealPresence DMA systems to support H.323 calls: 1 See the Polycom RealPresence DMA System Operations Guide for detailed information about adding a neighbored gatekeeper. Then go to Network > External Gatekeeper > Add and add the local RealPresence Access Director system as a neighbored gatekeeper identified by its internal signaling. 2 Go to Admin > Call Server > Dial Rules and add a resolve to external gatekeeper dial rule for the local RealPresence Access Director system that has been identified as the gatekeeper. 3 Go to Admin > Call Server > Domains and add the local RealPresence Access Director system to the domain list. Polycom, Inc. 51

52 Federation Between RealPresence Access Director and Other Systems This chapter describes how to configure this solution to support calls between endpoint users in two separate but federated (trusted) divisions or enterprises. In this deployment solution, one of the federated sites has a RealPresence Access Director. The other site has a different session border controller. Supported solutions include: Federation in an H.323 Environment with Polycom VBP-E Systems Federation in a SIP Environment with Acme Packet In this chapter, we assume you have already performed the standard deployment for the applicable systems as documented in Deploying the RealPresence Access Director System in a Corporate DMZ Environment. Federation in an H.323 Environment with Polycom VBP-E Systems In this solution deployment model, two enterprises or divisions are federated. One of the federated enterprises has a RealPresence Access Director system as its access controller along with a RealPresence DMA system as gatekeeper. The other federated enterprise has a Polycom VBP 5300E as its access controller and uses either an embedded or Polycom CMA system v6.2 gatekeeper. To support calls between these federated divisions or enterprises, perform the following deployment tasks: Task 1: Create an Additional DNS A Record on the External DNS Server Task 2: Create Additional DNS SRV Records on the External DNS Server Task 3: Configure the RealPresence Access Director Systems to Support Neighbored H.323 calls Task 4: Configure the Polycom RealPresence DMA System to Support Federated H.323 Calls Task 5 (Conditional): Configure the CMA System to Support Federated H.323 Calls Task 6 (Conditional): Configure the VBP-5300E System to Support Federated H.323 Calls Task 7 (Conditional): Configure the VBP-5300E System in Embedded Gatekeeper Mode to Support Federated H.323 Calls Task 1: Create an Additional DNS A Record on the External DNS Server Configure the DNS Service describes the basic DNS setup required for the RealPresence Access Director system in this solution. Federation requires additional DNS configuration as described here. Polycom, Inc. 52

53 Note: If necessary, get help with configuring the DNS records If you re not familiar with DNS administration, the creation of various kinds of DNS resource records, and your enterprise s DNS implementation, please consult with someone who is. Create a DNS A () record on the external DNS server to map the FQDN of the VBP 5300E system to its public (WAN side) IP. So if the VBP-E system has the FQDN name vbp_b.example2.com, add an A record as follows. vbpe_b.example2.com IN A Task 2: Create Additional DNS SRV Records on the External DNS Server Each access controller the RealPresence Access Director system and the VBP 5300E system must have an SRV record on the external DNS server to map the SRV service to its FQDN. Create an SRV record on the external DNS server to map the SRV service to the FQDN of the RealPresence Access Director system. The SRV record is required by the Auto Find Provisioning Server feature of the RealPresence Mobile system. So if the RealPresence Access Director system has the FQDN name rpad.example.com, add SRV records as follows. _h323ls._udp.example.com. IN SRV rpad.example.com. _h323cs._tcp.example.com. IN SRV rpad.example.com. Create an SRV record on the external DNS server to map the SRV service to the public IP of the Polycom VBP-5300E system. So if the VBP-E system has the FQDN name vbpe_b.example2.com, add SRV records as follows. _h323ls._udp.example2.com. IN SRV vbpe_b.example2.com _h323cs._tcp.example2.com. IN SRV vbpe_b.example2.com Task 3: Configure the RealPresence Access Director Systems to Support Neighbored H.323 calls Each enterprise s or division s RealPresence Access Director system must be configured to support neighbored H.323 calls. Note: Classless Inter-Domain Routing (CIDR) notations In the RealPresence Access Director system, Classless Inter-Domain Routing (CIDR) notations include the IP and subnet of local network H.323 devices (e.g., the RealPresence DMA system gatekeeper, endpoints, and bridges). You should add CIDR notations that specify all of the IP spaces within your enterprise LAN that include H.323 devices. Polycom, Inc. 53

54 To configure the federated enterprises RealPresence Access Director systems to support federated H.323 calls: 1 See the Polycom RealPresence Access Director System Administrator Guide for detailed information about configuring H.323 settings. Then go to Configuration > H.323 Settings. 2 Enable H.323 signaling and configure the following gatekeeper and network settings. Gatekeeper (next hop) is the RealPresence DMA system IP. Classless Inter-Domain Routing (CIDR) should only include the subnet of the internal gatekeeper. 3 Go to Configuration > Federation Settings > Add and configure the required information for the federated enterprise. Enter the FQDN or IP of the federated site s VBP-E system. Complete the other tabs and fields of the dialog as required Note: Port used during call is returned by DNS SRV search Generally, you will not need to configure the remote RAS port and H.225 signaling ports. The port used during the call will be returned by the DNS SRV search. Task 4: Configure the Polycom RealPresence DMA System to Support Federated H.323 Calls Each enterprise s or division s RealPresence DMA system must be configured to support neighbored H.323 calls. To configure the federated enterprise s RealPresence DMA systems to support federated calls: 1 See the Polycom RealPresence DMA System Operations Guide for detailed information about adding a neighbored gatekeeper. Then go to Network > External Gatekeeper > Add and add the local RealPresence Access Director system as a neighbored gatekeeper identified by its internal signaling. 2 Go to Admin > Call Server > Dial Rules and add a resolve to external gatekeeper dial rule for the local RealPresence Access Director system that has been identified as the gatekeeper. Task 5 (Conditional): Configure the CMA System to Support Federated H.323 Calls If a CMA system is the gatekeeper for the federated enterprise using the VBP-E access controller, perform this task. Otherwise, skip to Task 7 (Conditional): Configure the VBP-5300E System in Embedded Gatekeeper Mode to Support Federated H.323 Calls. To configure the federated enterprises CMA systems to support federated H.323 calls: 1 See the Polycom CMA System Operations Guide for detailed information about adding a neighbored gatekeeper. Then go to Admin > Gatekeeper Settings > Neighboring Gatekeepers and add the RealPresence Access Director system as neighboring gatekeeper. 2 Go to Admin > Server Settings > Network and enter the VBP-E s LAN interface as the IPv4 Default Gateway. Polycom, Inc. 54

55 3 Go to Admin > Dial Plan and Sites > Dial Rules and add a Prefix dial rule. Assign it a Routing Action of Route to a trusted neighbor. 4 Go to Trusted Neighbors and select the RealPresence Access Director system as a trusted neighbor. Task 6 (Conditional): Configure the VBP-5300E System to Support Federated H.323 Calls If a CMA system is the gatekeeper for the federated enterprise using the VBP-E access controller, perform this task. Otherwise, skip to Task 7 (Conditional): Configure the VBP-5300E System in Embedded Gatekeeper Mode to Support Federated H.323 Calls. To configure the federated enterprise s VBP-5300E systems to support federated calls when the CMA system is the gatekeeper: 1 See the Polycom VBP System Configuration Guide for detailed information about specifying H.323 settings. Then go to Configuration Menu> VoIP ALG > H Select Gatekeeper mode > LAN/Subscriber-side gatekeeper mode and enter the CMA system s IP as the LAN/Subscriber-side GK. Task 7 (Conditional): Configure the VBP-5300E System in Embedded Gatekeeper Mode to Support Federated H.323 Calls If the VBP-E is both the access controller and gatekeeper for the federated enterprise or division, perform this task. To configure the federated enterprises VBP-5300E systems to support federated calls when the CMA system is the gatekeeper: 1 See the Polycom VBP System Configuration Guide for detailed information about specifying H.323 settings. Then go to Configuration Menu> VoIP ALG > H Select Gatekeeper mode > LAN/Subscriber-side gatekeeper mode and enter the CMA system s IP as the LAN/Subscriber-side GK. Federation in a SIP Environment with Acme Packet Refer to the Acme Packet Net-Net Enterprise Session Director (ESD) documentation to support calls from federated divisions or enterprises with an Acme Packet Net-Net Enterprise Session Director system in their environment. Polycom, Inc. 55

56 Verifying Deployment Verifying Access Proxy Verifying access proxy confirms the functionality and connectivity between the RealPresence Access Director system and the RealPresence Mobile system, and between the RealPresence Access Director system and the RealPresence Resource Manager system To verify access proxy: 1 On the RealPresence Mobile device, configure a WiFi network. For example, if the RealPresence Access Director public IP is , make sure that the RealPresence Mobile system can access this. 2 On the RealPresence Mobile device, configure this sign-in setting. Provision Server: FQDN or public IP of the RealPresence Access Director system. User Name: User account login managed by the RealPresence Resource Manager system. Password: Correct password associated with User Name. 3 Click Sign in, and verify that sign-in was successful. 4 On the RealPresence Resource Manager system, go to ENDPOINT > Monitor view to check the status of the user. Verifying Call Success To verify registration and call success with the RealPresence DMA system: 1 Have a user sign into the RealPresence DMA system and verify that the user registered to the DMA system successfully. 2 Place a call, and verify that the call was established successfully. 3 Place a long call, and verify that the call remained connected. 4 Have the user sign out, and verify that the user was unregistered from the RealPresence DMA system successfully. Verifying Certificates Verifying certificates confirms that the administrator installed the correct certificates on the RealPresence Resource Manager, RealPresence Access Director, and RealPresence Mobile systems. Polycom, Inc. 56

57 To verify certificates: 1 In the access proxy configuration, select these settings: Require client certificate from the remote endpoint Verify certificate from internal server 2 Have a user sign on to the RealPresence Mobile device, and verify that the user signed on successfully. 3 In SIP settings, select TLS transport, and verify that the user can register and place a call successfully. Polycom, Inc. 57

58 Required Ports This section describes the specific ports or dynamic port ranges to configure on your Polycom RealPresence Access Director system and correspondingly on your firewall. The port information is organized based on the different functions, or services, that the RealPresence Access Director system supports. The dynamic source and destination port ranges listed here specify the allowable port ranges for communication between the RealPresence Access Director system and other systems and devices inside or outside of your enterprise network.the actual port ranges for your system depend on the number of calls on your license. A port range for a specific function (for example, LAN-side SIP signaling) indicates the number of ports for that function that must be available to accommodate the number of calls on your system license. You can change the beginning port ranges (within certain parameters) if necessary. If you do so, the RealPresence Access Director system automatically calculates the end ranges based on the number of calls on your license. For instructions, see Configuring Port Ranges in the Polycom RealPresence Access Director System Administrator Guide. Caution: Ports configured in the RealPresence Access Director system must match your firewall ports The specific ports and port ranges configured in the RealPresence Access Director system must match the ports configured on your firewall. If you change any port settings within the system, you must also change them on your firewall. The following sections define the required ports to configure for the different traffic types, services, and functions supported by the RealPresence Access Director system: Management Access SIP Signaling H.323 Signaling Access Proxy Media Two-System Tunnel Communication Comparison of Two-box Tunnel Deployment and Standard Deployment Ports Management Access The RealPresence Access Director system provides a web-based user interface to access, configure, and manage the system. Polycom suggests that you enable one interface as the management interface, segregated from WAN-accessible traffic. For greater security, Polycom recommends that you enable SSH Polycom, Inc. 58

59 and web access to the RealPresence Access Director system management interface only from authorized network segments. We also recommend that you disable SSH and web access from the WAN by creating explicit deny rules for these traffic types. If you require the ability to manage the RealPresence Access Director system from the WAN, see the table in Management Access Ports for specific requirements. To support certain functions in the RealPresence Access Director system, connectivity is required between the management interface and the following external systems (servers): Network Time Protocol (NTP) Syslog DNS Microsoft Active Directory SNMP Online Certificate Status Protocol (OCSP) Management Access Ports The following table lists the required ports and transport protocols to access the system s web-based user interface and to establish connections between the RealPresence Access Director system and external services. The table also lists access information to manage the RealPresence Access Director system from the WAN, if desired. Management Access Ports SRC IP SRC Port Protocol DST IP DST Port Description RPAD system management IP TCP IP of the RealPresence Platform Director system 3333 (RealPresence Platform Director system, version 1.7.0) 9333 (RealPresence Platform Director system, version 1.7.1) Connection from the RPAD system to the RealPresence Platform Director system for RPAD system license communication RealPresence Platform Director system IP >1023 TCP RPAD system management IP 8443 Connection from the Polycom RealPresence Platform Director system to the RPAD system for Polycom API communication Polycom, Inc. 59

60 Management Access Ports SRC IP SRC Port Protocol DST IP DST Port Description RPAD system management IP IP of the host sending an SNMP request to the RPAD system RPAD system management IP RPAD system management IP RPAD system management IP RPAD system management IP UDP or TCP 1 IP of SNMP server >1023 UDP or TCP 1 RPAD system management IP 123 UDP IP of external NTP server, if in use TCP IP of the OCSP responder, if in use UDP IP of the DNS server TCP IP of the LAN-based Microsoft Active Directory server, if in use Connection from the RPAD system to the SNMP server (for sending Trap messages) Connection from the LAN SNMP server to the RPAD system (for monitoring) 123 Connection from the RPAD system to the public NTP server 8080, 80 Connection from the RPAD system to the public OCSP responder 53 Connection from the RPAD system to the DNS server 389 StartTLS encrypted or unencrypted (TCP) connection from the RPAD system to the LAN-based Microsoft Active Directory server Note: This connection is optional. Polycom, Inc. 60

61 Management Access Ports SRC IP SRC Port Protocol DST IP DST Port Description RPAD system management IP RPAD system management IP IP of the WAN-based PC using a browser to access the RPAD system web (management) user interface IP of the host managing the RPAD system via SSH TLS IP of the LAN-based Microsoft Active Directory server, if in use UDP or TCP 2 IP of the syslog server, if in use Any TCP RPAD system public management IP Any TCP RPAD system public management IP 636 Encrypted connection from the RPAD system to the LAN-based Microsoft Active Directory server Note: This connection is optional. 514, Connection from the RPAD system to the syslog server Note: This connection is optional HTTPS connection from a WAN-based PC to the RPAD system s web user interface used to manage the system Note: This connection is optional. 22 Access to the command line interface (CLI) of the RPAD system via SSH Note: This connection is optional. 1 The SNMP protocol and DST port depend on the SNMP settings you configure in the RealPresence Access Director system user interface. See the Polycom RealPresence Access Director System Administrator Guide for details. 2 The protocol for syslog service depends on the remote syslog settings you configure in the RealPresence Access Director system user interface. See the Polycom RealPresence Access Director System Administrator Guide for details. Polycom, Inc. 61

62 SIP Signaling The RealPresence Access Director system serves as a SIP back-to-back user agent (B2BUA) and operates between endpoints that use the SIP protocol. When a SIP video call takes place, the RealPresence Access Director system divides the communication channel into two call legs and mediates all SIP signaling between the endpoints, from call establishment to termination. SIP signaling can be used for remote, guest, B2B, and open-sip calls, and to initiate content streaming with a Polycom RealPresence Content Sharing Suite system. Caution: Disable services that intercept and alter SIP messages If your firewall has a SIP function that enables it to intercept and alter SIP messaging (for example, SIP ALG), you must disable the service. If not disabled, the service may cause call failures due to rewriting of port or IP information. SIP WAN Ports The following table lists the required ports and protocols for bidirectional SIP signaling between the WAN and the RealPresence Access Director system. SIP Signaling Ports for the WAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of external SIP client IP of external SIP client IP of external SIP client RPAD external signaling IP >1023 TCP RPAD system public signaling IP >1023 UDP RPAD system public signaling IP >1023 TCP RPAD system public signaling IP TCP Public signaling IP of the other SIP system SIP (TCP 5060) connection from the WAN to the RPAD system 5060 SIP connection from the WAN to the RPAD system SIP TLS (TCP 5061) connection from the WAN to the RPAD system > Outbound SIP call from the RPAD system to another system Polycom, Inc. 62

63 SIP Signaling Ports for the WAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD external signaling IP UDP IP of remote user SIP client >1023 Outbound SIP call from the RPAD system to the remote user s SIP client is the default SIP external listening port on the RealPresence Access Director system. If you change this external port or add other SIP external listening ports on the RealPresence Access Director system, the ports must also be changed or added on the firewall is the encrypted (TLS) SIP external listening port on the RealPresence Access Director system. 3 Outbound calls normally resolve to TCP or UDP 5060 or TCP 5061 but DNS SRV queries may indicate any TCP or UDP port >1023. SIP LAN Ports The following table lists the required ports and protocols for bidirectional SIP signaling between the LAN and the RealPresence Access Director system. SIP Signaling Ports for the LAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD internal signaling IP RPAD internal signaling IP IP of the LAN-based SIP registrar (DMA system) TCP IP of the LAN-based SIP registrar (DMA system) UDP IP of the LAN-based SIP registrar (DMA system) UDP RPAD system internal signaling IP SIP (TCP 5060) and SIP TLS (TCP 5061) connection from the RPAD system to the LAN-based SIP registrar (DMA system) Connection from the RPAD system to the LAN-based SIP registrar (DMA system) Connection from the LAN-based SIP registrar (DMA system) to the RPAD system Polycom, Inc. 63

64 SIP Signaling Ports for the LAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of the LAN-based SIP registrar (DMA system) TCP RPAD system internal signaling IP SIP (TCP 5070) and SIP TLS (TCP 5071) connection from the LAN-based SIP registrar (DMA system) to the RPAD system and 5061 (encrypted TLS) are the default SIP listening ports on a RealPresence DMA system, so the RealPresence Access Director system ports must be the same as those on the RealPresence DMA system and 5071 (encrypted TLS) are the default SIP internal listening ports on the RealPresence Access Director system. If you change these internal ports on the RealPresence Access Director system, they must be changed accordingly on your firewall. H.323 Signaling H.323 signaling enables registration, calling, and neighboring functions for endpoints that use the H.323 protocol. H.323 signaling can be used for remote, guest, and federated or neighbored B2B calls. Caution: Disable services that intercept and alter H.323 messages If your firewall has an H.323 function that enables it to intercept and alter H.323 messaging, for example, H.323 ALG, you must disable the service. If not disabled, the service may cause call failures due to rewriting of port or IP information. H.323 and WAN Ports The following table lists the required ports and protocols for H.323 signaling between the WAN and the RealPresence Access Director system. H.323 Signaling Ports for the WAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of external H.323 device Public signaling IP of the other enterprise system >1023 UDP RPAD system public signaling IP 1 >1023 UDP RPAD system public signaling IP H.225 registration request from a remote endpoint to the RPAD system 1719 Inbound H.225 Location ReQuest (LRQ) to the RPAD system (suggested) Polycom, Inc. 64

65 H.323 Signaling Ports for the WAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of external H.323 device IP of external H.323 device RPAD external signaling IP RPAD external signaling IP RPAD external signaling IP >1023 TCP RPAD system public signaling IP >1023 TCP RPAD system public signaling IP TCP IP of external H.323 device TCP IP of external H.323 device 1719 UDP Public signaling IP of the other enterprise system H.225 connection from the WAN to the RPAD system H.245 connection from the WAN to the RPAD system 1720 H.225 connection from the RPAD system to the WAN >1023 H.245 connection from the RPAD system to the WAN 1719 H.225 gatekeeper neighboring connection from the RPAD system to the other enterprise system, if needed 1 The RealPresence Access Director system public signaling IP refers to the public IP for signaling mapped on the firewall located between the WAN and the RealPresence Access Director system is the default listening port on the RealPresence Access Director system used by remote H.323 endpoints to request registration is the default H.225 TCP port in the RealPresence Access Director system. If you change the port in the RealPresence Access Director system, you must also change it accordingly on the firewall. Polycom, Inc. 65

66 H.323 and LAN Ports The following table lists the required ports and protocols for H.323 signaling between the LAN and the RealPresence Access Director system. H.323 Signaling Ports for the LAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD internal signaling IP RPAD internal signaling IP RPAD internal signaling IP RPAD internal signaling IP UDP IP of LAN-based H.323 gatekeeper (DMA system) 1719 UDP IP of LAN-based H.323 gatekeeper (DMA system) TCP IP of LAN-based H.323 gatekeeper (DMA system) TCP IP of LAN-based H.323 device H.225 RAS connection for H.323 remote user registrations from the RPAD system to the LAN-based H.323 gatekeeper (DMA system) 1719 H.225 gatekeeper neighboring connection from the RPAD system to the LAN-based H.323 gatekeeper (DMA system), if needed H.225 connection from the RPAD system to the LAN-based H.323 gatekeeper (DMA system) 1720 H.225 connection from the RPAD system to the LAN-based H.323 device (with the DMA system in Direct mode) Polycom, Inc. 66

67 H.323 Signaling Ports for the LAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD internal signaling IP IP of the LAN-based H.323 gatekeeper (DMA system) IP of the LAN-based H.323 device IP of the LAN-based H.323 device IP of the LAN-based H.323 gatekeeper (DMA system) TCP IP of LAN-based H.323 gatekeeper (DMA system) UDP RPAD system internal signaling IP >1023 TCP RPAD system internal signaling IP >1023 TCP RPAD system internal signaling IP TCP RPAD system internal signaling IP H.245 connection from the RPAD system to the LAN-based H.323 gatekeeper (DMA system) 1719 H.225 RAS connection from the LAN-based H.323 gatekeeper (DMA system) to the RPAD system 1720 H.225 connection from the LAN-based H.323 device to the RPAD system (with the DMA system in Direct mode) H.245 connection from the LAN-based H.323 device (with the DMA system in Direct mode) to the RPAD system 1720 H.225 connection from the LAN-based H.323 gatekeeper (DMA system in Routed mode) to the RPAD system Polycom, Inc. 67

68 H.323 Signaling Ports for the LAN and RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of the LAN-based H.323 gatekeeper (DMA system) TCP RPAD system internal signaling IP H.245 connection from the LAN-based H.323 gatekeeper (DMA system in Routed mode) to the RPAD system 1 SRC Port 1719 is the default H.225 UDP port on the local RealPresence Access Director system. If you change the port in the RealPresence Access Director system, you must also change it accordingly on the firewall. 2 DST ports 1719 and 1720 are the default H.225 ports on a RealPresence DMA system, so these ports must be the same on the RealPresence Access Director system is the H.245 port range on a RealPresence DMA system. Access Proxy The RealPresence Access Director system access proxy feature provides reverse proxy services for external users. Based on your system configuration, when access proxy receives a request from an external user, it accepts the request and sends a new request on behalf of the user to the appropriate application server. Access proxy routes communication requests based on the type of target application server: HTTPS_proxy: HTTPS servers that provide management services, such as provisioning for the RealPresence Access Director system and endpoints (Polycom RealPresence Resource Manager system, Polycom RealPresence Content Sharing Suite), and web-based video conferencing services (RealPresence CloudAXIS suite) LDAP_proxy: LDAP servers that provide directory services for remote (authorized) users XMPP_proxy: XMPP servers that provide message, presence, or other XMPP services for remote (authorized) users HTTP tunnel proxy: An HTTP tunnel proxy enables RealPresence CloudAXIS suite SIP guest users to attend video conferences in an enterprise s CloudAXIS suite Experience Portal. Due to restrictive firewall rules, if a CloudAXIS suite client cannot establish a native SIP/RTP connection to a video conference, the RealPresence Access Director system can act as a web proxy to tunnel the SIP guest call on port 443. Once the SIP guest is connected to a meeting, the RealPresence Access Director system continues to tunnel TCP traffic, including SIP signaling, media, and Binary Floor Control Protocol (BFCP) content. Polycom, Inc. 68

69 Access Proxy WAN Ports The following table lists the ports and protocols for access proxy traffic between the WAN and the RealPresence Access Director system. Access Proxy Ports for the WAN and the RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of external client IP of external client IP of external client IP of external RealPresence CloudAXIS suite browser client that signs into the CloudAXIS suite Experience Portal and/or the Services Portal 2 IP of Polycom RealPresence Content Sharing Suite user >1023 TCP Public IP of the RPAD system >1023 TCP Public IP of the RPAD system >1023 TCP Public IP of the RPAD system >1023 TCP Public IP of the RPAD system >1023 TCP Public IP of the RPAD system HTTPS connection from the WAN to the RPAD system to sign in for provisioning TLS-encrypted or unencrypted encrypted (TCP) LDAP connection from the WAN to the RPAD system XMPP connection from the WAN to the RPAD system 443 HTTPS web connection from the WAN to the RPAD system. The RPAD system can proxy to both the RealPresence CloudAXIS suite Experience Portal and Services Portal HTTPS connection from the WAN to the RPAD system. The RPAD system proxies connections from external RealPresence Content Sharing Suite users to the Content Sharing Suite server. Polycom, Inc. 69

70 Access Proxy Ports for the WAN and the RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of RealPresence CloudAXIS suite client using an HTTP tunnel proxy. IP of RealPresence Mobile client using an HTTP tunnel proxy >1023 TCP Public IP of the RPAD system >1023 TCP Public IP of the RPAD system s external access proxy IP 443 HTTP tunnel proxy connection from the WAN to the RPAD system. The RPAD system terminates the tunnel and proxies the traffic to the internal systems HTTPS tunnel proxy connection from the WAN to the RPAD system. The RPAD system terminates the tunnel and proxies the traffic to the internal systems. 1 The RealPresence Access Director system automatically redirects inbound access proxy traffic on ports 443 and 389 to the internal ports reserved on the system's loopback interface private IP. The CentOS operating system does not allow processes without root ownership to listen on ports <1024. Redirecting access proxy traffic on ports <1024 to the internal ports enables the access proxy process to function correctly. 2 The RealPresence Access Director system denies all unencrypted LDAP requests if you enable Enforce TLS for LDAP connection in the web user interface (Admin > Security Settings). 3 Access to the RealPresence CloudAXIS suite Services Portal is required only for users who create and host conferences, and who are typically members of your organization. Providing external guests direct access to the Services Portal is left to the administrator's discretion. Polycom, Inc. 70

71 Access Proxy LAN Ports The following table lists the ports and protocols for bidirectional access proxy traffic between the RealPresence Access Director system and the LAN. Access Proxy Ports for the LAN and the RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD internal access proxy IP RPAD internal access proxy IP RPAD internal access proxy IP RPAD internal access proxy IP RPAD internal access proxy IP TCP IP of the LAN-based provisioning server that provisions the RPAD system TCP IP of the LAN-based management server that provisions the endpoints TCP IP of the LAN-based LDAP server TCP IP of the LAN-based XMPP server TCP IP of the RealPresence CloudAXIS suite Services Portal and/or Experience Portal 443 HTTPS connection from the RPAD system to the LAN-based provisioning server that provisions the RPAD system Note: This connection is optional. 443 HTTPS connection from the RPAD system to the LAN-based provisioning server that provisions the endpoints 389 LDAP connection from the RPAD system to the LAN-based LDAP server 5222 XMPP connection from the RPAD system to the LAN-based XMPP server 443 HTTPS connection from the RPAD system to the RealPresence CloudAXIS suite Experience Portal and/or Services Portal 1 Polycom, Inc. 71

72 Access Proxy Ports for the LAN and the RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD internal access proxy IP TCP IP of the Polycom RealPresence Content Sharing Suite server 443 HTTPS connection from the RPAD system to the RealPresence Content Sharing Suite server. 1 Access to the RealPresence CloudAXIS suite Services Portal is required only for users who create and host conferences, and who are typically members of your organization. Providing external guests direct access to the Services Portal is left to the administrator's discretion. Media The RealPresence Access Director system enables media traffic (audio, video, and content) to traverse the firewall during video conferencing calls. Media WAN Ports The following table lists the ports and protocols for bidirectional media relay between the WAN and the RealPresence Access Director system. Media Ports for the WAN and the RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description IP of external device Public media IP of the RPAD system >1023 UDP RPAD system public media IP UDP Public media IP of the external device Inbound media (RTP) traffic from the WAN to the RPAD system >1023 Outbound media traffic from the RPAD system to the to WAN 2 1 The RealPresence Access Director system public media IP refers to the public IP for media mapped on the firewall located between the WAN and the RealPresence Access Director system. 2 Most firewalls do not require a specific policy for the outbound media port range. The port range is the same for both inbound and outbound media traffic. The port information is included here for reference. Polycom, Inc. 72

73 Media LAN Ports The following table lists the ports and protocols for bidirectional media traffic between the LAN and the RealPresence Access Director system. Media Ports for the LAN and the RealPresence Access Director System SRC IP SRC Port Protocol DST IP DST Port Description RPAD internal media IP IP of the LAN-based video conferencing device RPAD internal media IP IP of LAN-based RealPresence Collaboration Server (RMX) UDP Any LAN-based video conferencing device >1023 UDP RPAD system internal media IP TCP IP of LAN-based RealPresence Collaboration Server (RMX) >1023 TCP RPAD internal media IP > Inbound media traffic from the RPAD system to the LAN-based video device Outbound media traffic from the LAN-based video conferencing device to the RPAD system >1023 Inbound BFCP content from the RPAD system to the LAN-based RealPresence Collaboration Server (RMX) Outbound BFCP content from the LAN-based RealPresence Collaboration Server (RMX) to the RPAD system 1 By default, video devices choose a port greater than 1023 to receive media traffic from the RPAD system (far end). Most video devices allow you to limit the port range they use by specifying fixed ports. The destination port can be restricted if endpoints and bridges are using restricted inbound port ranges. Two-System Tunnel Communication If you deploy two RealPresence Access Director systems in a tunnel configuration, one system acts as the tunnel server and the other system as the tunnel client. Communication for the RealPresence Access Director system services is tunneled between the two servers. In a tunnel configuration, signaling, access proxy, and media traffic travels through a secure tunnel connection between the tunnel client and tunnel server. Port 1194 for UDP tunnel communication does not need to be open on the firewall between the tunnel server and the tunnel client. Polycom, Inc. 73

74 When you enable the tunnel feature on the tunnel server, the tunnel port is opened and listens for communication from the tunnel client. When you enable the tunnel feature on the tunnel client, the client then registers to the tunnel server through the tunnel port. During the registration process, the tunnel server detects the IP of the tunnel client. Additionally, the tunnel client sends the internal signaling and media IP to the tunnel server. The tunnel client uses this IP to communicate with the internal RealPresence DMA system. After the tunnel client registration is complete, a secure tunnel connection exists between the tunnel server and tunnel client. This connection enables continued communication between the two systems. Management traffic does not traverse the tunnel. Regardless of how you configure your management interface, you must ensure that your RealPresence Access Director system has access to all management functions described in Management Access. The following table lists the port and protocol for traffic between a RealPresence Access Director system tunnel server and tunnel client. Tunnel Server and Tunnel Client Port and Protocol SRC IP SRC Port Protocol DST IP DST Port Description RPAD tunnel client IP UDP RPAD tunnel server IP Tunnel connection between the RPAD tunnel client and the RPAD tunnel server is the default port for the RealPresence Access Director system local tunnel server and tunnel client. Comparison of Two-box Tunnel Deployment and Standard Deployment Ports The following tables describe port similarities and differences in a RealPresence Access Director system standard deployment and a two-server tunnel deployment. WAN and Tunnel Server Connections From the WAN to the Tunnel Server Management Ports The port range is the same for two-box tunnel and standard deployments (see Management Access Ports). H323 Ports The port range is the same for two-box tunnel and standard deployments (see H.323 and WAN Ports). SIP Ports The port range is the same for two-box tunnel and standard deployments (see SIP WAN Ports). From the Tunnel Server to the WAN Management Ports The port range is the same for two-box tunnel and standard deployments (see Management Access Ports). H323 Ports The port range is the same for two-box tunnel and standard deployments (see H.323 and WAN Ports). SIP Ports The port range is the same for two-box tunnel and standard deployments (see SIP WAN Ports). Polycom, Inc. 74

75 LAN and Tunnel Client Connections From the LAN to the Tunnel Client Management Ports The port range is the same for two-box tunnel and standard deployments (see Management Access Ports). Tunnel Port The default port is 1194 (see Two-System Tunnel Communication). From the Tunnel Client to the LAN Management Ports The port range is the same for two-box tunnel and standard deployments (see Management Access Ports). Tunnel Port The default port is 1194 (see Two-System Tunnel Communication). Polycom, Inc. 75

76 Network Interface Configurations This chapter provides illustrations and network interface configuration details for the different RealPresence Access Director system deployment models. Single Firewall Deployment with One Network Interface DMZ Deployment with One or More Network Interfaces Two-System Tunnel Deployment Single Firewall Deployment with One Network Interface The RealPresence Access Director system with one network interface card (NIC) is deployed at the DMZ of the single outside firewall. All traffic use one network interface and IP. Polycom, Inc. 76

77 All communication services are configured for one network interface card and IP, as shown in the following table. Number of NICs Name of Interface Assigned Traffic 1 eth0 Management External signaling Internal signaling External media Internal media External access proxy Internal access proxy DMZ Deployment with One or More Network Interfaces The RealPresence Access Director system can be deployed in the DMZ with either a standard configuration or a WAN/LAN configuration. Note: Polycom recommends the use of four network interfaces As a best practice, Polycom recommends that you configure IP es for all four network interface cards. This configuration is required in order to support media throughput greater than 256 MB. The figure below shows deployment in the enterprise DMZ, between an inside and outside firewall. Standard Configuration In a standard configuration with 1 4 configured NICs, all network interface IP es must be within the same subnet. External signaling and access proxy must be assigned to the same interface. External signaling and access proxy, and external media must have NATed IP es on the external, WAN-side firewall. All other network interfaces route traffic to and from the enterprise LAN through the inside firewall without NAT. Polycom, Inc. 77

78 The following table lists the recommended network interface settings for the different communication services in a standard configuration, based on the number of network interfaces you use. Number of NICs Name of Interface Assigned Traffic 1 Minimal implementation eth0 Management External SIP/H.323 signaling and access proxy External media Internal SIP/H.323 signaling and access proxy Internal media 2 Best practice for minimal implementation with management traffic segregated eth0 eth1 External SIP/H.323 signaling and access proxy External media Internal SIP/H.323 signaling and access proxy Internal media Management 3 Not recommended eth0 eth1 eth2 External SIP/H.323 signaling and access proxy Internal SIP/H.323 signaling and access proxy External media Internal media Management 4 Best practice required to support media throughput greater than 256 MB eth0 eth1 eth2 eth3 External SIP/H.323 signaling and access proxy Internal SIP/H.323 signaling and access proxy External media Internal media Management LAN-WAN Configuration In a LAN-WAN configuration with 2 4 configured NICs, all network interface IP es must be assigned to a WAN-side subnet or a LAN-side subnet. All network interfaces assigned to external, WAN-side services must have IP es in the WAN-side subnet. All network interfaces assigned to route traffic to and from the enterprise LAN must have IP es in the LAN-side subnet. In the LAN-WAN configuration, external signaling and access proxy must be assigned to the WAN-side subnet. Internal signaling and access proxy must be assigned to the LAN-side subnet. The following table lists the recommended network interface settings for the different communication services in a LAN-WAN configuration, based on the number of network interfaces you use. Polycom, Inc. 78

79 Number of NICs Name of Interface Assigned Traffic 2 Minimal implementation eth0 eth1 Management Internal SIP/H.323 signaling and access proxy Internal media External SIP/H.323 signaling and access proxy External media 3 Best practice for implementation with Management traffic segregated eth0 eth1 eth2 External SIP/H.323 signaling and access proxy External media Internal SIP/H.323 signaling and access proxy Internal media Management 4 Best practice required to support media throughput greater than 256 MB eth0 eth1 eth2 eth3 External SIP/H.323 signaling and access proxy External media Internal media Internal SIP/H.323 signaling and access proxy Management Two-System Tunnel Deployment In a two-system tunnel deployment, two RealPresence Access Director systems can be deployed to tunnel traffic to and from the inside network. In this model, one system with one to four network interfaces is deployed in the corporate back-to-back DMZ and acts as the tunnel server. The other system with one to three network interfaces is deployed behind the inside firewall and acts as the tunnel client. The following figure illustrates a two-system tunnel deployment. Polycom, Inc. 79