Breaking News RealPresence Access Director 2.1 /...
Transcript of Breaking News RealPresence Access Director 2.1 /...
December 2013 | Level 2
Breaking News
RealPresence Access Director 2.1 / 3.0
Software Release Dates: March 2013 / August 2013
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 2 of 32
Disclaimer © 2013 Polycom, Inc. All rights reserved.
Polycom, Inc. 6001 America Center Dr San Jose, CA 95002 USA
No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Polycom, Inc. Under the law, reproducing includes translating into another language or format.
As between the parties, Polycom, Inc., retains title to and ownership of all proprietary rights with respect to the software contained within its products. The software is protected by United States copyright laws and international treaty provision. Therefore, you must treat the software like any other copyrighted material (e.g., a book or sound recording).
Every effort has been made to ensure that the information in this manual is accurate. Polycom, Inc., is not responsible for printing or clerical errors. Information in this document is subject to change without notice.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 3 of 32
Contents
Module Overview ........................................................................................................................4
Polycom RealPresence Access Director Version 2.1 .............................................................5
H.323 Guest Policy .................................................................................................................. 5
Static Routing ......................................................................................................................... 10
SVC Federation Calls ............................................................................................................. 10
Polycom RealPresence Access Director Version 3.0 ...........................................................11
Split Signaling Interface ......................................................................................................... 11
Tunnel Deployment ................................................................................................................ 13
H.460 and DMA Gatekeeper Registration Support for H.323 Remote Users ....................... 16
Lab Exercise: H.323 Registration / H.460 Support for External Endpoints .......................... 17
Default Destination Alias for H.323 Guest Users .................................................................. 20
Access Control List (ACL) Support ........................................................................................ 21
Lab Exercise: Access Control Lists ....................................................................................... 23
Updating SIP External Port Settings ...................................................................................... 25
Call History and Registration History ..................................................................................... 26
Lab Exercise: Call History ...................................................................................................... 30
TCP Reverse Proxy Enhancement (Support for MEA) ......................................................... 32
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 4 of 32
Module Overview
This module provides an overview of the new features included in the Polycom RealPresence Access Director 2.1 and 3.0 software releases.
Intended Audience
This course is intended for students that are familiar with existing Polycom solutions and now want to learn about the Access Director Version 3.0 release.
Prerequisites
Students should have attended RealPresence Implementation, Configuration and Troubleshooting (Level 2) training or have equivalent experience with Polycom video and infrastructure products. These topics cover some advanced features and it is recommended that students have also attended RealPresence Platform: Security and Firewall Traversal Using RealPresence Access Director RPSAT301 prior to reading these.
Product Release Date
Polycom RealPresence Access Director version 2.1 was made generally available in March of 2013 and RPAD version 3.0 was generally available in August of 2013.
Lab Exercise / Demonstration Scenarios
The following lab exercises are provided with this training. Detailed instructions are provided for students that have access to the necessary Polycom equipment and recorded demonstrations can be viewed as well.
H.323 Registration / H.460 Support for External Endpoints
Access Control Lists
Call History
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 5 of 32
Polycom RealPresence Access Director Version 2.1
Version 2.1 of the RealPresence Access Director was primarily a maintenance release that included a few new features that warrant coverage here:
H.323 Guest Policy
Static Routing
SVC Federation Calls
H.323 Guest Policy
Version 2.0 of the RPAD system included the ability for it to identify unauthorized SIP calls with a configurable prefix. The DMA could then be used to create an unauthorized dial rule to specifically limit these calls to route only to VMRs, VEQs or SIP Peers. An unauthorized SIP call is defined as a SIP call originating from outside of the corporate firewall from an endpoint that is not registered with the DMA system or part of a federated division or enterprise. These calls come to the DMA via the RPAD or other SIP Session Border Controllers (SBCs). For security purposes these unauthorized and untrusted calls can be routed to:
DMA Virtual Meeting Rooms (VMRs)
DMA Virtual Entry Queues (VEQs)
DMA SIP peers
The RPAD identifies these unauthorized SIP calls by inserting a configurable prefix in the Request-URI of the first INVITE message for the call. DMA SIP signaling settings can be configured to create a prefix service to recognize this RPAD prefix as an unauthorized call. This routing of these unauthorized calls is done by creating one or more unauthorized dial rules on the DMA. Other SBCs may route untrusted calls to a specific port.
Version 3.0 of the RPAD adds a new H.323 Guest Policy, which provides similar functionality for H.323 “guest” calls. An H.323 guest call is any incoming call from an unregistered endpoint.
When the H.323 Guest Policy is enabled, the RPAD system adds a prefix to the dial string when forwarding H.323 guest calls from an external network to the DMA system. The DMA system, in turn, can be configured with a dial rule to handle these external H.323 calls.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 6 of 32
The H.323 Guest Policy is enabled at the bottom of the H.323 configuration page, as shown below. In the example the prefix has been configured as 77.
To restrict these guest calls so they can only reach existing Conference Rooms, the existing DMA dial rule should be modified. The existing dial rule can be located and edited from the Admin > Call Server > Dial Rules page, as shown below. Notice the dial rule at the top of
the page for unauthorized calls. This dial rule was created earlier to specifically handle the SIP calls being identified by the RPAD.
The dial rule to be modified for H.323 guest calls is highlighted at the bottom of the page and is listed as #2 – Dial by conference room ID.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 7 of 32
This dial rule must be edited to include a Preliminary script to remove the H.323 guest prefix that was added by the RPAD, which in this example is 77. The appropriate preliminary script to enter here is as follows: DIAL_STRING = DIAL_STRING.replace(/^77/,””); as shown in
the screen shot below.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 8 of 32
Successful H.323 Guest Call into DMA Conference Room (VMR)
An example of a successful H.323 guest call into a DMA conference room, or VMR, is shown below, with the following steps:
1. The unregistered guest H.323 endpoint uses Annex O dialing to attempt to reach VMR
151102 at Medeatalk Corp and dials [email protected]
2. The RPAD inserts a prefix of 77 when sending the ARQ to the DMA Gatekeeper
3. The DMA processes the Conference Room dial rule and strips the 77 prefix
4. The caller is routed to VMR 151102 on the RMX 4000
RPAD
LAN
HDX
RMX RPRM
Guest
User
DMZ
Conf Rooms
151101
151102
151103
Dials
1
Internet
ARQ = 77151102
2
3
4
Processes dial rule,
resolves to VMR 151102
Caller routed to VMR
151102 on RMX
DMA
Medeatalk Corporation
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 9 of 32
Blocked H.323 Guest Call to Internal Endpoint
An example of a blocked H.323 guest call directly to an internal corporate endpoint is shown below, with the following steps:
1. The unregistered H.323 guest endpoint is attempting to place a direct call to the HDX
inside Medeatalk with the e.164 alias of 55587 by dialing [email protected]
2. The RPAD inserts a prefix of 77 when sending the ARQ to the DMA Gatekeeper
3. The DMA processes the Conference Room dial rule and strips the 77 prefix and the
dial string of 55587 does not resolve to an existing DMA conference room (VMR)
4. The call is rejected with an ARJ RAS message from the DMA gatekeeper
RPAD
LAN
HDX
RMX RPRM
Guest
User
DMZ
Conf Rooms
151101
151102
151103
Dials
1
Internet
ARQ = 7755587
2
3
Dial rules processed, call
does NOT resolve to VMR
DMA
e.164=55587
4
Call is REJECTED
Medeatalk Corporation
RealPresence Access Director Version 3 includes further enhancements to the handling of H.323 guest calls. These will be covered in a later section.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 10 of 32
Static Routing
RPAD supports the use of static routes to route data from one subnet to a different subnet. Based on network routing policies, static routes can be configured for different destinations. The RealPresence Access Director system dynamically updates the routing table based on the static routes that have been configured.
Static routes are configured on the Static route setting tab of the Admin > Network settings page, as shown in the screen shot below:
SVC Federation Calls
The RealPresence Access Director system now supports both AVC and SVC endpoints for calls between federated enterprises. When connected using SVC, conference participants will experience lower latency and improved call quality.
Federation is a function of the RPAD system that enables enterprise users from one division or enterprise to call enterprise users from other federated, or neighbored, divisions or enterprises. Configuring federation in the RPAD is covered in great detail in the Polycom RealPresence Access Director System Solution Deployment Guide, which can be downloaded from the Polycom Support site.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 11 of 32
Polycom RealPresence Access Director Version 3.0
This release of the RealPresence Access Director offers a wide range of features and changes, including:
Split interfaces for SIP and H.323 signaling traffic
Tunnel deployment of two RPAD systems
H.460 support for H.323 remote users
Port pool enhancement
Default destination alias for H.323 Guest Users
Access Control List (ACL) support
Call history and registration history
TCP reverse proxy
Reverse proxy enhancement (support for MEA)
Split Signaling Interface
The RealPresence Access Director system supports the use of separate network interfaces for signaling (SIP and H.323) and media services. Along with the capability to split signaling and media communications, separate network interfaces and IP addresses can be assigned for external and internal traffic. Separating external and internal signaling and media services both strengthens enterprise network security and increases the available bandwidth for calls.
Version 3.0 of the RPAD supports split interfaces for both signaling and media, while version 2.x supported just split media port. In this release, SIP and H.323 listening is supported on both external and internal signaling interfaces. Split signaling requires multiple interfaces in the RPAD server to support the internal and external traffic types.
If more than one network interface is used on the RPAD system, each network interface must be individually configured for the type of service it communicates. The management, signaling, external media and internal media can be configured on one or three network adapters or separated individually by using all four of the available network interfaces.
A two-interface deployment is shown below. Notice that the signaling and media are on the same interface on both the internal facing and external facing network interfaces.
Internet
RPAD
DMZ
eth0eth1
ManagementSIP / H.323 SignalingMedia
LAN
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 12 of 32
In a three-interface deployment the signaling and media are also on the same interface, as shown below but in the example the third interface has been used to separate management traffic.
Internet
RPAD
DMZ
eth0eth1
ManagementSIP / H.323 SignalingMedia
LAN
eth2
A four-interface deployment provides complete separation of signaling and media.
Internet
RPAD
DMZ
eth0eth1
ManagementSIP / H.323 SignalingMedia
LAN
eth2 eth3
The table below summarizes the options depending on the number of interfaces.
Number of Network Interfaces
eht0
eth1
eth2
eth3
1 Management External Signaling Internal Signaling External Media Internal Media
2 Management Internal Signaling Internal Media
External Signaling External Media
3 Management External Signaling External Media
Internal Signaling Internal Media
4 Management Internal Signaling
External Signaling External Media Internal Media
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 13 of 32
Tunnel Deployment
Two RealPresence Access Director Systems can be deployed to tunnel traffic to and from the inside enterprise network. One RPAD system is deployed in the enterprise back-to-back DMZ between the inside and outside firewall and acts as the tunnel server. The other system is deployed behind the inside firewall and serves as a tunnel client.
With the new tunnel feature deployed, the tunnel server can forward all traffic through one open port on the inside firewall, thereby significantly reducing the number of firewall ports that must be opened.
Before considering tunnel-based deployments the image and information below provides information on a typical single RPAD deployment.
RPAD
DMA 7000Internet Corp LANCorp LAN
RPRM
RPD
DMZ
x.x.x.x
z.z.z.z
Port 443
Port 1719
Port 1720
Port 5060
Port 5061
Port 443
Port 1719
Port 1720
Port 5060
Port 5061
Some important items to note include:
Because the single RPAD is located in the DMZ, ports must be open on both the inside
and outside firewalls to support provisioning from the RealPresence Resource
Manager (port 443), H.323 traffic (ports 1719/1720) and SIP traffic (ports 5060/5061)
All outside endpoints that are provisioned or registered via the DMZ RPAD system will
appear with the IP address of the RPAD (z.z.z.z) to the RealPresence Platform
infrastructure products
A firewall traversal network site should be created that includes just the DMZ RPAD
(z.z.z.z/32) to ensure outside endpoints are properly provisioned
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 14 of 32
The new two-RPAD tunnel deployment is shown in the diagram below:
RPAD
Tunnel – Port 1194
DMA 7000
Tunnel Server
Internet
Corp LANCorp LAN
RPRM
RPAD
RPD
Tunnel Client
DMZ
z.z.z.z y.y.y.y
Port 443
Port 1719
Port 1720
Port 5060
Port 5061
Some important items to note include:
The external-facing RPAD in the DMZ will serve the role of Tunnel Server
The RPAD located on the corporate network will be the Tunnel Client
The default and recommended port for the RPAD tunnel implementation is port 1194,
but this can be changed to any value between 1190-1199 or 65380-65389 This is the
only port that must be open in the internal firewall for RPAD communication
The Tunnel Server initiates the tunnel connection to the Tunnel Client
Each RPAD system requires an individual license and if the systems are licensed for a
different number of calls, the number of calls traversing the tunnel will be limited to the
fewest number of calls licensed
RPAD configuration is done on the Tunnel Server RPAD and the Tunnel Client RPAD
simply performs the tunnel function
All outside endpoints that are provisioned or registered via the DMZ RPAD system will
appear with the IP address of the Tunnel Client RPAD (y.y.y.y) to the RealPresence
Platform infrastructure products
A firewall traversal network site should be created that includes just the Tunnel Client
RPAD (y.y.y.y/32) to ensure outside endpoints are properly provisioned
If the tunnel is configured with encryption, it is required that both RPAD servers use a
time server configuration
If the tunnel client has two configured network interfaces, be sure to create a DNS A
record so the IP address matches the internal signal and media IP address
In a tunnel configuration certain IP addresses are reserved for internal use. The IP
address you define for each system must not fall within the IP address ranges listed
below:
o Non-encrypted tunnel: 192.168.99.21
o Encrypted tunnel: 192.168.99.1 – 192.168.99.21
Note: in a tunnel deployment the RealPresence Resource Manager will not provision the RPAD systems (the tunnel server or the tunnel client). The RPRM will continue, however, to provision internal endpoints directly and external endpoints through the RPAD system.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 15 of 32
Configuring the Tunnel Deployment
Configuring the Tunnel Client is done from the RPAD web GUI by navigating to Configuration > Tunnel Settings. The screen shot below shows an RPAD located inside of the corporate firewall that is being configured as the Tunnel client, using the default port of 1194.
In this example, the RPAD IP address is 10.233.10.116 and the remote tunnel server address of 10.233.6.123 is actually a virtual IP address that has been configured on the inside firewall. The firewall has also been configured with a 1:1 NAT of this virtual IP address to the IP address of the Tunnel Server RPAD.
RPAD
Tunnel – Port 1194
Tunnel Server
Corp LANCorp LAN
RPAD
Tunnel Client
DMZ
192.168.1.203 10.233.10.11610.233.6.1231:1 NAT
Virtual IP
The configuration settings on the RPAD Tunnel Server are shown below:
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 16 of 32
H.460 and DMA Gatekeeper Registration Support for H.323 Remote Users
The RealPresence Access Director system supports calls to and from H.460-enabled endpoints. The H.460 standard allows secure traversal of H.323 signaling across network address translators (NATs) and firewalls. The RealPresence Access Director system now allows videoconference participants with H.460-enabled endpoints or non-H.460 endpoints to register to a Polycom® RealPresence® Distributed Media Application™ (DMA™) system (H.323 gatekeeper) and place and receive H.323 calls across firewalls and NATs.
To support H.460 the RPAD system does the following:
Uses the H.460.18 registration procedure to proxy registration requests from H.460-
enabled endpoints to the gatekeeper
Enables the keep-alive mechanism of H.460.19 for opening and maintaining RTP and
RTCP pinholes in the firewall for communication between the remote endpoint and the
gatekeeper
The new call scenarios supported in version 3.0 include:
H.460 remote endpoint call to internal H.323 endpoint
Internal H.323 endpoint call to remote H.460 endpoint
H.460 endpoint call to another company’s H.323 endpoint (remote all trusted Business-
to-Business)
H.460 remote endpoint call to open B2B company’s H.323 endpoint (remote call ‘open’
Business-to-Business)
H.460 remote endpoint gateway call with SIP endpoint
To support H.460, H.323 signaling must be enabled on the RPAD on the Configuration > H.323 Settings page. The bottom of this page also includes two H.460-specific settings:
External registration refresh interval – specifies how often registered endpoints send
keep-alive messages to the RPAD system
Internal registration refresh interval – specifies how often the RPAD system sends
keep-alive messages to the DMA system to refresh the existing call registration
Note: the RPAD system supports only symmetric media communication. This means that remote H.460 endpoints must use the same port to send and receive one media stream.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 17 of 32
Lab Exercise: H.323 Registration / H.460 Support for External Endpoints
Lab Diagram
RPAD
LAN
RPRM
External
User
DMZ
User Two
e.164 = 661004
Internet
DMA
HDX
e.164=5158
Exercise Summary
In this lab exercise you will enable H.323 on the RPAD and H.323 register a remote endpoint to the DMA gatekeeper. From the remote H.323 endpoint, place a call to an inside endpoint and receive a call from an inside endpoint. The lab steps will include:
Enable H.323 on the RPAD and verify default H.460 settings
Configure H.323 and H.460 dynamic provisioning settings from the RealPresence
Resource Manager (different configuration steps for RPRM software versions 7.x and
8.x)
H.323 register a remote endpoint and place call from the external endpoint to a
registered H.323 endpoint on the corporate LAN
Note: this lab includes steps for RealPresence Resource Manager version 7 and
version 8. Select the correct steps for the version used by your organization.
Detailed Lab Steps
Configure H.460 Support on the RPAD
1. From the RPAD web interface, navigate to Configuration > H.323 Settings and check the box to Enable H.323 signaling and click Update
2. In the H.460 settings section, ensure the External registration refresh interval is set to 60 (seconds) and the Internal registration refresh interval is set to 300 (seconds). If changes were made, click Update. Click OK and OK again, when prompted
Configure H.323 Gatekeeper and H.460 Provisioning from RPRM version 8.x
3. For RPRM version 8.x systems, open the web interface and navigate to Endpoint > Dynamic Management > Provisioning Profiles and take the action to Add
4. Set the Profile Name to External Endpoints Profile and ensure the Provisioning
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 18 of 32
Profile Type is set to Network Provisioning Profile
5. Navigate to Firewall Settings and check the box to Enable H.460 Firewall Traversal and change NAT Configuration to Auto
6. Navigate to H.323 Settings and check the box to Enable IPH.323 and enter the IP Address of your DMA Gatekeeper in the box provided. Click OK to save changes
7. Navigate to Endpoint > Dynamic Management > Provisioning Rules and take the action to Add a new rule to apply the profile you just created
8. Name the rule External Endpoints and click the button to Add a condition:
Type: Site
Attribute: Site
Operator: =
Value: RPAD (selected from the drop-down list)
Click OK to save the new condition
9. Navigate to Endpoint Provisioning Profile and select the External Endpoints Profile from the list. Use the down arrow icon to move this profile to the Selected Profiles list
10. Click OK to save the new Provisioning Rule
RPRM version 7.x Configuration for H.323 Gatekeeper and H.460 Provisioning
11. For RPRM version 7.x systems, open the web interface and navigate to Admin > Topology > Sites and highlight the RPAD network site
12. Take the action to Edit Site Provisioning Profile
13. Navigate to H.323 Settings and check the box to Enable IPH.323 and enter the Gatekeeper Address of your DMA in the box provided
14. Navigate to Firewall Settings and check the box to Enable H.460 Firewall Traversal and set NAT Configuration to Auto. Click OK to update
H.323 Register Remote Endpoint via Dynamic Provisioning and Make Call
15. From an external PC, start RealPresence Desktop
16. Sign In using an existing user account to ensure correct provisioning of H.460 from the RealPresence Resource Manager
17. Verify the registration status by clicking the Status button
Record H.323
18. Place a call to an endpoint inside the Corporate LAN, in this case the Training Lab endpoint with an e.164 alias of 5158
View the Active Call from RPAD, DMA and RPRM Web GUIs
19. Access the RPAD web GUI and notice the active H.323 call shown on the Dashboard
20. Navigate to Diagnostics > Active Call to locate and highlight the active H.323 call
21. Open the Call Info, Originator and Destination Panes on the right side of the GUI
to view additional call details
22. Access the DMA web GUI and notice the active H.323 call counter on the Dashboard
23. Navigate to the RPRM web GUI and notice the active call from User Two to the Lab
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 19 of 32
HDX in the Conference Status Pane on the Dashboard
24. Navigate to Conference > Ongoing, which will allow you to manage the ongoing conference
25. Take the Action to Manage the conference
26. When finished, use the Terminate action to end the active call from the Resource Manager
End of practical exercise
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 20 of 32
Default Destination Alias for H.323 Guest Users
Enabling the H.323 Default Policy allows the RPAD system to assign a default destination alias to incoming H.323 guest calls that do not already include a destination alias in the Q.931 call SETUP message. One default alias can be configured and the RPAD system will use this to route the H.323 guest calls to the DMA gatekeeper. The default alias can be entered as an E.164 alias or H.323 ID.
This feature provides both security and simplicity for an organization. All external guest H.323 callers can be provided with the same dialing information for the RPAD system and the H.323 Default Policy can be used to route all incoming callers to a specific DMA Virtual Entry Queue (VEQ) or MCU entry queue. These guest callers will then be required to enter a valid VMR or conference number.
If both the H.323 Guest Policy and the H.323 Default Policy are enabled, the RPAD uses the default destination alias to forward H.323 guest calls to the DMA without the H.323 Guest Policy prefix. This would, in essence, route all incoming H.323 guest or unauthorized calls to a specific destination such as a DMA VEQ or MCU entry queue.
Shown below is a diagram of a guest user placing an H.323 call directly to the DNS name of the RPAD: video.medeatalk.com. Because there is no specific alias in the dial string and the H.323 default policy is enabled with an e.164 alias of 761000 the RPAD will send this call to the internal gatekeeper with an ARQ of 761000. In this example, the RMX is registered with the DMA gatekeeper with a prefix of 76 and the numeric ID of 1000 is assigned to the Default Entry Queue.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 21 of 32
H.323 Guest Policy Call Flow
RPAD
LAN
HDX
RMX RPRM
Guest
User
DMZ
Dials
video.medeatalk.com
1
Internet
ARQ = 761000
2
3
Resolves 76 prefix to
RMX and routes call
Caller placed in Entry
Queue 1000 on RMX
DMA
Access Control List (ACL) Support
The RealPresence Access Director system supports the use of Access Control Lists (ACLs) for SIP and H.323 calls that come through the external signaling ports. ACL rules and rule settings define whether the RealPresence Access Director system allows or denies a specific type of SIP or H.323 request from a public network. The use of Access Control Lists provides increased protection against external security threats.
The Access Control List features provide numerous options for defining access rules and are highly configurable. Existing default Access Control List rules can be used within the RealPresence Access Director system and new rules can be created to make white lists, black lists, and other access controls. Additionally, multiple Access Control List rules can be applied on one port.
There are three separate components that come into play when configuring an ACL on the RPAD system:
ACL Variables – optional component that provides an efficient method of defining
group members, source IP addresses and other lists. Custom variables can be
created and values (list items) can be added to the variables. A variable, with all of its
component values, can then be applied to a condition for ACL rules
ACL Rules – contains one or more conditions that must be met
ACL Settings – allows one or more rules to be applied to a signaling type, IP address
and port. An ACL Setting combines an ACL Rule with the action the RPAD system
performs when it applies the rule to incoming calls. Rules are applied according to the
order of priority that is configured. Note: all changes are effective immediately for new
call requests and active calls are not affected
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 22 of 32
Using the Access Control List feature the RPAD can be configured, for example, to implement an H.323 registration white list. To configure this on the RPAD is a two-step process:
1. Create an ACL Rule called 323RegWhitelist that uses one of the three system ACL Variables maintained by the RPAD, prov_list. This variable maintains the IP addresses of all endpoints that are successfully provisioned by the RealPresence Resource Manager through the RPAD system.
a. The rule will have two conditions to identify H.323 registration requests from endpoints that have not been provisioned by the RPRM:
Request.type = RAS
and
Request.src-ip not memberof prov_list
2. Create an ACL Setting on the H.323 Service to Deny access to endpoints based on the 323RegWhitelist rule created above
This example will be demonstrated in the lab exercise below.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 23 of 32
Lab Exercise: Access Control Lists
Exercise Summary
This lab exercise will allow you to configure the ACL feature of the RPAD to deny H.323 registration to endpoints that have not been provisioned by the RealPresence Resource Manager through the RPAD system. This involves two steps:
1. Create an ACL Rule called 323RegWhitelist that uses one of the three system ACL Variables maintained by the RPAD, prov_list. This variable maintains the IP addresses of all H.323 endpoints that are successfully provisioned by the RealPresence Resource Manager through the RPAD system
a. The rule will have two conditions to identify H.323 registration requests from endpoints that have not been provisioned by the RPRM:
Request.type = RAS
and
Request.src-ip not memberof prov_list
2. Create an ACL Setting on the H.323 Service to Deny access to endpoints based on the 323RegWhitelist rule created above
Detailed Lab Steps
Configure ACL Rule
1. Login to the RPAD system and navigate to Configuration > Access Control List Rules
2. Take the Action to Add a new rule
3. Name the Rule 323RegWhitelist, select H323 from the drop-down and enter a description of Defines H.323 registration request from endpoint that is not provisioned by the RPRM (RPAD will DENY)
4. Click the button to Add a condition and select the following:
Attribute: request.type
Operator: ==
Value: RAS
Click OK to save the condition
5. Click the button to Add a condition and select the following:
Attribute: request.src-ip
Operator: not memberOf
Value: prov_list
Click OK to save the condition
6. Click OK to save the new ACL Rule
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 24 of 32
Configure ACL Settings
7. Navigate to Configuration > Access Control List Settings
8. Take the action to Add and select a service type of H323
9. Click the button to Add a new ACL Rule
10. From the drop-down lists, select the following:
ACL Name: 323RegWhitelist
Action: deny
Click OK to save the new rule
Test the Rule
11. From an external H.323 endpoint, enable H.460 and attempt to H.323 register via the RPAD
12. The endpoint should receive a rejection message from the gatekeeper, which is actually coming from the RPAD
Review the Security Denial from the RPAD
13. Open the RPAD web GUI and navigate to Diagnostics > Registration History
14. Change the Signaling type to H.323 and click Search
15. Highlight the Offsite Endpoint registration attempt and take the Action to Show Registration Details
16. Navigate to Registration Events, find the INBOUND_REQUEST and click Show Message
17. Click Expand All to review the RAS message details, then click OK to close the
window
18. Find the OUTBOUND_RESPONSE and click Show Message
19. Click Expand All to review the RAS message details and notice the securityDenial from the RPAD because of the ACL Rule
20. Click OK to close the window
End of practical exercise
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 25 of 32
Updating SIP External Port Settings
In previous versions of the RealPresence Access Director system, you could specify to Forbid Registration for specific SIP external ports. The Forbid Registration option is not available in version 3.0 of the RPAD system. If you configured any SIP external ports to forbid registrations, this setting will not be applied to any SIP external ports after you upgrade to this version of the RealPresence Access Director system. To forbid registration on SIP external ports, you must create an Access Control List rule to deny SIP registration for the ports you specify.
To create an Access Control List rule to deny SIP registration on an external port:
1. Go to Configuration > Access Control List Rules and click Add to create a new rule
2. Enter a name for the rule, such as ACL-Deny-SIP-REGISTER. Do not use blank spaces in the name
3. Select SIP and enter a description of the rule.
4. Click Add and select the following options:
— Attribute: request.method
— Operator: = =
— Value: REGISTER
5. Click OK twice.
6. Go to Configuration > Access Control List Settings
7. Click Add and select the following options:
— Service Name: SIP
— IP: The IP address of the network interface assigned to external signaling.
— Port: The external SIP port that will deny SIP registrations.
8. Click Add and select the following options:
— Access Control List Name: the rule you created to forbid SIP registration (e.g., ACL-Deny-SIP-REGISTER)
— Action: Deny
9. Click OK. The setting displays in the Rule Setting list
10. Click OK to apply the rule
11. Apply the rule to all ports that had Forbid Registration enabled in previous versions of the RPAD system
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 26 of 32
Call History and Registration History
Version 3.0 provides the ability to access not only active call information, but call history and registration history information as well. Both options are accessed from the Diagnostics menu and are very similar in format to the call and registration history found in the Polycom DMA 7000 system.
The historical data that is available depends on the settings you configure for history retention. RPAD History Retention Settings are accessed from the Admin menu and can be configured to specify when the system purges call and registration history data. According to the values you specify for retention, the system purges the oldest registration history, call history, and registration signaling message records when:
The number of records exceeds the maximum number to retain
The records have been stored for the maximum number of days
When the system purges call history or registration history records, all of the associated data is also purged, including call events, call properties, and registration signaling events. Shown below is the History Retention Settings page populated with the default values:
Accessing call history via the Diagnostics > Call History menu starts by initiating a search. The search pane at the top of the page allows searching via the following criteria:
Start after – date and time after which the call began
Start before – date and time before which the call began
Signaling type – SIP or H.323
Originator – the originating device’s display name, alias or IP address (in that order of
preference), depending on what is provided in the call signaling
Dial string – dial string sent by call originator, when available
Once the appropriate search criteria have been entered the Search button initiates the search of the RPAD retained call history and the first 500 results will be presented.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 27 of 32
To view the call details of a particular call, simply highlight the call of interest and select the Show Call Details action. This option will present three categories of information: Call Info, Call Events and Subscription Events, as shown below.
The Call Info pane includes the following information:
Call Status – active or ended
Start Time – the time the call began, from the first signaling event
End time – the time the call ended (session closed)
Duration – duration of the call in minutes
Signaling – SIP or H.323
Originator and Destination– call ID, originating endpoint’s display name, name, alias or
IP address, destination endpoint’s display name, name, alias or IP address, dial string
sent by the originator, IP address from which the RPAD receives SIP INVITE and
H.323 SETUP messages
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 28 of 32
The Call Events pane provides a detailed list of all signaling events for the selected call. The figure below shows the Call Events for an H.323 call:
An example of Call Events for a SIP call is shown below:
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 29 of 32
An example of H.323 registration history was illustrated earlier in the ACL H.323 whitelist example. The offsite H.323 endpoint attempted to register via the RPAD and the Access Control List rule was applied to deny the registration attempt because the endpoint was not provisioned by the RealPresence Resource Manager system. Because the H.323 registration attempt was denied by the RPAD, there will be no record of this attempt in the DMA Registration History.
All RPAD SIP and H.323 registrations can be examined by navigating to Diagnostics > Registration History, as shown below.
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 30 of 32
Lab Exercise: Call History
Exercise Summary
This lab exercise has three steps:
Review and record the current RPAD Call History Retention Settings
Call Details for one SIP and one H.323 call from the RPAD Call History page
Detailed Lab Steps
Modify Call History Retention Settings
1. Access the RPAD web GUI and navigate to Admin > History Retention Settings
2. Review the current settings and note the
Number of Call History Records to Retain: ________
Change the number of retention days to 120 and click Update
View SIP Call Details
3. Access the RPAD web GUI and navigate to Diagnostics > Call History
4. Change the Signaling type to SIP and click the Search button to return a list of today’s SIP calls
5. Highlight a call and take the Action to Show Call Details
6. On the Call Info pane, take note of the Originator and Destination IP addresses:
Originator IP address: ___________________________
Destination IP address: ___________________________
7. Navigate to Call Events to find the SIP INVITE with an Event-type of INBOUND_REQUEST and click Show Message. Take note of the following:
SIP Protocol (TCP or TLS?): _____________________
From URI: ___________________________
To URI: ______________________________
8. Click OK to close the Call Details window
View H.323 Call Details
9. Change the Signaling type to H.323 and click the Search button to return a list of today’s H.323 calls
10. Highlight a call and take the Action to Show Call Details
11. On the Call Info pane, take note of the Originator and Destination IP addresses:
Originator IP address: ___________________________
Destination IP address: ___________________________
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 31 of 32
12. Navigate to Call Events and find the Event-type of INBOUND_REQUEST and click Show Message. Take note of the following:
Destination e.164: _____________________
Source e.164: ___________________________
Gatekeeper Identifier: ______________________________
13. Click OK to close the Call Details window
End of practical exercises
Breaking News: RealPresence Access Director 2.1 / 3.0
Page 32 of 32
TCP Reverse Proxy Enhancement (Support for MEA)
If the RPAD system has been deployed as part of the Polycom® RealPresence® CloudAXIS™ Suite, the RealPresence Access Director system’s access proxy feature supports a TCP reverse proxy connection, that Web clients can use to send meeting requests to the internal Meeting Experience Application (MEA), on the CloudAXIS server.
A TCP reverse proxy connection can be bound to any existing interface, as well as the signaling port. To avoid conflict with the current proxy for the RealPresence Resource Manager the MEA proxy should be set to a TCP port other than 443 or be bound to a different port than the Resource Manager.