Breaking News RealPresence Access Director 2.1 / 3learningcenter.polycom.com/plconline/courses/BreakingNews...Breaking News: RealPresence Access Director 2.1 / 3.0 Page 9 of 32 Blocked

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.


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


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


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.


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.


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.


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

[email protected]

1

Internet

ARQ = 77151102

2

3

4

Processes dial rule,

resolves to VMR 151102

Caller routed to VMR

151102 on RMX

DMA

Medeatalk Corporation

mailto:[email protected]


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

[email protected]

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.

mailto:[email protected]


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.


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


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


LAN

eth2

A four-interface deployment provides complete separation of signaling and media.

Internet

RPAD

DMZ

eth0eth1


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


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


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.


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:


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.


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


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


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


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.


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


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.


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


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


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


— 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.


— 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


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.


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


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:


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.


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: ___________________________


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


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.

Breaking News RealPresence Access Director 2.1 / 3learningcenter.polycom.com/plconline/courses/BreakingNews...Breaking News: RealPresence Access Director 2.1 / 3.0 Page 9 of 32 Blocked

Documents