Copyright© 2014 Avaya Inc. All Rights Reserved.This document contains Avaya Inc. confidential and proprietary information.

It is not to be copied, disclosed or distributed in any manner, in whole or in part, without express written authorization of Avaya Inc. While the information in this document is believed to be accurate and reliable, except as otherwise expressly agreed to in writing, AVAYA PROVIDES THIS DOCUMENT “AS IS” WITHOUT WARRANTY OR CONDITION OF ANY KIND, EITHER EXPRES OR IMPLIED. The information and/or products described in this document are subject to change without notice.

Avaya and the Avaya Logo are trademarks of Avaya Inc. and may be registered in certainjurisdictions. All trademarks identified by®, TM or SM are registered marks, trademarks, and service marks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners.

Learning Object Overview

After you complete this learning object, you should be able to:• Identify IP Office™ networking enhancements • Identify media enhancements in IP Office networks involving NAT

IP Office Networking Enhancements: IP Office Line

Notes

In previous releases, Networking IP Offices was achieved using H.323 Lines configured with Supplementary Services set to IP Of-fice SCN. On upgrade to 9.1 these lines are migrated to IP Office Lines. Note - H.323 lines with other supplementary service values remain as H.323 lines.

An IP Office Line with Transport Type Proprietary and Networking Level SCN will interwork with a previous release system con-figured with an H.323 SCN line. The supported feature level will be that of the lower release system. Note - An IP Office Line with Transport Type Proprietary and Networking Level None will not interwork with a previous release system configured with an H.323 line with H.450 supplementary services. H.323 Lines should be used on both ends if this is required.

New IP Office Line Functionality

Notes

IP Office now offers functionality for IP Office Lines. Transport Type functionality defines which transport protocols should be used for Call and Network Signaling.

The Proprietary functionality gives the IP Office lines H.225 Call Signaling over TCP which is roughly equivalent to H323 Lines. WebSocket Client / Server functionality enables the IP Office lines to become an HTTP / HTTPS initiated TCP pipe through which Call and Network Signaling is securely tunneled.

IP Office Lines Signaling Security is offered with WebSocket Client/Server Transport and provides varying levels of security.Unsecured Signaling Security is an HTTP/TCP connection which provides no security.Medium Signaling Security uses an HTTPS/TLS encrypted connection. Providing a client certificate NOT required to be in server system’s certificate storeHigh Signaling Security, which is an HTTPS/TLS connection, uses a required a client certificate that is in server system’s certificate store.

New IP Office Line Functionality (continued)

Notes

(SRTP) Secure Real -Time Transport Protocol Media Security is offered on all Transport Types and Network Levels.WebSockets, found in RFC 6455, are bi-directional HTTP or HTTPS communication pipes initiated from a client to a server.

They are designed to permit clients behind a local NAT/firewall to traverse the internet to a server by using well known ports and protocols.

When used in IP Office deployments, the system with the WebSocket Server line must be reachable by clients via a static public IP address. This address is configured on the WebSocket Client line. As connections are initiated by the Client, the public IP address of the Client side system is not required at configuration time by the Server side system.

For identity purposes and Solution Management, the private IP address of the interface over which the link is made is required.

IP Office WebSocket Lines: Deployment/Configuration

Notes

In the above scenario, the connection between the main IP Office unit and expansion unit is through a WebSocket tunnel using IP Office Lines.

In order for the connection to be set up, the IP Office Lines with WebSocket functionality will have to be configured.

In the transport type, one IP Office Line will use the WebSocket Server and the other the WebSocket Client.

SCN Networking Level must be turned on and the Security set to Medium.

You must also populate the Gateway IP Address, the Location set to Cloud and add the security password.

IP Office WebSocket Lines: Monitoring

Notes

System Status provides real-time monitoring of IP Office Lines and many of their characteristics.

You can see an at-a-glance view of the IP address, Line Number, Number of channels and which of those channels are in use.

You can view the Networking Level and see if the Direct Media Path or Silence Suppression or Fax Transport is enabled.

IP Office WebSocket Lines: Operation

Notes

In the sample trace, IP Office attempts to establish a single Web Socket pipe for Call Signaling.

You can see the authorization or password provided for authentication, the IP addresses for both lines, and finally, the Connection Active.

There are different SCN WebSocket pipes for the different protocols used. The SCN Support Protocol supports IP Office SCN Data exchange.

The Web_Proxy Protocol supports a Proxy service for relaying of Web Service calls and responses. The SCN_TAPI Protocol sup-ports a Proxy service for relaying of TAPI call and responses.

IP Offices Lines: Troubleshooting

Notes

