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 certain
jurisdictions. 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 Office 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 configured 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
systems certificate store
High Signaling Security, which is an HTTPS/TLS connection, uses a required a client certificate that is in server systems 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 supports 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 Addresses 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 Servers Public IP Addresses and Port Numbers against the Clients 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 requirements.
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 doesnt 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 within 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 attempted.
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.
Youll 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