For troubleshooting high level alarms, generated by out-of-service trunks, System Status Application is the tool.SysMonitor is the primary tool for capturing call traces when troubleshooting at a deeper level. An HTTP trace, will show IP Ad-dresses and Port Numbers. These traces can indicate security password/authentication mismatches with HTTP 401 Unauthorized response.

The Server side, in a trace, will display if it is waiting for a Client connection.Check the Server’s Public IP Addresses and Port Numbers against the Client’s line configuration such as the trace above. It verifies IP address mismatch and isolate the root cause or which end of the tunnel is creating the outage.

Network Enhancements: NAT Traversal

Notes

Release 9.1 implements NAT traversal for Media over IP Office Lines. Functionality is available on all IP Office platforms and all modes that support IP Office lines. There are no special license require-ments.

The primary drive for adding this feature is hosted deployment, which is a special type of deployment for Server Edition, where both Primary and Expansion systems often reside behind routers performing NAT.

The Primary system is expected to either be directly on the internet, or will reside behind a special type of NAT / DMZ that has all required ports open and performs 1-1 port mapping. Its public address is static. Expansion systems reside behind an unspecified type of NAT which doesn’t necessarily have a fixed IP address and we might not have any influence over that NAT such as opening or forwarding ports.

For simplicity, the solution implements this requirement in the similar way it exists for SIP trunks, H323 and SIP remote workers. The following implications are that the IP Office line transport type is limited to WebSocket Server/Client, a proprietary transport type does not have NAT traversal functionalities and that there is no direct media if the endpoint involved is behind a NAT.

Note: Within this section, the term Primary is often used to describe the IP Office with the WebSocket Server end of the IP Office Line, and Expansion for the WebSocket client end, but this is only to simplify explanations. The solution is equally applicable in non-Server Edition deployments.

Network Topology: Configuration

Notes

To configure the Primary IP Office unit behind the 1 to 1 NAT, go to Network topology > Firewall / NAT. Type and set to One-To-One NAT. This setting is not discoverable by the STUN server if available. Setting One-To-One NAT will also fix public ports for remote workers.

Network topology > Public IP Address should be set to A.

To configure the Expansion unit the RTP keep-alives for RTP and RTCP must be enabled in the System>LANx>VoIP>RTP menu.No special Network topology configuration is required.

Note: It might be configured if expansion module has remote workers or public SIP trunks, but that is not relevant for this feature.

Network Topology Operation

Notes

When the WebSocket connection is established between Primary and Expansion, they exchange their private IP addresses with-in the packets and by comparing them with the actual addresses the packets came from, can conclude whether the other one is behind a NAT.

In call signaling, if a Primary is behind a NAT it will ensure that all media addresses sent to the Expansion unit are correct, meaning they contain public IP addresses and properly translated ports, 1-1, in a typical deployment. The Expansion unit will not change any media addresses in the packet, so if behind a NAT, these addresses/ports will be incorrect.

In Media when the Expansion is behind a NAT (detected when the line is connected), the Primary will use late binding to discover where to send media packets. This algorithm is already used for H323 and SIP remote workers and essentially it means that the primary will not send any packets until it receives the first one from the remote, and will store the IP address and Port and use them in future communication during that call.

NAT Enhancements – SSA

• The IP Office line must be In Service before calls can be attempted.• When IP Office detects that lines traverse NATs they will be displayed in the Trunk details page.

Notes

NAT Enhancements in IP Office 9.1 include NAT visibility, however, the IP Office line must be In Service before calls can be at-tempted.

When IP Office detects that lines traverse NATs, these should be displayed in the Trunk details page.

NAT Enhancements – SysMon

Notes

SysMonitor enhancements include default traces and more details with H323 tab Summary Traces, H.323 Send, H.323 Receive & H.323 FastStart.

The Presence of NAT is displayed in SysMonitor when the lines are coming up.

You’ll see Server Side detection that the client is behind a NAT, Server Side indication that the Client has detected that the Server is behind a NAT and Client Side indication that the Server has detected the Client is behind a NAT

NAT Troubleshooting Tips

Notes

Confirm that the lines are In Service and that NAT traversal is properly detected. If still no speech path, confirm that NAT topology is properly configured on the primary side (One-To-One NAT).

If the problem persists, Use SysMonitor & status/RTP Sessions window on the server side. Identify the appropriate session (based on ports and addresses from signaling), and if remote client is behind a NAT, verify that NAT column in this window is set to yes (this indicates late binding and will be present only on the server side).

Check whether IP Office is receiving any packets. In some situations, routers can be quite restrictive, so if IP Office is not receiving any packets, check that the client is sending packets (RTP Sessions window on the client side). If it is then the fault is likely in the router on the expansion side – potentially disabled outgoing traffic on some ports.

Learning Object Summary

You should now be able to:• Identify IP Office networking enhancements • Identify media enhancements in IP Office networks involving NAT