Avaya IP Office Platform in a Branch Environment Reference Configuration

Transcription

1 Avaya IP Office Platform in a Branch Environment Reference Configuration Release Issue 3 December 2014

2 All Rights Reserved. Notice While reasonable efforts have been made to ensure that the information in this document is complete and accurate at the time of printing, Avaya assumes no liability for any errors. Avaya reserves the right to make changes and corrections to the information in this document without the obligation to notify any person or organization of such changes. For full support, please see the complete document, Avaya Support Notices for Hardware Documentation, document number For full support, please see the complete document, Avaya Support Notices for Software Documentation, document number To locate this document on our website, simply go to and search for the document number in the search box. Documentation disclaimer Documentation means information published by Avaya in varying mediums which may include product information, operating instructions and performance specifications that Avaya may generally make available to users of its products and Hosted Services. Documentation does not include marketing materials. Avaya shall not be responsible for any modifications, additions, or deletions to the original published version of documentation unless such modifications, additions, or deletions were performed by Avaya. End User agrees to indemnify and hold harmless Avaya, Avaya's agents, servants and employees against all claims, lawsuits, demands and judgments arising out of, or in connection with, subsequent modifications, additions or deletions to this documentation, to the extent made by End User. Link disclaimer Avaya is not responsible for the contents or reliability of any linked websites referenced within this site or documentation provided by Avaya. Avaya is not responsible for the accuracy of any information, statement or content provided on these sites and does not necessarily endorse the products, services, or information described or offered within them. Avaya does not guarantee that these links will work all the time and has no control over the availability of the linked pages. Warranty Avaya provides a limited warranty on Avaya hardware and software. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this product while under warranty is available to Avaya customers and other parties through the Avaya Support website: or such successor site as designated by Avaya. Please note that if You acquired the product(s) from an authorized Avaya Channel Partner outside of the United States and Canada, the warranty is provided to You by said Avaya Channel Partner and not by Avaya. Hosted Service means a hosted service subscription that You acquire from either Avaya or an authorized Avaya Channel Partner (as applicable) and which is described further in Hosted SAS or other service description documentation regarding the applicable hosted service. If You purchase a Hosted Service subscription, the foregoing limited warranty may not apply but You may be entitled to support services in connection with the Hosted Service as described further in your service description documents for the applicable Hosted Service. Contact Avaya or Avaya Channel Partner (as applicable) for more information. Hosted Service THE FOLLOWING APPLIES IF YOU PURCHASE A HOSTED SERVICE SUBSCRIPTION FROM AVAYA OR AN AVAYA CHANNEL PARTNER (AS APPLICABLE), THE TERMS OF USE FOR HOSTED SERVICES ARE AVAILABLE ON THE AVAYA WEBSITE, UNDER THE LINK Avaya Terms of Use for Hosted Services OR SUCH SUCCESSOR SITE AS DESIGNATED BY AVAYA, AND ARE APPLICABLE TO ANYONE WHO ACCESSES OR USES THE HOSTED SERVICE. BY ACCESSING OR USING THE HOSTED SERVICE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF YOURSELF AND THE ENTITY FOR WHOM YOU ARE DOING SO (HEREINAFTER REFERRED TO INTERCHANGEABLY AS YOU AND END USER ), AGREE TO THE TERMS OF USE. IF YOU ARE ACCEPTING THE TERMS OF USE ON BEHALF A COMPANY OR OTHER LEGAL ENTITY, YOU REPRESENT THAT YOU HAVE THE AUTHORITY TO BIND SUCH ENTITY TO THESE TERMS OF USE. IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT WISH TO ACCEPT THESE TERMS OF USE, YOU MUST NOT ACCESS OR USE THE HOSTED SERVICE OR AUTHORIZE ANYONE TO ACCESS OR USE THE HOSTED SERVICE. YOUR USE OF THE HOSTED SERVICE SHALL BE LIMITED BY THE NUMBER AND TYPE OF LICENSES PURCHASED UNDER YOUR CONTRACT FOR THE HOSTED SERVICE, PROVIDED, HOWEVER, THAT FOR CERTAIN HOSTED SERVICES IF APPLICABLE, YOU MAY HAVE THE OPPORTUNITY TO USE FLEX LICENSES, WHICH WILL BE INVOICED ACCORDING TO ACTUAL USAGE ABOVE THE CONTRACT LICENSE LEVEL. CONTACT AVAYA OR AVAYA S CHANNEL PARTNER FOR MORE INFORMATION ABOUT THE LICENSES FOR THE APPLICABLE HOSTED SERVICE, THE AVAILABILITY OF ANY FLEX LICENSES (IF APPLICABLE), PRICING AND BILLING INFORMATION, AND OTHER IMPORTANT INFORMATION REGARDING THE HOSTED SERVICE. Licenses THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA WEBSITE, OR SUCH SUCCESSOR SITE AS DESIGNATED BY AVAYA, ARE APPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/OR INSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC., ANY AVAYA AFFILIATE, OR AN AVAYA CHANNEL PARTNER (AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITH AVAYA OR AN AVAYA CHANNEL PARTNER. UNLESS OTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOES NOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINED FROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR AN AVAYA CHANNEL PARTNER; AVAYA RESERVES THE RIGHT TO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSE USING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BY INSTALLING, DOWNLOADING OR USING THE SOFTWARE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OF YOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING, DOWNLOADING OR USING THE SOFTWARE (HEREINAFTER REFERRED TO INTERCHANGEABLY AS YOU AND END USER ), AGREE TO THESE TERMS AND CONDITIONS AND CREATE A BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THE APPLICABLE AVAYA AFFILIATE ( AVAYA ). Avaya grants You a license within the scope of the license types described below, with the exception of Heritage Nortel Software, for which the scope of the license is detailed below. Where the order documentation does not expressly identify a license type, the applicable license will be a Designated System License. The applicable number of licenses and units of capacity for which the license is granted will be one (1), unless a different number of licenses or units of capacity is specified in the documentation or other materials available to You. Software means computer programs in object code, provided by Avaya or an Avaya Channel Partner, whether as stand-alone products, pre-installed on hardware products, and any upgrades, updates, patches, bug fixes, or modified versions thereto. Designated Processor means a single stand-alone computing device. Server means a Designated Processor that hosts a software application to be accessed by multiple users. Instance means a single copy of the Software executing at a particular time: (i) on one physical machine; or (ii) on one deployed software virtual machine ( VM ) or similar deployment. License type(s) Designated System(s) License (DS). End User may install and use each copy or an Instance of the Software only on a number of Designated Processors up to the number indicated in the order. Avaya may require the Designated Processor(s) to be identified in the order by type, serial number, feature key, Instance, location or other specific designation, or to be provided by End User to Avaya through electronic means established by Avaya specifically for this purpose.

3 Concurrent User License (CU). End User may install and use the Software on multiple Designated Processors or one or more Servers, so long as only the licensed number of Units are accessing and using the Software at any given time. A Unit means the unit on which Avaya, at its sole discretion, bases the pricing of its licenses and can be, without limitation, an agent, port or user, an or voice mail account in the name of a person or corporate function (e.g., webmaster or helpdesk), or a directory entry in the administrative database utilized by the Software that permits one user to interface with the Software. Units may be linked to a specific, identified Server or an Instance of the Software. Database License (DL). End User may install and use each copy or an Instance of the Software on one Server or on multiple Servers provided that each of the Servers on which the Software is installed communicates with no more than one Instance of the same database. CPU License (CP). End User may install and use each copy or Instance of the Software on a number of Servers up to the number indicated in the order provided that the performance capacity of the Server(s) does not exceed the performance capacity specified for the Software. End User may not re-install or operate the Software on Server(s) with a larger performance capacity without Avaya s prior consent and payment of an upgrade fee. Named User License (NU). You may: (i) install and use the Software on a single Designated Processor or Server per authorized Named User (defined below); or (ii) install and use the Software on a Server so long as only authorized Named Users access and use the Software. Named User, means a user or device that has been expressly authorized by Avaya to access and use the Software. At Avaya s sole discretion, a Named User may be, without limitation, designated by name, corporate function (e.g., webmaster or helpdesk), an or voice mail account in the name of a person or corporate function, or a directory entry in the administrative database utilized by the Software that permits one user to interface with the Software. Shrinkwrap License (SR). You may install and use the Software in accordance with the terms and conditions of the applicable license agreements, such as shrinkwrap or clickthrough license accompanying or applicable to the Software ( Shrinkwrap License ). Heritage Nortel Software Heritage Nortel Software means the software that was acquired by Avaya as part of its purchase of the Nortel Enterprise Solutions Business in December The Heritage Nortel Software currently available for license from Avaya is the software contained within the list of Heritage Nortel Products located at LicenseInfo under the link Heritage Nortel Products or such successor site as designated by Avaya. For Heritage Nortel Software, Avaya grants You a license to use Heritage Nortel Software provided hereunder solely to the extent of the authorized activation or authorized usage level, solely for the purpose specified in the Documentation, and solely as embedded in, for execution on, or for communication with Avaya equipment. Charges for Heritage Nortel Software may be based on extent of activation or use authorized as specified in an order or invoice. Copyright Except where expressly stated otherwise, no use should be made of materials on this site, the Documentation, Software, Hosted Service, or hardware provided by Avaya. All content on this site, the documentation, Hosted Service, and the product provided by Avaya including the selection, arrangement and design of the content is owned either by Avaya or its licensors and is protected by copyright and other intellectual property laws including the sui generis rights relating to the protection of databases. You may not modify, copy, reproduce, republish, upload, post, transmit or distribute in any way any content, in whole or in part, including any code and software unless expressly authorized by Avaya. Unauthorized reproduction, transmission, dissemination, storage, and or use without the express written consent of Avaya can be a criminal, as well as a civil offense under the applicable law. Virtualization Each product has its own ordering code and license types. Note that each Instance of a product must be separately licensed and ordered. For example, if the end user customer or Avaya Channel Partner would like to install two Instances of the same type of products, then two products of that type must be ordered. Third Party Components Third Party Components mean certain software programs or portions thereof included in the Software or Hosted Service may contain software (including open source software) distributed under third party agreements ( Third Party Components ), which contain terms regarding the rights to use certain portions of the Software ( Third Party Terms ). As required, information regarding distributed Linux OS source code (for those products that have distributed Linux OS source code) and identifying the copyright holders of the Third Party Components and the Third Party Terms that apply is available in the products, Documentation or on Avaya s website at: support.avaya.com/copyright or such successor site as designated by Avaya. You agree to the Third Party Terms for any such Third Party Components. THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR THE PERSONAL USE OF A CONSUMER OR OTHER USES IN WHICH IT DOES NOT RECEIVE REMUNERATION TO (i) ENCODE VIDEO IN COMPLIANCE WITH THE AVC STANDARD ( AVC VIDEO ) AND/OR (ii) DECODE AVC VIDEO THAT WAS ENCODED BY A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY OTHER USE. ADDITIONAL INFORMATION MAY BE OBTAINED FROM MPEG LA, L.L.C. SEE Note to Service Provider The product or Hosted Service may use Third Party Components subject to Third Party Terms that do not allow hosting and require a Service Provider to be independently licensed for such purpose. It is your responsibility to obtain such licensing. Preventing Toll Fraud Toll Fraud is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent, subcontractor, or is not working on your company's behalf). Be aware that there can be a risk of Toll Fraud associated with your system and that, if Toll Fraud occurs, it can result in substantial additional charges for your telecommunications services. Avaya Toll Fraud intervention If You suspect that You are being victimized by Toll Fraud and You need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at for the United States and Canada. For additional support telephone numbers, see the Avaya Support website: or such successor site as designated by Avaya. Suspected security vulnerabilities with Avaya products should be reported to Avaya by sending mail to: securityalerts@avaya.com. Trademarks The trademarks, logos and service marks ( Marks ) displayed in this site, the Documentation, Hosted Service(s), and product(s) provided by Avaya are the registered or unregistered Marks of Avaya, its affiliates, or other third parties. Users are not permitted to use such Marks without prior written consent from Avaya or such third party which may own the Mark. Nothing contained in this site, the Documentation, Hosted Service(s) and product(s) should be construed as granting, by implication, estoppel, or otherwise, any license or right in and to the Marks without the express written permission of Avaya or the applicable third party. Avaya is a registered trademark of Avaya Inc. All non-avaya trademarks are the property of their respective owners. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Downloading Documentation For the most current versions of Documentation, see the Avaya Support website: or such successor site as designated by Avaya.

4 Contact Avaya Support See the Avaya Support website: for product or Hosted Service notices and articles, or to report a problem with your Avaya product or Hosted Service. For a list of support telephone numbers and contact addresses, go to the Avaya Support website: (or such successor site as designated by Avaya), scroll to the bottom of the page, and select Contact Avaya Support.

5 Contents Chapter 1: Introduction... 7 Purpose... 7 Intended audience... 7 New in this release... 7 Document changes since last issue... 8 Related resources... 9 Documentation... 9 Training Web sites Viewing Avaya Mentor videos Support Chapter 2: IP Office as an enterprise branch overview Topology Components IP Office branch interoperability Customer requirements Voic options Test strategy summary Chapter 3: Design considerations Caveats and limitations Capacity and scalability Avaya WebLM capacity VCM channels SM trunk channel licenses Voice mail port licenses: Embedded Voic and Voic Pro Migration roadmap and limitations Dial plan considerations Security considerations Chapter 4: Configuration details Network configuration IP Office SIP connection to Avaya Aura Session Manager JRE requirement for client computers Video configuration Packaging and order codes Port assignments Traffic and Quality of Service Quality of Service requirements Bandwidth requirements Bandwidth management December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 5

6 Contents Redundancy and high availability Redundancy and high availability from the Avaya Aura network Redundancy through Rainy day support Appendix A: Call flows Overview of IP Office example call flows Centralized deployment example call flows Routing concepts Call flows Centralized voice mail example call flows Sunny day call flows: Incoming call transferred to Avaya Aura Messaging or Avaya Modular Messaging Rainy day call flows: Incoming call transferred to Avaya Aura Messaging or Avaya Modular Messaging ATA example call flows Centralized ATA phone to IP Office PSTN trunk call flow ATA phone invoking Communication Manager call pick-up feature call flow SRTP example call flows Centralized SIP phone to IP Office PSTN trunk IP Office user with IP phone to headquarters user outside the branch Toll bypass functionality Toll bypass call flows Glossary Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

7 Chapter 1: Introduction Purpose This document provides information about engineering and configuration requirements for the IP Office Branch solution. It describes the IP Office Branch solution architecture, topology, deployment options, and interoperability. This document also describes functional limitations of the solution and customer requirements that are met by the solution. With this information, sales design specialists can make design-related decisions to meet the business needs of a customer. This document briefly describes the features provided by the solution components. For more detailed information about features and functionality, see Avaya IP Office Platform Solution Description ( ). This document does not provide procedures for deploying and administering the solution. Deployment and administration procedures are provided in the IP Office Branch solution Deployment Guides. Related Links Documentation on page 9 Intended audience This document is intended for people who determine the best design to meet a customer s business needs. New in this release The following sections outline what s new in Avaya IP Office Platform in a Branch Environment Reference Configuration, document number : Branch account The branch account has changed from SMGRB5800Admin to BranchAdmin. For more information see, Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager, document number December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 7

8 Introduction Licensing Branch System and SM Trunk Channels are added to the IP Office reserve license configuration for WebLM in IP Office Manager. For more information about licensing that impact IP Office, see the following documents: Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager Security and certificate changes Security and certificate requirements have been implemented in Avaya Aura and IP Office. For more information about security and certificate requirements that impact IP Office, see the following documents: Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager Administering Centralized Users for an IP Office Platform Enterprise Branch Support for E.129 phones and B.179 phones as Centralized users IP Office Branch supports the deployment of E.129 and B.179 phones as Centralized users. You can migrate the existing phone to the branch environment or deploy new phones as Centralized users in the Branch environment. For more information about E.129 and B. 179 phones, see the following documents: Administering Centralized Users for an IP Office Platform Enterprise Branch ATA feature enhancements IP Office Branch now supports additional ATA features on Avaya Aura Communication Manager. IP Office Branch also supports analog fax devices. For more information about the ATA features, see the following documents: Administering Centralized Users for an IP Office Platform Enterprise Branch Avaya IP Office Platform in a Branch Environment Reference Configuration Support for toll bypass Telecom regulations in certain countries do not allow mixing of VoIP and PSTN calls if the source and target call locations are in different toll areas. The toll bypass functionality allows you to overcome the restriction by making IP Office compliant with this regulation. Document changes since last issue The following changes have been made to this document in Release 9.1: Reorganized Rainy Day feature information. Added Rainy Day feature information for E.129 series phones. Added E.129 and B.179 series phones as a supported component. 8 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

9 Related resources Related resources Documentation The following table lists the related documents for the IP Office Branch solution. Download the documents from the Avaya Support website at Document number Overview Title Use this document to Audience Avaya IP Office Platform Solution Description Not numbered IP Office Release 9.0 deployed as a Branch Product Offer Understand IP Office platforms, components, and features. Provides a technical and commercial overview of the IP Office Branch solution IP Office Product Description Understand IP Office systems and requirements. Not numbered Not numbered Reference Configuration Avaya Aura System Manager Overview and Specification Avaya Aura Communication Manager Feature Description and Implementation Avaya IP Office Platform in a Branch Environment Reference Configuration Implementation Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager Understand how System Manager works and the performance specifications for the product Understand how to use and implement Communication Manager features. Understand the architecture and network engineering requirements for the solution Deploy an IP Office enterprise branch Sales Engineers Sales Engineers Reference Architects Solution Architects Sales Engineers Reference Architects Sales Engineers Reference Architects Sales Engineers Reference Architects Solution Architects Reference Architects Solution Architects Sales Engineers Implementation Engineers Solution Architects December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 9

10 Introduction Document number Title Use this document to Audience Deploying IP Office as a Distributed Enterprise Branch in a Communication Server 1000 Environment with Avaya Aura Session Manager Deploying Avaya IP Office Platform IP500/IP500 V2 Not numbered Implementing Avaya Aura System Manager Avaya Application Solutions: IP Telephony Deployment Guide Avaya IP Office Implementing Embedded Voic Avaya IP Office Implementing Voic Pro Not numbered Avaya Port Matrix: IP Office 9.0 (available at support.avaya.com/security under the Avaya Product Port Matrix Documents link) Not numbered Not numbered Administration IP Office: Avaya Radvision Installation Notes Avaya Aura Communication Manager Release 6.2 and Radvision SCOPIA Release 7.7 and 8.0 Interoperability Day 180 Solution Quick Setup Administering Centralized Users for an IP Office Platform Enterprise Branch Migrating an IP Office or B5800 Branch Gateway to an IP Office Enterprise Branch Not numbered Administering Avaya Aura System Manager Deploy an IP Office enterprise branch with CS 1000 Install an IP Office system using an IP500 or IP500 V2 control unit. Implement System Manager and System Platform Understand deployment options and provide overview information Implement Embedded Voic Implement Voic Pro Determine the correct ports to use for the IP Office Branch solution Deploy Radvision endpoints with IP Office Deploy Radvision endpoints in the Avaya Aura infrastructure Add Centralized users to an enterprise branch Understand migration procedures for the IP Office Branch solution Administer System Manager Implementation Engineers Solution Architects Implementation Engineers Solution Architects Implementation Engineers Solution Architects Implementation Engineers Solution Architects Sales Engineers Implementation Engineers Implementation Engineers Implementation Engineers Solution Architects Implementation Engineers Solution Architects Implementation Engineers Solution Architects Implementation Engineers Implementation Engineers Solution Architects Administrators Implementation Engineers Solution Architects 10 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

11 Related resources Document number Title Use this document to Audience Administering Avaya Aura Session Manager Not numbered Avaya IP Office Administering Embedded Voic Avaya IP Office Administering Voic Pro Administer Session Manager Configure Embedded Voic Configure Voic Pro Not numbered Avaya WebLM Administration Guide Administer a WebLM server Not numbered White Papers Not numbered Administering Avaya WebLM (standalone) Avaya IP Voice Quality Network Requirements Administer a standalone WebLM server Understand Avaya network requirements for good voice quality Implementation Engineers Solution Architects Implementation Engineers Implementation Engineers Implementation Engineers Implementation Engineers Solution Architects Reference Architects Sales Engineers Training Obtain the following certifications before deploying or administering the IP Office Branch solution: ASPS Avaya IP Office Deployed as a Branch ACSS Avaya Aura Session Manager and System Manager ACSS Avaya Small and Medium Enterprise (SME) Communications To obtain a certification, you must pass an exam. Each certification you obtain is valid for one year. The following table lists the main IP Office Branch courses you must obtain. For a complete list of courses available for each certification assessment, visit the Avaya Learning web site at Table 1: Courses for IP Office as a Branch Deployment Course code Knowledge Transfers (KTs) 8U00010O Course title Knowledge Access License 5U00130E 5U00130E_TH 5U00130E_ATM 5U00130E_Lab Knowledge Transfer: Avaya IP Office Deployed as a Branch Pre-GA KT Knowledge Access: IP Office Deployed as a Branch Theory Knowledge Access: IP Office Deployed as a Branch Ask the Mentor Knowledge Access: IP Office Deployed as a Branch Practise Lab Workshop December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 11

12 Introduction Web sites Information to support IP Office can be found on a number of web sites. Avaya ( The official web site for Avaya. The front page also provides access to individual Avaya web sites for different countries. Avaya Enterprise Portal ( This is the official web site for all Avaya Business Partners. The site requires registration for a user name and password. Once accessed, the site portal can be individually customized for what products and information types you wish to see and to be notified about by . Avaya Support ( Contains documentation and other support materials for Avaya products. Avaya IP Office Knowledge Base ( Provides access to an on-line regularly updated version of the IP Office Knowledge Base. Avaya University ( This site provides access to the full range of Avaya training courses. That includes both on-line courses, course assessments and access to details of classroom based courses. The site requires users to register in order to provide the user with access to details of their training record. Avaya Community ( This is the official discussion forum for Avaya product users. However it does not include any separate area for discussion of IP Office issues. Other non-avaya Web sites There are several third-party web forums that discuss IP Office. These can be a useful source of information about how IP Office is used. Some of these forums require you to be a member and to register. These are not official Avaya forums and their content is not monitored or sanctioned by Avaya. - Tek-Tips ( - IP Office Info ( - Yahoo Groups ( - PBX Tech ( Viewing Avaya Mentor videos Avaya Mentor videos provide technical content on how to install, configure, and troubleshoot Avaya products. About this task Videos are available on the Avaya Support website, listed under the video document type, and on the Avaya-run channel on YouTube. 12 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

13 Support Procedure To find videos on the Avaya Support website, go to and perform one of the following actions: - In Search, type Avaya Mentor Videos to see a list of the available videos. - In Search, type the product name. On the Search Results page, select Video in the Content Type column on the left. To find the Avaya Mentor videos on YouTube, go to and perform one of the following actions: - Enter a key word or key words in the Search Channel to search for a specific product or topic. - Scroll down Playlists, and click the name of a topic to see the available list of videos posted on the website. Note: Videos are not available for all products. Support Go to the Avaya Support website at for the most up-to-date documentation, product notices, and knowledge articles. You can also search for release notes, downloads, and resolutions to issues. Use the online service request system to create a service request. Chat with live agents to get answers to questions, or request an agent to connect you to a support team if an issue requires additional expertise. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 13

14 Chapter 2: IP Office as an enterprise branch overview You can deploy IP Office as an enterprise branch to provide a communications solution that is adaptable to meet the growing needs of an enterprise branch network while providing investment protection of the installed hardware platform and phones. You can implement an IP Office enterprise branch on an IP Office Standard Mode, Essential, or Preferred system. The IP Office system can be installed as an independent, standalone branch, or be connected to the Avaya Aura network and migrated to a Distributed, Centralized, or Mixed enterprise branch to provide specific features and applications to meet the needs of individual employees in each branch location. In addition to centralized SIP endpoints or centralized analog devices configured as ATA, IP Office can concurrently support other IP and TDM endpoints for a community of Centralized users and IP Office users in the same branch. Ideal for enterprises wanting applications deployed in customer data centers or in the branch itself, an IP Office branch can effectively deliver a range of communication tools without complex infrastructure and administration. See Administering Centralized Users for an IP Office Platform Enterprise Branch for information on how to add Centralized users to an IP Office enterprise branch. IP Office is also supported in an Avaya Communication Server 1000 (CS 1000) branch environment. Only the Distributed enterprise branch option is supported. IP Office can be deployed as a new branch in an existing CS 1000 configuration with the addition of Avaya Aura Session Manager to which IP Office connects through the SM Line for branch connectivity. Providing phone investment protection, it can also be deployed as a replacement for Business Communications Manager (BCM) or Norstar in a branch office and connect to CS 1000 via Avaya Aura Session Manager. IP Office cannot operate as a survivable gateway to CS 1000 endpoints the way that Survivable Remote Gateway (SRG) does. Topology The IP Office Branch solution provides the flexibility to support independent, stand-alone IP Office branches as well as IP Office branches connected to an Avaya Aura system. The Branch solution also supports CS 1000 integration. The following deployment options are available for the solution architecture: Stand-alone IP Office branch option: Independent IP Office systems are deployed within the network. These IP Office systems are not connected to each other or to anything else in the 14 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

15 Topology network. With this option, the IP Office branches are not connected to an Avaya Aura system and users cannot access any Avaya Aura services. Distributed enterprise branch deployment option: All users in this deployment option are IP Office users. These IP Office users obtain telephony services from the local IP Office and not from Avaya Aura. The IP Office systems in this deployment option can be connected to Avaya Aura Session Manager and administrators can obtain Centralized management services through Avaya Aura System Manager. The enterprise can choose to connect IP Office users in this deployment option to an IP Office voice mail system, Embedded Voic or Voic Pro, or a Centralized voice mail system, such as Avaya Aura Messaging or Avaya Modular Messaging. IP Office users in this deployment also have access to some Centralized Avaya Aura applications and services. With the Distributed branch deployment option, you can also connect CS 1000 to the IP Office in the branch through Avaya Aura Session Manager. Users still obtain telephony services from the local IP Office, but can use Avaya CallPilot as their voice mail system. When connected to CS 1000, the IP Office and CS 1000 interoperate as peers through Avaya Aura Session Manager. Centralized enterprise branch deployment option: All users in the enterprise are Centralized users. Centralized users register to Avaya Aura Session Manager and obtain telephony services from the Avaya Aura Communication Manager Feature Server or Evolution Server in the enterprise core. If WAN connectivity to the Avaya Aura Session Manager is lost, the user automatically gets basic telephony services from the local IP Office. The telephony features provided by the IP Office in survivability mode is limited compared to the features that are normally provided to the Centralized phone. Centralized users must be configured on the Avaya Aura Session Manager, Communication Manager, and IP Office. A Centralized user must be configured on the Avaya Aura Session Manager and Avaya Aura Communication Manager as a SIP user. On the IP Office, the Centralized user must have either a SIP extension, an analog extension, or an analog fax device. Table 2: Documentation terminology This table shows the terminology used in the IP Office Branch documentation for Centralized users with SIP and analog extensions. Terminology used Centralized SIP user ATA user Definition Centralized user in the IP Office Branch with a SIP extension. Centralized user in the IP Office Branch with an analog extension or an analog fax device. Mixed enterprise branch deployment option: An enterprise branch with both Centralized users and IP Office users. Centralized users and IP Office users obtain the same telephony services described above. All users in this deployment option must use a Centralized voice mail system: Avaya Aura Messaging or Avaya Modular Messaging. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 15

16 IP Office as an enterprise branch overview The deployment options in the Branch solution allow you to start off with stand-alone IP Office systems and then slowly evolve the solution architecture into a Centralized environment as your enterprise grows. The following image shows the topology of the solution architecture with the deployment options described above. This image does not show CS 1000 in the Distributed branch deployment. Figure 1: Topology of solution architecture Related Links Components on page 16 Redundancy and high availability on page 52 Components The following table briefly describes the components in the IP Office Branch solution and how these components fit into the Branch architecture. Some of these components are only implemented in certain branch deployment environments. 16 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

17 Components Table 3: Branch components Component IP Office Main Avaya Aura network CS 1000 Reference Configuration Characteristics Includes hardware and software components. In this solution, there is an IP Office in each branch. IP Office systems can be deployed as stand-alone branches or connected to an Avaya Aura network. Avaya Aura provides access to centralized services. Avaya Aura System Manager provides administrative functions that administrators can use to easily manage all users and IP Office systems in the enterprise. In a Distributed, Mixed, or Centralized environment, IP Office branches are connected to the Avaya Aura System Manager server. Note: Avaya Aura System Manager does not manage the following applications: Voic Pro, Avaya one-x Portal for IP Office, CCR, and Unified Communications Module. Avaya Aura Session Manager connects branches to each other and to other applications and services in the enterprise center. For IP Office users in Distributed and Mixed deployment environments, Avaya Aura Session Manager acts as a SIP proxy to route SIP sessions to and from the SIP connections to the IP Office. For centralized users, Avaya Aura Session Manager is also the main interface that handles user registration and call routing. Avaya Aura Communication Manager provides telephony services to centralized users through Avaya Aura Session Manager. Avaya WebLM is included within the Avaya Aura System Manager and provides centralized licensing management. Secure Access Link (SAL) provides remote access and alarm reception capabilities. The SAL Gateway is installed on a Red Hat Enterprise Linux host in the customer network and acts as an agent on behalf of several managed elements. All communication is outbound from the environment of the customer and uses encapsulated Hypertext Transfer Protocol Secure (HTTPS). Other centralized services such as conferencing and messaging are available to centralized users. Some of these services are also available to IP Office users deployed in Distributed and Mixed branch environments. For more information about applications that interoperate with the IP Office branch, see IP Office branch interoperability in Avaya IP Office Platform in a Branch Environment Reference Configuration. In a Distributed branch environment, you can connect CS 1000 to the IP Office in the branch through Avaya Aura Session Manager. Users still obtain telephony services from the local IP Office, but can use Avaya CallPilot as their voice mail system. The CS 1000 provides telephony interoperability between IP Office users in the branch and CS 1000 users at other sites. Avaya Aura System Manager is used to centrally manage CS December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 17

18 IP Office as an enterprise branch overview Component Reference Configuration Characteristics In branch deployments with CS 1000, all IP Office endpoints are supported. Some CS 1000 endpoints can also be migrated to IP Office endpoints. For more information about supported endpoints, see the following documents: Deploying Avaya IP Office Platform IP500/IP500 V2 ( ) Deploying IP Office Platform as a Distributed Enterprise Branch in a Communication Server 1000 Environment with Avaya Aura Session Manager ( ) Important: IP Office does not support Meridian Customer Defined Networking (MCDN), but all major Branch features, including dial plans and centralized voice mail, are supported in Distributed branch environments with CS Supported endpoints All IP Office endpoints are supported as IP Office users. For a list of IP Office endpoints, see phones in Deploying Avaya IP Office Platform IP500/IP500 V2 ( ). The following SIP endpoints are supported as Centralized users. For information about centralized phones and adding Centralized users to an enterprise branch, see Administering Centralized Users for an IP Office Platform Enterprise Branch ( ) SIP SIP SIP SIP SIP SIP G SIP G SIP G SIP Avaya one-x Communicator SIP 6.2 (audio only) Note: The 9600 series SIP phones and Avaya one-x Communicator SIP are supported only as Centralized phones for use by Centralized users. They are not supported as IP Office phones for use by IP Office users. The 1100 and 1200 series phones are supported as IP Office users or as Centralized users. E.129 series phones are supported as IP Office users or as Centralized users. B.179 series phones are supported as IP Office users or as Centralized users. 18 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

19 Components Component Reference Configuration Characteristics IP Office Branch also supports video endpoints connected to IP Office or to the Avaya Aura infrastructure. Related Links IP Office branch interoperability on page 19 Video configuration on page 40 IP Office branch interoperability The IP Office in the branch can interoperate with other applications and services. For more information about IP Office branch interoperability, see Index.aspx. Centralized SIP users in the branch connect directly to Avaya Aura Session Manager in sunny-day and have full access to all central applications and services that the Avaya Aura solution provides to SIP users. IP Office users in the branch cannot access all the features provided through the Avaya Aura solution. Users in a stand-alone IP Office branch deployment do not have access to any of the centralized applications and services. Differences in service for IP Office users and Centralized users IP Office users and Centralized users cannot access all of the services offered through the products listed above. The following table describes the services available to the different users. Products Avaya Aura Session Manager Avaya Aura Conferencing Description Used by Centralized users and IP Office users, but plays an enhanced role for Centralized users. For Centralized users, Session Manager is the main interface that handles user registration and call routing. Avaya Aura Conferencing services can be accessed by IP Office users and Centralized users, but certain services are not available to IP Office users. IP Office users can dial in to an Avaya Aura Conferencing bridge and be participants in an Avaya Aura ad hoc conference. However, IP Office users cannot initiate ad-hoc Avaya Aura conferences or perform conference control functions. Avaya Aura Call Center Elite Avaya Aura Presence Services IP Office users cannot have agent roles. Only Centralized users can perform agent roles within the branch. In Sunny day, the Centralized user is registered to Session Manager and has full agent access. In Rainy day, the Centralized user in the branch is unavailable and no longer accessible to the Avaya Call Center. The Centralized user s phone registers to the IP Office in Rainy day and obtains access to the survivable telephony features supported by IP Office. When Sunny day returns, the Centralized user will reregister to Session Manager and again be available to the Avaya Call Center. Centralized users can use Avaya Aura Presence Services. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 19

20 IP Office as an enterprise branch overview Products Avaya Aura Messaging Lync Integration client plug-in Description IP Office users cannot use Avaya Aura Presence Services. IP Office can only use IP Office Presence, which requires Avaya one-x Portal to be deployed in each branch on Unified Communications Module or on an external server. No interaction is currently supported between IP Office and Avaya Aura Presence Services. When the connection to the Avaya Aura network is down, the Message Waiting Indicator button does not light up to indicate a new message. When the connection to the Avaya Aura network is restored, the Message Waiting Indicator continues working as expected for Centralized users. However, for IP Office users, the Avaya Aura Messaging server does not refresh immediately so even after the connection to the Avaya Aura network is restored, the Message Waiting Indicator does not light up immediately to indicate a new message. The IP Office Lync Integration client plug-in is available to IP Office users. It requires Avaya one-x Portal to be installed in each branch on a Unified Communications Module or an external server. The IP Office Lync Integration client plug-in cannot be used by Centralized users. Centralized users in sunny-day can use ACA R6.3, which supports integration with the Avaya SIP phones using Session Manager. This sunny-day support does not involve IP Office. In rainy-day, when the branch loses connection to the center, the Lync integration of the Centralized users through ACA R6.3 will not be available. CS 1000 and Avaya CallPilot Radvision Scopia Only available in a distributed branch deployment connected to CS With this option, IP Office users can use Avaya CallPilot as their voice mail system. Radvision Endpoints are video endpoints for IP Office. Using this option, IP Office devices can join or dail out from a meeting. NAT Firewall traversal is offered to enable outside to/from inside video calls. This enables Internet based endpoints to make calls to video endpoints or meeting rooms in a company network. The Elite MCU series supported with IP Office are Elite 5100 MCU Series and Elite 5200 MCU Series. AvayaSession Border Controller R6.3 This is applicable to Distributed, Mixed, and Centralized branch deployments and includes the following types of calls: Local SIP trunk - Session Border Controller - IP Office - IP Office user Local SIP trunk - Session Border Controller - IP Office - Session Manager - Centralized users (in sunny-day) Local SIP trunk - Session Border Controller - IP Office - Centralized users (in rainy-day) Local SIP trunk - Session Border Controller - IP Office - Session Manager - users in headquarters or other enterprise sites 20 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

21 Customer requirements Products Description Central SIP trunk - Session Border Controller - Session Manager - IP Office - IP Office user Central SIP trunk - Session Border Controller - Session Manager - Centralized users IP Office remote worker - Session Border Controller - IP Office - Session Manager - users in headquarters or in other enterprise sites IP Office remote worker - Session Border Controller - IP Office - Session Manager - Centralized users in a Mixed branch (in sunnyday) IP Office remote worker - Session Border Controller - IP Office - Centralized users in a Mixed branch (in rainy-day) IP Office remote worker - Session Border Controller - IP Office - Session Manager - voic services on Avaya Aura Messaging/ Modular Messaging. Avaya Aura remote worker - Session Border Controller - Session Manager - IP Office - IP Office user Avaya BCM R6.0 Avaya Aura Experience Portal R7.0 Voice Portal R5.1 Avaya Aura Communication Manager R6.3.8 This enhancement positions IP Office as a SIP gateway between BCM and an Session Manager. IP Office is only supported within the Feature Pack 4 System Manager. Provides only basic connectivity support with IP Office. IP Office is only supported within the Feature Pack 4 System Manager. Customer requirements The IP Office Branch solution supports the following customer requirements: Flexible deployment options with autonomous IP Office branches as well as Distributed, Mixed, and Centralized Branch environments. Support for multiple voic options depending on the deployment model. Freedom to evolve to different deployment phases as the needs of your enterprise change. You do not have to follow the evolution phases in any particular order. For more information about evolution phases, see Avaya IP Office Platform Solution Description ( ). The flexible deployment options offered with the architecture provide guaranteed investment protection within the hardware platform and phones. Centralized management services available in Distributed, Mixed, and Centralized Branch environments with the Avaya Aura network. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 21

22 IP Office as an enterprise branch overview Access to PSTN trunking and a variety of other services, such as messaging and conferencing, for centralized users with the Avaya Aura network. IP Office users in the Distributed and Mixed Branch environment can also access some of these services. Support for CS 1000 configurations connected to the IP Office in the branch with Avaya Aura Session Manager. This provides telephony interoperability and phone investment protection. Support for the Rainy day mode, guaranteeing that centralized users still have access to telephony services through IP Office when the WAN connection between the branch and the enterprise center is down or if the core Avaya Aura server is down. Related Links Topology on page 14 IP Office branch interoperability on page 19 Voic options The following IP Office voic options are supported: Local voic options IP Office systems deployed as Distributed or stand-alone enterprise branches can be configured to use the following local voice mail options: Embedded Voic Embedded Voic is the IP Office default voic option. It uses the system SD card in the IP Office system control unit for storage of prompts and messages. Embedded Voic supports mailboxes for all local extension numbers, announcements to waiting callers, and auto attendants (up to 40) for external calls. The capacity is limited to 15 hours of recorded messages, prompts and announcements. Voic Pro Voic Pro runs on an external server PC connected to IP Office or on Unified Communications Module and provides a wide range of features. Voic Pro supports 40 voice channels, which includes: Message/greeting recording Message playing System/custom IVR prompt playing Call recording and prompt playing to outcalls made from Voic Pro Mailbox messages, greetings, recordings, and announcements are stored locally on Unified Communications Module or on a standalone computer where Voic Pro is running. Management of the Voic Pro call flows in the branches can be done from a remote central Voic Pro client. Use of the Voic Pro client to remotely manage the calls flows is available only when Voic Pro is running on an external server, not when it is deployed on Unified Communications Module. The Voic Pro client can also connect to Voic Pro that runs the Unified Communications Module server and can therefore, be used in the management. For enterprise branch deployments with multple Voic Pro servers, the Voic Pro client provides an export or import feature that allows the same Voic Pro configuration including call flows to be deployed on multiple Voic Pro servers. 22 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

23 Customer requirements Note: If the IP Office 500v2 systems are present in the enterprise deployment with System Manager, you can manage Voic Pro callflow. For more information, see Configuring Voic Pro from System Manager in Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager. Voic Pro is the only option that supports manual call recording for IP Office users and automatic call recording for the IP Office system. Note: If security of signaling links is a concern, the Voic Pro application should run on a coresident Unified Communications Module blade. Security enhancements such as TLS are not applicable to links with external servers running Voic Pro. You can now manage Voic Pro from Avaya Aura System Manager. The local voic options can be configured only in Distributed enterprise branch deployments where there are only IP Office users. They cannot be configured in Centralized or Mixed enterprise branch deployments with Centralized users. Only one type of voic system can be configured for an IP Office branch. This does not preclude the use of local auto-attendant in Centralized or Mixed enterprise branch deployments. Centralized voic options IP Office systems deployed in Distributed, Mixed, or Centralized enterprise branch environments can be configured to use the following Centralized voic options. Stand-alone branches cannot use Centralized voic systems. Avaya Aura Messaging An IP Office system can be configured to use Avaya Aura Messaging as its voic server when Session Manager is used as the core SIP router. Modular Messaging An IP Office system can be configured to use Modular Messaging as its voic server when Session Manager is used as the core SIP router. CallPilot An IP Office system deployed as a Distributed enterprise branch in a Avaya Communication Server 1000 branch environment can be configured to use Avaya CallPilot as the voic system. In this deployment, the Distributed enterprise branch configuration includes Session Manager as part of the CS 1000 core. All users in this configuration are IP Office users. When a central voic system is configured for the branch, the mailboxes of the branch users are on the central voic system. However, you still have the option to use the automated attendant of the IP Office local Embedded Voic or the call flows of a local Voic Pro, even though the embedded voic or Voic Pro are not used for the voic messages of the branch users. Note that this configuration requires the use of Embedded Voic or Voic Pro port licenses. If the configuration requires more ports than the number of ports that are licensed and come with the IP Office system, additional port licenses are required. When Messaging or Modular Messaging is used as the central voic system, IP Office users and Centralized users in Rainy day can leave and retrieve voic over the PSTN when the SM Lines are unavailable. DTMF digits are used to indicate a specific mailbox. Message Waiting Indication is not provided. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 23

24 IP Office as an enterprise branch overview Test strategy summary Avaya conducted thorough Solution Verification (SV) testing for all the features available in the Branch deployment options and for IP Office interoperability with CS 1000 and major Avaya Aura components. Once the SV testing was complete, Avaya Solution and Interoperability (SIL) teams also re-tested features, interoperability, failover, and deployment to ensure solution stability and resolve any remaining issues. This topic describes the Avaya Solution and Interoperability test strategy for the IP Office Branch solution in distributed, mixed, and centralized enviroments connected to the Avaya Aura infrastructure. Avaya did not conduct any separate tests as part of this solution for stand-alone IP Office branch deployments. Stand-alone IP Office branches operate in the same way as the standard IP Office system. The goal of the Avaya Solution and Interoperability tests conducted was to achieve solution stability for: Installation, configuration, and maintenance Feature functionality in all test conditions as well as in standard and stretched network conditions Failover and failback scenarios 24 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

25 Chapter 3: Design considerations Caveats and limitations The following general caveats and limitations exist for the Avaya IP Office Branch solution. Solution not supported in all IP Office editions Branch functionality is supported in IP Office Essential and Preferred Editions. The following limitations exist for branch support in other IP Office editions. The IP Office Basic Edition does not support branch functionality. The IP Office Server Edition is not positioned as a branch edition. The Server Edition had the ability to support certain call features and interoperability with the following products using SIP through an SM Line interface: - Avaya Aura Session Manager - Avaya Aura Communication Manager or Avaya Communication Server 1000 through the Session Manager However, the Server Edition does not support the following centralized services available in Branch: - Centralized management through Avaya Aura System Manager - Centralized licensing through Avaya WebLM - Centralized users - Centralized voice mail over the SM Line Co-existence of Branch functionality with the IP Office Small Community Network (SCN) is also limited. SCN can connect to the Session Manager through the SM Line. However SCN does not support centralized users, centralized voice mail over the SM Line, centralized management through System Manager, and centralized licensing through Avaya WebLM. IP Office Branch positioning with Avaya Aura IP Office is not an H.248 gateway under the control of Communication Manager.IP Office is a telephony system and SIP gateway connected through SIP to Session Manager. IP Office as a Branch solution has the following limitations: A Session Manager and SIP gateway solution with IP Office Branch does not support the Communication Manager Inter-Gateway Alternate Routing (IGAR) feature. Communication Manager cannot directly control the media resources of the IP Office. In Sunny day mode, Communication Manager based media services, such as conferencing and Music on Hold, deliver media to the branch from a central Communication Manager gateway resource. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 25

26 Design considerations IP Office administration When System Manager is configured to centrally manage IP Office systems, you cannot use the IP Office Manager to administer the IP Office systems. If you need to administer the IP Office using the IP Office Manager that is directly connected to the branch, you must first disable the System Manager administration feature for the Branch. For more information, see Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager ( ). User functionality Mixed enterprise branch deployments support both Centralized users and IP Office users. Centralized users obtain telephony services from the Avaya Aura Communication Manager Feature or Evolution Serve in the enterprise core, and IP Office users obtain telephony services from the local IP Office. As a result, when the Mixed enterprise branch is deployed, the IT department should identify and record which telephones are associated with a Centralized user experience and which telephones are associated with an IP Office user experience. No support for Communication Manager Messaging The IP Office Branch solution does not support Communication Manager Messaging. Avaya Aura Messaging and Avaya Modular Messaging are supported as Centralized voice mail systems. One voice mail type per branch IP Office only supports one voice mail type for all users in the same branch. In a Mixed branch with both IP Office users and Centralized users, all users must use a Centralized voice mail system. IP Office users in the Mixed branch do not have the option of selecting a local IP Office voice mail system and 1200 series phones deployed as Centralized users Ensure that the 1100 and 1200 series phones within a branch are all Centralized or all IP Office users, otherwise you must configure each phone manually. In the Rainy day mode, direct media with SRTP is not supported. In this scenario, media is anchored on IP Office. The address book feature of the phone varies for different servers. Hence, the contacts added to the phones while the phones are connected to Session Manager are unavailable when the phones are connected to IP Office, and vice versa. Install the security certificate manually. You must accept the authorization prompts from the phones to go ahead and install the certificate. If you do not provide any input, then the certificate does not get installed and 1200 series phones support only two servers. You can deploy this phone as Centralized users in branches that connect to a single Session Manager and configure it with the local branch IP Office as the secondary server. However, you cannot deploy this phone as Centralized users in a branch that is configured to two Session Manager. If there are Centralized 1100 series or 1200 series phones in the branch, then you must not configure the IP Office and other Centralized phones in that branch to two Session Manager. If you configure the IP Office with two Session Manager, then the Centralized 1100 series and 1200 series phones will receive no service. This occurs if the primary Session Manager is down and the secondary Session Manager is still reachable from the IP Office. The Centralized 1100 series and 1200 series phones will not be able to register to the IP Office that will still be in Sunny day mode. 26 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

27 Capacity and scalability E.129 series phones deployed as Centralized users Only one address book exists, and is shared between the Sunny Day and Rainy Day modes. Some address book entries might not work if there is no route to the destination. For example, routes that require Session Manager do not work in Rainy Day. E.129 series phones support a primary and a secondary call server, but not explicit fallback server. Therefore, to support the use of IP Office as a rainy-day fallback server, only one session manager can be configured on the primary call back server. The secondary call back server is used to identify IP Office. For example, in an Avaya Aura only deployment, use the secondary server for a second session manager. You must use IP addresses, not FQDNs, between the primary Avaya Aura and secondary IP Office servers. E.129 series phones support only one dial plan. This is generally the Avaya Aura dial plan and not the IP Office dial plan. Ensure that the E.129 series phones within a branch are all Centralized or all IP Office users, otherwise you must configure each phone manually. E.129 series phones support only two servers. You can deploy this phone as Centralized users in branches that connect to a single Session Manager and configure it with the local branch IP Office as the secondary server. However, you cannot deploy this phone as Centralized users in a branch that is configured to two Session Manager. If there are Centralized E.129 series phones in the branch, then you must not configure the IP Office and other Centralized phones in that branch to two Session Manager. If you configure the IP Office with two Session Manager, then the Centralized E.129 series phones will receive no service. This occurs if the primary Session Manager is down and the secondary Session Manager is still reachable from the IP Office. The Centralized E.129 series phones will not be able to register to the IP Office that will still be in Sunny day mode. B.179 series phones deployed as Centralized users IP Office deployed as a Branch supports B.179 R2.4 phones as Centralized users. The configuration of the Centralized B.179 phone is done through the phone s built-in configuration tool that is available through a web browser and not through a configuration file. The B.179 phone does not support manual failback. Therefore, when a deployment includes a B.179 phone as a Centralized User, the failback policy must be automatic. Capacity and scalability The IP Office Branch solution is flexible and scalable to meet the needs of small, medium, and large enterprises. You can also evolve the architecture of the solution as your enterprise grows. The following table defines general capacity information for all deployment options in the IP Office Branch solution. See the IP Office Knowledge Base for detailed capacity information. For a list of the maximum capacity limits for each Avaya Aura System Manager in the solution, see Performance specifications in Avaya Aura System Manager Overview and Specification. System Manager limits only apply if your solution uses a Distributed, Mixed, or Centralized deployment connected to the Avaya Aura infrastructure. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 27

28 Design considerations Table 4: IP Office Branch general capacity information Description Number of users Number of branches Number of SIP sessions Number of trunks and channels IP Office voice mail Capacity Solution is ideal for a small or large number of users. Up to 384 users can be deployed on each IP Office branch, and up to users can be deployed on Avaya Aura System Manager. Up to 2000 IP Office branches can be connected to an Avaya Aura Session Manager. Up to 2000 Unified Communications Module or Application Server can also be supported in addition to the 2000 IP Office branches. The IP Office Branch solution is not limited to 250 gateways per Communication Manager. Up to 128 calls signalled through SIP are supported between the IP Office branch and the Avaya Aura Session Manager. The Branch solution supports up to: 16 analog trunks 16 ISDN BRI trunks (32 channels) 8 digital PRI trunks (up to 192 T1 channels or 240 E1 channels) The IP Office system uses Embedded Voic by default. Embedded Voic supports up to: 6 ports 40 auto-attendants 15 hours of recorded messages, prompts, and announcements. With the IP Office Preferred or Advanced editions, Voic Pro is also supported. The Voic Pro system supports up to 40 ports. The capacity information presented in Table 4: IP Office Branch general capacity information on page 28 describes general maximums supported by the IP Office system, but these maximums are not automatically available to all enterprises that purchase IP Office systems. You must obtain licenses and hardware modules to deploy VCM channels, SIP sessions to and from Avaya Aura Session Manager, and voice mail ports (if applicable). Use the information in the following sections to calculate what you need to obtain to meet the branch requirements for your enterprise. Avaya WebLM capacity The Avaya WebLM on the Avaya Aura System Manager supports licensing of up to 2000 IP Office branches from Avaya Aura Release 6.2 Feature Pack 3 onwards. Note: The previous releases of the WebLM server, prior to Avaya Aura 6.2 Feature Pack 3 has limited capacity. The server could handle approximately 300 to 400 IP Office systems in a 28 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

29 Capacity and scalability typical Branch deployment. The number depends on the server load and on the number of different license types requested by the IP Office systems. If your deployment has a large number of branches, then you must upgrade your System Manager to Avaya Aura Release 6.2 Feature Pack 3 or later. VCM channels IP Office uses voice compression modules (VCMs) to convert media traffic between IP and TDM. Some examples of when VCM channels are required in the branch are: Each call between an IP endpoint or trunk and a TDM endpoint or trunk Each call between an IP Office analog or digital endpoint and a device behind the SM Line, including calls to phones in other sites, centralized phones within the branch, and centralized trunks or voice mail systems through the Avaya Aura Session Manager Each call between an IP Office ISDN or analog PSTN trunk and a device behind the SM Line, including calls between centralized SIP users within the branch local ISDN or analog PSTN trunks. Calls between IP Office users with IP endpoints and entities behind the SM Line are considered IP device to IP device calls. These calls do not typically require VCM channels unless no common codec can be selected on the two sides. The following table describes general usage of VCM channels within IP Office environments. Call type IP device to non-ip device IP device to IP device Non-IP device to non-ip device Music on Hold Voice compression channel usage These calls require a voice compression channel for the duration of the call. If no channel is available, busy indication is returned to the caller. Call progress tones (for example dial tone, secondary dial tone, etc) do not require voice compression channels with the following exceptions: Short code confirmation, ARS camp on and account code entry tones require a voice compression channel. Devices using G723 require a voice compression channel for all tones except call waiting. When a call is connected: If the IP devices use the same audio codec no voice compression channel is used. If the devices use differing audio codecs, a voice compression channel is required for each. No voice compression channels are required. This is provided from the IP Office TDM bus and therefore requires a voice compression channel when played to an IP device. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 29

30 Design considerations Call type Conference resources and IP devices Page calls to IP device Voic services and IP devices T38 fax calls Voice compression channel usage Conferencing resources are managed by the conference chip which is on the IP Office TDM bus. Therefore, a voice compression channel is required for each IP device involved in a conference. This includes services that use conference resources such as call listen, intrusion, call recording and silent monitoring. IP Office 4.0 and higher uses only G729a for page calls, therefore only requiring one channel. Only pages to G729a capable devices are supported. Calls to the IP Office voic servers are treated as data calls from the TDM bus. Therefore calls from an IP device to an IP Office voic system require a voice compression channel. This does not apply to central voice mail systems over the SM line. In order to use T38 fax connection, fax tone detection is performed if the analog extension connected to the fax machine is set as Standard telephone. If the fax machine does not include an attached handset that is used to make/receive voice calls, then the Equipment Classification of an analog extension connected to the fax machine can be set to Fax Machine, which will result in T38 fax connection without fax tone detection and respective signaling renegotiation. Additionally, a new short code feature, Dial Fax, is available. Note: T3 IP devices must be configured to 20ms packet size for the above conditions to apply. If left configured for 10ms packet size, a voice compression channel is needed for all tones and for non-direct media calls. Measuring channel usage The IP Office System Status Application can be used to display voice compression channel usage. Within the Resources section it displays the number of channels in use. It also displays how often there have been insufficient channels available and the last time such an event occurred. For the VCM cards, the level of channel usage is also indicated by the LEDs (1 to 8) on the front of the VCM card. Calculation guidelines On the IP Office, you can configure the following number of VCM modules: Up to 2 optional VCM 32 modules or VCM 64 modules, providing 32 and 64 VCM channels each Up to 2 combination cards, providing 10 VCM channels each With 4 modules, the maximum VCM channel capacity is 148. The calculation of how many VCM channels are required in a particular deployment depends on the type and number of phones in the branch, the types of trunks used, the traffic patterns or typical call flows, as well as typical call frequency and length. For example, if most phones are centralized SIP phones and most calls are made to local ISDN or analog PSTN trunks, then VCM channels will be needed for most calls. However, VCM channels will not be needed as often if most phones are analog or digital phones and most calls are made to local ISDN or analog PSTN trunks. 30 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

31 Capacity and scalability As a general rule, the number of required VCM channels is equivalent to the number of IP Office IP phones (not including centralized phones) divided by three, plus the number of SIP trunk channels used for simultaneous calls over the SM Line. However, this calculation rule can vary depending on the deployment and traffic patterns of the enterprise. SM trunk channel licenses You must obtain a SM trunk channel license for each simultaneous SIP sessions to the Session Manager or call required in your IP Office branch. For example, if your system needs to support 5 simultaneous SIP sessions, you must obtain 5 SM trunk channel licenses. Calls over the SM trunk use only SM trunk channel licenses. Regardless of the call media, an SM trunk channel license is required for each call with signaling over the SM Line. Examples of calls over the SM Line include: Calls between an IP Office user and a device behind the SM Line. This includes calls to users in other sites, to centralized users within the branch in sunny-day, and centralized trunks or voice mail through Avaya Aura Session Manager Calls between an IP Office PSTN trunk and a device behind the SM Line Calculation guidelines The calculation of how many SM trunk channel licenses are required depends on the expected traffic patterns in the enterprise deployment. If your deployment uses Avaya WebLM, the number of SM trunk channel licenses required by the IP Office must be specified in the IP Office licensing configuration. The ratio of the average number of users to each SM trunk channel license must be calculated based on traffic patterns and media call flows. Do not assume that the user to license ratio needs to be 1 to 1. To determine the appropriate ratio, look at patterns such as the average number of SIP calls over the SM Line, the call duration, and the destination of incoming calls. Related Links IP Office SIP connection to Avaya Aura Session Manager on page 38 Voice mail port licenses: Embedded Voic and Voic Pro You must obtain a voice mail port license for each simultaneous call you want to allow to your IP Office voice mail system (Embedded Voic or Voic Pro). Voice mail port licenses for Embedded Voic are required in the following two cases: Branch users use Embedded Voic as their voice mail system. Branch users use a centralized voice mail system through Avaya Aura Session Manager (Avaya Aura Messaging, Modular Messaging, or CallPilot ), but use Embedded Voic for auto-attendant features and announcements. Voice mail port licenses for Voic Pro are required in the following two cases: Branch users use Voic Pro as their voice mail system. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 31

32 Design considerations Branch users use a centralized voice mail system through Avaya Aura Session Manager (Avaya Aura Messaging, Modular Messaging, or CallPilot ), but use Voic Pro for local call flow processing. Calculation guidelines The following table provides information about: The number of voice mail ports provided as entitlements with the IP Office Essential, Preferred, and Advanced packages. The maximum number of ports that can be deployed on IP Office voice mail systems. Table 5: Ports entitlements with IP Office package editions Ports provided as entitlements IP Office Essential edition IP Office Preferred and Advanced editions 2 ports provided as entitlements 4 ports provided as entitlements Table 6: Maximum number of ports supported with IP Office voice mail systems Maximum number of ports supported Embedded Voic Voic Pro up to 6 ports up to 40 ports If the enterprise deployment uses Avaya WebLM licensing, the required number of IP Office voice mail port licenses for Embedded Voic or Voic Pro must be specified in the IP Office licensing configuration. Migration roadmap and limitations You can upgrade from a B5800 Branch Gateway to the current release of IP Office, or from a previous release of IP Office to the current release of IP Office. The upgrade process for the IP Office Branch solution varies depending on how the architecture is deployed. If the B5800 Branch Gateway or IP Office release you are upgrading from is connected to the Avaya Aura infrastructure and uses Avaya Aura System Manager for centralized management, use Avaya Aura System Manager to upgrade the firmware and software for the system. If the architecture is deployed in a stand-alone IP Office branch environment with no centralization or connection to the Avaya Aura network, you must use IP Office Manager for upgrades. From IP Office Manager, you can perform an upgrade using the upgrade wizard or the System SD card. For procedures on how to perform System Manager or IP Office Manager upgrades for your Branch solution, see Migrating an IP Office or B5800 Branch Gateway to an IP Office Enterprise Branch ( ). 32 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

33 Dial plan considerations Dial plan considerations A uniform dial plan greatly simplifies configuration, management and phone calls within the network branch sites. For example, if each branch has similar roles such as reception, manager and warehouse, using the same extension number for each role and a unique prefix for each branch allows calls between sites with little need for directory lookups. It also means a standard configuration can be used at branches which simplifies installation, user training and maintenance. IP Office supports dial plans comprised of the branch prefix and local number length for IP Office users and enterprise-wide extensions for Centralized users. Branch prefix and local number length for IP Office users Dial plans comprised of the branch prefix and local number length for IP Office users should not exceed 15 digits. The Branch Prefix field and the Local Number Length field appear in IP Office Manager under System > Telephony > SM tab. The branch prefix enables IP Office users to have short extension numbers within the local branch but appear to the rest of the enterprise to have unique full enterprise-wide numbers in enterprise canonical format. If a number is configured in the Branch Prefix field, it causes automatic conversion of the IP Office users extension numbers in calls to and from the SM Line. The branch prefix is added as a prefix to the IP Office user s extension number when it appears as the calling number in calls sent to the SM Line. Similarly, it is added to the extension number when it appears in Diversion-Header or History-Info in calls sent over the SM Line to centralized voic . In calls received from the SM Line, if the called number starts with the branch prefix, the prefix is removed and the IP Office will try to target the remaining number locally, to a non-centralized extension or hunt group. If there is no match, IP Office will target it to any matching system short code. If the called number does not start with the branch prefix, the whole number is checked for a match against system short codes. Centralized users (SIP or ATA) can call local IP Office users in the same branch by dialing the full enterprise number composed of the branch prefix plus local extension number, and IP Office will remove the branch prefix and target the local extension. This may be needed if short-form dialing is not set up on the centralized Avaya Aura Communication Manager for Sunny day and the Centralized users are accustomed to dialing the full number. IP Office users cannot call other local IP Office users in the same branch by dialing the full enterprise number composed of the branch prefix plus local extension number. Note: This could be enabled in Sunny day if there is a short code in the IP Office configuration that matches the branch prefix and routes it to the SM Line. But it cannot be enabled in Rainy day. Users should not be instructed to dial differently in Sunny day and Rainy day. Therefore, enabling IP Office users to be able to call other local IP Office users in the same branch by dialing the full enterprise number should not be enabled for Sunny day. When a call is made by any source on the IP Office system and short code matching targets the SM Line, if the target (the dialed number) starts with the branch prefix, the branch prefix is removed and the call is targeted locally. This does not apply if the target is the extension number of a Centralized user or Centralized group configured on the IP Office. In this case, the call is handled as specified below and in Sunny day it will be sent to Session Manager. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 33

34 Design considerations The branch prefix is expected to be used in Distributed enterprise branch deployments and it is expected to be left blank in Centralized enterprise branch deployments. In Mixed enterprise branch deployments, the branch prefix can be left blank or used. If left blank, the IP Office users extension numbers will have to be the full enterprise number. If used, the IP Office users extension numbers will be shorter than the Centralized users extension numbers. The Local Number Length field sets the default length for extension numbers. If an extension number of a different length is configured, a warning appears. The Local Number Length field can be left blank. In Mixed enterprise branch deployments, if the Branch Prefix field is not blank, and the Centralized users and IP Office users have extension numbers of different lengths, then it is recommended to leave the Local Number Length field blank. Enterprise-wide extensions for Centralized users The extension number configured on IP Office for the Centralized user is the user s enterprise-wide number. This is the same number that is configured for that user on Session Manager, which is the number that the centralized phone uses when registering to Session Manager in Sunny day and when registering to IP Office in Rainy day. Centralized users extension numbers can be up to 13 digits in length. (Note that IP Office users extensions can be up to 9 digits in length.) Note: Although IP Office deployed as a Centralized branch supports extension numbers up to 15 digits, the 13-digit length is determined by the maximum extension number length allowed for provisioning Centralized users in Communication Manager. The IP Office Branch Prefix field, which causes number modifications for IP Office users extension numbers, does not impact Centralized users extension numbers when they appear as calling number or as called number. Centralized users may have extension numbers that are not related to the local IP Office branch prefix or numbers that begin with the same digits as the IP Office branch prefix. If Centralized users have extension numbers that begin with the same digits as the IP Office branch prefix, the Centralized users extension numbers look like the IP Office users extension numbers to the rest of the enterprise. This enables users to keep their numbers when migrating from a Distributed enterprise branch to a Centralized enterprise branch. Targeting/routing to Centralized users Calls to centralized users, which can arrive from different sources, are sent to the SM Line in Sunny day and are targeted to the Centralized user s extension locally in Rainy day. Both Sunny day and Rainy day call handling are done automatically by matching the called number to the Centralized user s extension number. IP Office can manage calls to Centralized users that are dialed to the Centralized user s full extension number, or calls that are dialed using short-form dialing. To support short-form dialing, the global parameter Short Form Dialing Length must be configured. The Short Form Dialing Length field appears in IP Office Manager under System > Telephony tab > SM tab. Configuration of this feature allows IP Office to treat the last N digits (where N is the number configured for the Short Form Dialing Length) as an alias to that user s extension number. Short-form dialing from Centralized phones The Sunny day conversion from the dialed short-form number (for example, 1111) to the enterprise canonical extension number (for example, ) is done by the Communication Manager 34 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

35 Security considerations Feature Server (CM-FS) or Communication Manager Evolution Server (Communication Manager- ES) based on the caller s location. When a Centralized user makes a call in Sunny day, the call goes directly from the Centralized phone to Session Manager, and IP Office is not involved at this stage. Session Manager first sends the call to the Communication Manager-FS or Communication Manager-ES responsible for calling the Centralized user for origination-side features. That Communication Manager performs the called-number conversion from the dialed short-form to the enterprise canonical number, and sends the call back to Session Manager with the called number modified to the enterprise-canonical number. Session Manager then sequences the call to other applications, if any, and then routes the call based on the enterprise-canonical number. This conversion in Communication Manager is based on Communication Manager configuration of a perbranch location via ip-network-map and ip-network-region forms, as well as Communication Manager per-location AAR analysis to identify the short-form dialed number and per-location route pattern which modifies the called number before sending to Session Manager. For Rainy day calls made from one Centralized user to another Centralized user, the IP Office Short Form Dialing Length has to be set. Security considerations The IP Office Branch solution provides security to prevent unauthorized users from accessing the system and to prevent unwanted traffic from entering. This section provides an overview of the security for all deployments in the Branch architecture. For detailed information about Avaya Aura System Manager security, see Security considerations in Avaya Aura System Manager Overview and Specification. System security settings Update security settings to prevent unauthorized users from changing system settings. You can edit the access privileges for each user and update security passwords. By default, security settings for a centralized, mixed, or distributed deployment connected to the Avaya Aura infrastructure, are managed in the System Manager web interface. However, you can choose to disable centralized administration and update the settings for each IP Office using IP Office Manager. If autonomous branches with no centralization are deployed, you must update security settings with IP Office Manager. Secure TLS and SRTP signalling When the Branch solution is deployed in a centralized, mixed, or distributed environment connected to the Avaya Aura infrastructure, you can use secure transport methods and media encryption to maintain the confidentiality of media communications. You can select the secure TLS, instead of TCP, as the transport method for SIP phones deployed as Centralized users and for many types of SIP endpoints that are deployed as IP Office users. You can also configure TLS as the SIP connection between Session Manager and IP Office. When TLS is activated, you can enable Secure Real-time Transport Protocol (SRTP) for media encryption. SRTP is supported by IP Office with many types of endpoints deployed as IP Office users and with all phones that are deployed as Centralized users. SRTP interoperability is also supported between IP Office and other components in the solution on calls through the SM Line. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 35

36 Design considerations In cases where there is no SRTP compatibility between one call leg and the other, IP Office does not set up direct media for the call. Instead, IP Office relays the media and converts it as required. An example for such an SRTP call flow is described in Appendix A. IP Office supports SRTP interoperability with the following products: The following endpoints deployed as IP Office users: , 9611, 9621 and 9641 H323 phones (also known as 96x1 H.323 phones) - Avaya Communicator for ipad and Avaya Communicator for Windows - one-x Mobile Preferred ios and one-x Mobile Preferred Android - 11xx/ 12xx series phones - E.129 series phones - B.179 series phones - Radvision XT series Avaya Aura Session Border Controller The following endpoints deployed as Centralized users, both in Sunny day and in Rainy day: series SIP phones (both 96x1 and 96x0) - Avaya one-x Communicator - 11xx/ 12xx series phones - E.129 series phones - B.179 series phones Communication Manager and its endpoints in other sites with signaling through Session Manager that includes the following phones: - G450 Branch Gateway used by the central Communication Manager to handle any calls that are not shuffled. - Phones, such as, 9600 series phones, which are registered to Communication Manager. IP Office exchanges media directly when Communication Manager sets up direct media or shuffles the call. The following other applications and products are behind Session Manager: - Avaya Aura Messaging - Avaya Aura Conferencing - Avaya Aura Session Border Controller Certificate configuration Establishment of TLS connections depends on the successful exchange and verification of certificates. Certificates must be set up appropriately on the different products involved. In branch deployments. when IP Office is managed by System Manager, each IP Office must obtain an identity certificate that is generated and signed by System Manager. Each IP Office should be added to the System Manager Certificate Authority and the Simple Certificate Enrollment Protocol (SCEP) should be configured to enable IP Office to obtain required certificates from System Manager. For more information, see Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager ( ). 36 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

37 Security considerations If the phones register using the TLS protocol, in order to register to IP Office in Rainy day, the System Manager CA root certificate must be included in the list of files installed on the file server. This is required because the phones must trust the System Manager CA root certificate so they can verify the IP Office Identity Certificate that is signed by the System Manager CA. Ports and firewalls If the network includes any firewalls between the branch and the rest of the enterprise, then the appropriate ports must be opened on those firewalls to enable necessary traffic to enter. Related Links Port assignments on page 44 Caveats and limitations on page 25 December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 37

38 Chapter 4: Configuration details Network configuration IP Office is a converged telephony system that combines aspects of a traditional PABX telephone system and IP data and telephony systems. The Branch solution supports VoIP that includes IP trunks, SIP 9600 series telephones for centralized users, as well as H.323 and SIP IP telephones for local IP Office users. In a Distributed, Mixed, or Centralized environment connected to the Avaya Aura infrastructure, the VoIP connection is established between the IP Office branch and the enterprise center over WAN. VoIP signaling is based on SIP signaling between the IP Office in the branch and the Avaya Aura Session Manager in the enterprise center. Regardless of the deployment architecture, you must consider the following network configuration factor: A network assessment is a mandatory requirement for all systems using VoIP. For support issues with VoIP, Avaya may request access to the network assessment results and may refuse support if those are not available or satisfactory. If you need to update the default timer settings for the solution, see Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager ( ). IP Office SIP connection to Avaya Aura Session Manager When connecting the IP Office in the branch to Avaya Aura Session Manager, you must configure the SIP connection on both systems as follows: On the IP Office, the connection to Session Manager is configured as an SM Line. This is a special type of SIP trunk on the IP Office. On the Session Manager, the connection to the IP Office is configured as a SIP Entity Link. SM Lines provide the following additional capabilities in the Branch solution: Ability to monitor the SIP connection to Avaya Aura Session Manager and determine whether the connection is up or down. Ability to configure dial plans and prefixes for the branch. You must obtain SIP Trunk Channel licenses for the IP Office to make or receive calls over the SM Line. 38 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

39 Network configuration IP Office supports two Sessions Managers, a primary Session Manager and a secondary Session Manager, which are each connected through an SM Line. To route calls, you must configure the following routing rules on IP Office and on Avaya Aura Session Manager: On the IP Office, you must configure appropriate IP Office Short Codes and optionally IP Office ARS entries to route calls to the rest of the enterprise through the SM Line. This is not needed to route calls to Centralized users in the branch. IP Office automatically routes these types of calls within the branch in sunny-day mode through the SM Line. On the Session Manager, you must configure appropriate Routing Policies and Dial Patterns to route calls to the IP Office in each branch. Each IP Office system has 2 LAN interfaces, labelled as LAN (LAN 1) and WAN (LAN 2). The SM Lines, as well as connections to IP phones, should be configured to use LAN 1. LAN 2 is primarily intended to connect to the Internet or to public SIP trunks from carriers. You must enable SIP trunks on the LAN 1 configuration in order for the SM Line to use that LAN interface. For more information about configuring SM Lines and other SIP connections, see Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager ( ). Related Links SM trunk channel licenses on page 31 Dial plan considerations on page 33 Fax services through the SM line You can deploy fax machines as IP Office analog endpoints. The Branch solution supports fax machines deployed as centralized ATA endpoints. In the IP Office branch, you can send and receive faxes from the enterprise headquarters or other enterprise sites. Faxes are sent over the SM line using the T38 protocol and consume WAN bandwidth. The settings for T38 are set on the T38 Fax tab. JRE requirement for client computers When launching IP Office Manager, client computers need Java Runtime Environment (JRE). JRE is required to open IP Office Manager through the Java Applet. As an System Manager administrator, you must install JRE 1.7+ on your client machine to manage IP Office users, system configuration, and security configuration. If JRE 1.7+ is not installed, the system displays the following message: Failed to launch IP Office Manager. IP Office Manager requires Java Runtime Environment to launch, System has detected that there is no Java Runtime Environment present or version present is below recommended Java Runtime Environment version Download and install latest Java Runtime Environment version for Windows operating system from the Oracle site downloads/index.html. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 39

40 Configuration details You can download the latest version of JRE from downloads/index.html. Note: Upgrade JRE to JRE 1.7.0_51+ and upgrade JDK plugin in the browser to JDK Because JRE 1.7 introduced security settings changes, you must clear the browser cache and temporary internet files of Java from Java Control Panel. To delete the cache of applications and applets, when you delete the temporary internet files from Java Control Panel, click Installed Applications and Applets. Video configuration You can connect video endpoints in the Branch to IP Office or to the entralized Avaya Aura infrastructure. Note: The supported video endpoints in IP Office Branch deployment are Avaya Scopia and Avaya Flare Experience. Deployment option 1: Connect video endpoints to IP Office In this type of deployment, the signaling call flow for video calls goes through the IP Office. The RTP media of the video stream does not go through the IP Office if direct media is appropriately set up on the IP Office. If the WAN connection between the branch and the center is lost, the video endpoints are still connected to the IP Office. Video calls to other sites will not be possible if the WAN is disconnected, but local video calls within the branch or audio-only calls to the PSTN through the IP Office can still be made. For more information about connecting the video endpoints to IP Office, see IP Office: Avaya Scopia Installation Notes. Note: You must set up video to use Direct Media on IP Office. IP Office video endpoints registered to IP Office in the branch can have video calls with the headquarters or other sites of the enterprise. You can use these endpoints to make and receive video calls to and from any of the following: A video multipoint control unit (MCU) located centrally such as in the headquarters, which is connected via the central Avaya Aura Session Manager. A video endpoint registered to the central Session Manager. A video endpoint registered to an IP Office in another branch, which is connected via the central Session Manager Deployment option 2: Connect video endpoints to the Avaya Aura infrastructure In a typical branch deployment using this option, the video endpoint is deployed within the branch and connected through the WAN to the central Avaya Aura infrastructure. In this deployment option, IP Office is not involved in either the signaling or the media flow between the video endpoint in the branch and endpoints in other sites. If the WAN connection between the branch and the center is lost, the video endpoints do not receive service. Failover of these endpoints to IP Office is not supported. 40 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

41 Packaging and order codes For more information about connecting video endpoints to the Avaya Aura infrastructure, see Avaya Aura Communication Manager Release 6.2 and Avaya Scopia Release 7.7 and 8.0 Interoperability Day 180 Solution Quick Setup. Related Links Network impact on video on page 47 Packaging and order codes Many solutions, applications, and features on IP Office systems are licensed and only operate when a valid license is detected. IP Office can obtain licenses through one or more of the following sources: ADI keys Product Licensing and Delivery System (PLDS) nodal license files Interactions with a central Avaya WebLM server The remote PLDS license on WebLM is the recommended method for an IP Office deployed as an enterprise branch. PLDS licenses for IP Office are available for common features and can replace ADI licenses. In exceptional cases, if a feature cannot be licensed through PLDS, you can obtain an ADI license for that feature and use the ADI license in a hybrid licensing system with existing PLDS licenses and Avaya WebLM. The following table lists the IP Office licenses available in PLDS. Table 7: IP Office licenses in PLDS Display name Avaya WebLM Model 9.1 Avaya Softphone Avaya Mac Softphone Avaya Contact Center Select Branch System Essential Edition Additional Voic Ports Description This license is required by IP Office in order to use WebLM centralized licensing, connect to the WebLM server, and operate in the WebLM license enforcement model that includes the License Error mode grace period. See Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager for more information on license modes. This license enables support for basic Flare Communicator for IP Office usage on IP500 V2 systems when either one-x Portal for IP Office or Voic Pro is not available. The license can be used with any user profile including Basic User. This license enables support for Mac softphone. This license is required to support Avaya Contact Center Select. This license is required for branch systems. You cannot configure this license. It is used for tracking purpose only. You must obtain a sufficient quantity of Essential Edition Additional Voic Ports licenses to support the number of simultaneous calls that you want to allow to the Embedded Voic . By default, Embedded Voic provided by the system supports 2 December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 41

42 Configuration details Display name Essential Edition Description simultaneous connections and 15 hours of storage. This license enables expansion of up to 6 channels. Each license enables an additional two channels. Each license also enables an additional 5 hours of storage. This license is for IP500v2 systems only. One per branch required for any deployment of IP Office in a branch. This license is required for IP500v2 systems to run in IP Office Essential Edition mode. Preferred Edition Optional. If used, obtain one license for each branch. This license is required if the branch needs one or more of the following: This license enables support for Voic Pro as the IP Office voic server with 4 voic ports. An Essential Edition license is a pre-requisite for this license on IP500v2 systems. IP Office unified communications capabilities such as Avaya one- X Portal, presence and instant messaging, Outlook Integration, or Lync Integration. Specific IP Office user profiles. IP Office Avaya IP Endpoints license These licenses are used to license additional Avaya IP phones on IP500v2 systems. By default, these licenses are consumed by each Avaya IP endpoint that registers with the system. The license is released if the phone unregisters. One license is required for each IP Office H.323 or SIP extension used by an IP Office user if the endpoint used is an Avaya endpoint, such as an H phone or a SIP 1220 phone. IP Office Centralized Endpoints license One license required for each Centralized user configured on the IP Office with a SIP extension or an analog extension. This license is only available from PLDS and not from ADI. Important: In addition to this IP Office license, each centralized user also requires a license on the central Avaya Aura system. IP Office Third Party IP Endpoints license These licenses are used for support of non-avaya IP phones including SIP extensions. Available licenses are used in order of phone registration. If no license is available, the phone will not be able to register. One license is required for each IP Office H.323 or SIP extension used by an IP Office user if the endpoint used is not an Avaya endpoint. IP500 Universal PRI Incremental channels The IP500 PRI Universal trunk card (IP500 PRI-U) is available in 1 or 2 port variants, each port supporting a single PRI trunk connection. Through the IP Office configuration, the ports can be switched between supporting E1, E1R2, or T1 line types as required for the trunk being connected. Each port supports 8 B-channels or Bearer, which do not need to be licensed. If additional B-channels are 42 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

43 Packaging and order codes Display name Incremental Voic Ports IPSec Tunneling Mobile Worker Office Worker Power User Receptionists SIP Trunk Channels SM Trunk Channel Description required, they must be licensed through additional licenses. Multiple licenses can be added to achieve the total number of channels required. D-channels are not subject to licensing. The licenses are consumed by the channels that are configured as in service. You must obtain a sufficient quantity of Incremental Voic Ports licenses to support the number of simultaneous calls that you want to allow to Voic Pro. By default Voic Pro supports 4 voic ports. This license enables additional ports, up to a maximum capacity of 40. This license enables the system to initiate and terminate IPSec and L2TP tunnels. These licenses set the number of users who can have their profile set as Mobile Worker. These licenses set the number of users who can have their profile set as Office Worker. These licenses set the number of users who can have their profile set as Power User. This license is used to enable support for the IP Office SoftConsole application. This license can only be used by users set to Receptionist in the IP Office configuration. These licenses are used to configure the maximum number of simultaneous SIP trunk calls supported. A value has to be configured according to the maximum number of concurrent SM Line calls to be enabled on the system. It has to be consistent with the value of the Max Calls field on the SM Line configuration. The calculation of how many SM Trunk Channel licenses are required depends on the expected traffic patterns in the particular deployment. For more information, see SIP trunk channels on page 31. Software Upgrade (upgrades to 9.1) Small Site Software Upgrade (upgrade to 9.1) Teleworker Third Party API Unified Messaging Server (UMS) Web service Upgrade licenses depend on the system size. Small system upgrade license can be used to upgrade systems with up to 32 users and no external expansion modules. Large system upgrade license can be used to upgrade system with more than 32 users or with external expansion modules. This license supports 32 users or less and no expansion modules. It is available for Basic Edition in IP Office. These licenses set the number of users who can have their profile set as Teleworker. This license enables CTI Link Pro functionality required for use of the TAPI Link Pro and DEVLink Pro interfaces. UMS allows users to access messages in the Voic Pro mailbox using either a web browser that uses an IMAP compatible application or a Microsoft Exchange Server 2007 message store. The December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 43

44 Configuration details Display name VMPro Recordings Administrators VMPro TTS Professional VMPro TTS Generic VMPro TTS Scansoft Description total number of users supported is set by adding combinations of the following licenses. This license is required to support ContactStore in a multi-site network. This license enables use of all text-to-speech facilities provided by Voic Pro running on a Linux server. One license per simultaneous instance of TTS usage. This license is used within customized voic call flows to speak information to callers instead of recording prompts for the call flow or speak results of IVR queries. This license enables the use of Scansoft TTS speech engines. The Scansoft TTS engines are delivered on a separate DVD that has to be purchased and installed additionally. This is supported on Windows Voic Pro only. Voice Networking Channels This license enables support for multi-site network, QSIG and H.323 IP trunks. The additional ports license can be used without requiring a base license first. This license is for IP500 and IP500v2 systems only. Wave User Web Collaboration This license allows streaming of WAV files, using TAPILink Pro, for 3rd party voice applications. This is a per user license. This license is required for users with Web collaboration. This is available on Preferred or Server Edition with appropriate User profile license. Port assignments The IP Office Branch solution uses protocol interactions between the IP Office in the branch and solution components in the Avaya Aura core as well as in other parts of the enterprise network. If the network includes any firewalls between the branch and the rest of the enterprise, then the appropriate ports must be opened on those firewalls to enable necessary traffic to enter. If the deployment includes centralized users, you must also open the appropriate ports on the firewall to enable interactions between centralized SIP phones and other sites. The following image shows the main ports used in the IP Office Branch solution. 44 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

45 Port assignments Figure 2: Main ports in IP Office Branch solution For a detailed list of IP Office and SIP phone ports, see the following part matrix documents at Avaya one-x Deskphone 96x1 SIP Release 6.2 Port Matrix IP Office Port Matrix December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 45

46 Configuration details Traffic and Quality of Service Quality of Service requirements To achieve good voice and video quality, your network must meet certain network requirements. Even if these requirements are met, other factors may still prevent you from achieving optimal voice and video quality. Video should be HD quality. The terms used to describe acceptable voice quality are toll quality and business communication quality. Optimal voice quality is toll quality, but business communication quality is well suited for most enterprises. Business communication quality is not as high as toll quality, but is still much better than cell phone quality. The following table summarizes the network delay, jitter, and packet loss requirements that the network must meet. Table 8: Quality of Service (QoS) requirements Requirements Network delay Network jitter Network packet loss Description Voice quality: To obtain toll quality, the delay cannot exceed 80 milliseconds (ms). To obtain business communication quality, the delay must be between 80 ms to 180 ms. Business communication quality is well suited for most enterprises. Delays exceeding 180 ms provide a lower quality than business communication quality, but this may still be acceptable depending on end user enterprise requirements. Video quality: The network delay cannot exceed 150 ms. To achieve optimal voice and video quality, the average jitter should be less than half the network packet payload. This value can vary depending on the type of service the jitter buffer has in relation to other buffers and to the packet size used. Assuming the packet size is 20 ms, to prevent problems with voice and video quality, the network jitter should not exceed 20 ms. Voice quality: To obtain toll quality, the packet loss cannot exceed 1%. To obtain business communication quality, the packet loss cannot exceed 3%. A packet loss exceeding 3% provides a lower quality than business communication quality. This may result in signaling interferences. 46 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

47 Traffic and Quality of Service Requirements Description Video quality: Network packet loss should not exceed 0.2%. When transporting voice over low speed links, normal data packets can prevent or delay voice packets from getting across the link. This can result in unacceptable speech quality. To ensure low speech latency and help maintain sufficient voice quality, implement another Quality of Service (QoS) mechanism, such as a QoS router, on the traffic routers and switches in your network. QoS mechanisms must be implemented on the WAN routers that connect the branch with the rest of the enterprise network. QoS must be based on DSCP tagging. Use the DSCPs to determine the appropriate priority queuing and handling to implement on the network routers. DSCP tagging should be then be configured consistently on the IP Office and on the Avaya Aura Communication Manager for the telephones connected to the Avaya Aura system. Network impact on video Multiple network parameters affect the quality of video, such as the bit rate, the frame rate, the packet loss ratio, the content type, the compression method, jitter, and intra-frame coding. Each of these parameters might impact the quality of experience of a user. Recommended specifications The following table lists the recommended values for the network parameters that impact the video quality: Network parameter One-way network delay Network packet loss for video <= 0.2 % Latency Jitter Frame rate Recommended value <= 80 ms to 180 ms < 300 ms <= 20 ms >= 26 fps MOS 4 to 5 Bandwidth requirements For local branch calls involving Centralized users, the signaling path goes over the WAN to the Avaya Aura Session Manager and back to the branch. These types of local branch call scenarios include: Calls between two Centralized users in the same branch Calls between a Centralized user and an IP Office user in the same branch Calls between a Centralized user and the PSTN via a PSTN trunk on the local IP Office in the branch December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 47

48 Configuration details While the signaling path goes over the WAN, the media path for such calls remains within the branch and does not go back and forth across the WAN. This depends on the central Avaya Aura Communication Manager being appropriately configured for direct IP-IP audio. If Avaya Aura Communication Manager is configured for Initial Direct Media, then no media will be sent over the WAN for the call. If Avaya Aura Communication Manager is not configured for Initial Direct Media, but only for direct IP-IP audio or shuffling, then the first few media packets of each local call are relayed across the WAN through a Communication Manager central media resource, such as the G450 Media Gateway in the enterprise center. This occurs until Avaya Aura Communication Manager shuffles the call so the media goes directly within the branch. Exceptions for local calls Exception cases where the media streams of local calls consume WAN bandwidth are as follows: If the Centralized user initiates a conference on Avaya Aura Communication Manager, then the different media streams are pulled by Communication Manager across the WAN to the central G4xx gateway. There is one media stream between the central G4xx gateway (where the Communication Manager conference is hosted) and each of the conference participants. For example, in a three-way sunny-day Communication Manager conference that includes two Centralized users in the branch and a PSTN caller through a local PSTN trunk on the IP Office in the branch, there will be three media streams across the WAN between the central G4xx gateway and the branch. If the Centralized user puts the call on hold, then Avaya Aura Communication Manager plays music-on-hold from the central G4xx gateway across the WAN to the branch. Other call scenarios that consume WAN bandwidth Calls between IP Office users and users in other sites of the enterprise are routed either through the Avaya Aura Session Manager or through the PSTN, depending on how the solution is configured. If configured to route the calls across the SIP connection between the IP Office and the Avaya Aura Session Manager, then both the signaling and the call media go across the WAN. For site-to-site calls between Centralized SIP users in sunny-day, the signaling goes through the Avaya Aura Session Manager and the media goes between the endpoints across the WAN. The IP Office in the branch is not involved in such calls. The Communication Manager Inter-Gateway Alternate Routing (IGAR) feature is not supported with IP Office branch deployments and the media flow of such site-to-site calls between Centralized SIP users cannot be sent through the PSTN instead of the WAN. Codec bandwidth usage By default, all IP Office IP trunks and extensions use automatic codec negotiation. The default negotiation order varies depending on the type of SD card configured. With an IPO MU_LAW SD card, the default negotiation order is G711.MU_LAW, G711 A_LAW, G729a, and G With an IPO A_LAW SD card, the default negotiation order is G711.A_LAW, G711.MU_LAW, G729a, and G Calls to and from IP devices can require conversion to the audio codec format being used by the IP device. For IP Office systems, this conversion is done by voice compression channels. The voice 48 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

49 Traffic and Quality of Service compression channels support the common IP audio codecs G711, G723 and G729a. For more information about configuring codecs and voice compression channels, see Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager ( ). The following table lists the default codecs available and the other options you can select for each codec. Setting Selected Preference G.729 G729(a) 8K CS- ACELP G.723 G K3 MP- MLQ 2nd Preference 3rd Preference 4th Preference G711 U-Law 64K G711 A-Law 64K G K3 MP- MLQ G729(a) 8K CS- ACELP G711 U-Law 64K G.711 U-Law G711 U-Law 64K G711 A-Law 64K G729(a) 8K CS- ACELP G.711 A-Law G711 A-Law 64K G711 U-Law 64K G729(a) 8K CS- ACELP G711 A-Law 64K G K3 MP- MLQ G K3 MP- MLQ Some calls and media flows do not consume WAN, but others do. For calls that consume WAN bandwidth, codec selection is an important factor in determining the amount of bandwidth consumed and the audio quality of the call. The G729 codec consumes less bandwidth but can result in reduced audio quality. Depending on the needs of the enterprise, the audio quality with the G729 codec may not be acceptable. The G711 codec provides optimal audio quality, but consumes more bandwidth. The amount of bandwidth consumed by different codecs is the same for Avaya Aura Communication Manager and IP Office. Typical bandwidth usage The following table can be used to help assess how much bandwidth (in Kbits/sec) is used for various types of codecs and packet sizes. The values shown have a 7 byte L2 WAN header and are rounded up. Packet Size 10 ms 20 ms 30 ms 40 ms 50 ms 20 ms G G G NA NA 19 NA NA 13 G NA NA 18 NA NA 12 G NA 43 NA 34 NA 31 Related Links VCM channels on page 29 Bandwidth management on page 50 Direct media setting in Avaya Aura Communication Manager To prevent media flow from unnecessarily crossing the WAN to a central Communication Manager media resource, you must enable the Initial IP-IP Direct Media parameter in Avaya Aura December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 49

50 Configuration details Communication Manager. This must be done in all IP Office branch deployments with Centralized users. Enabling this parameter is especially important for the following types of calls: Calls between Centralized users within the branch Calls between Centralized users and local IP Office trunks WAN bandwidth usage for signaling traffic Determining the WAN bandwidth needed for signaling traffic requires network engineering calculations based on the user s expected call patterns. Signaling bandwidth is impacted by the average frequency of calls, while media bandwidth is also impacted by the average length of calls. A call between a Centralized SIP user and a local IP Office PSTN trunk in the same branch typically generates about 50 kilo Bytes of signaling traffic on the WAN link between the branch and the Avaya Aura core. This number must be multiplied by the expected number of calls to calculate the estimated bandwidth required for signaling in kilo bits per second. Calculation example If the average number of PSTN calls made or received by all the Centralized SIP users in the branch is 150 calls an hour, then 7,500 kilo Bytes of bandwidth is consumed per hour. On average, if spread evenly, this would mean that signaling for these calls will consume 17 kilo bits per second of the WAN bandwidth. Bandwidth management In IP Office Branch solution, Avaya Aura Session Manager provides bandwidth management through Call Admission Control (CAC). This service is available is available in Distributed, Mixed, and Centralized deployment options connected to the Avaya Aura network. You must configure a location for each branch on Avaya Aura Session Manager, and make sure that Session Manager detects that the IP Office and the centralized users in the branch are part of the same location. Make sure the IP address pattern configured in the Location Pattern section of the Session Manager location represents the IP addresses for the branch. You must select the name of the location in the Location field of the SIP Entity configured in Avaya Aura System Manager for the IP Office in the branch. You can configure a bandwidth limit for a branch location in Avaya Aura Session Manager. The bandwidth limit should be configured according to: The network bandwidth available for media traffic on the WAN link that connects the branch to the rest of the enterprise network Expected traffic patterns to and from the branch The Session Manager CAC feature inspects the SDP in call signaling to count the total bandwidth of calls. When the bandwidth limit is reached the Session Manager CAC rejects all new calls to and from the IP Office branch location. 50 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

51 Traffic and Quality of Service The Session Manager CAC is aware that centralized users and IP Office are in the same branch, and can calculate the following call details to determine the bandwidth of calls: The number of calls to and from the IP Office The number of calls to and from centralized users in the branch The CAC can determine the types of calls that consume WAN bandwidth. For example, a call between an IP Office user or trunk and a centralized user in the same branch does not consume WAN bandwidth because the media flow is local within the branch. The CAC does not count this type of call with local media flow toward the configured WAN bandwidth limit for the branch. Session Manager CAC specifications Audio and multimedia calls require high bandwidth and low latency for best user experience. Call Admission Control (CAC), also known as Bandwidth Management, provides an efficient means to prevent degradation of quality by limiting the number of concurrent calls over limited bandwidth links. Based on location level settings, Avaya Aura Session Manager provides the following set of CAC functionality using Session Description Protocol (SDP): 1. Recognizes different types of calls categorized either as audio or multimedia. Multimedia includes video and other forms of non-audio media sent by endpoints as part of a session. 2. Provisions a second, lesser limit on the bandwidth usage permitted for a location. This second limit applies only to multimedia calls (Multimedia Bandwidth) and prevents such calls from consuming too large a percentage of the available bandwidth of a location (Total Bandwidth). 3. If the Total Bandwidth is left BLANK then Session Manager does not perform CAC for calls in the Location. 4. Allows audio and multimedia bandwidth sharing at a location by selecting the option Audio Calls Can Take Video Bandwidth. If selected, then Session Manager considers only the Total Bandwidth when deciding whether a new audio call can proceed. If not selected, then Session Manager considers the Total Bandwidth minus the Multimedia Bandwidth when deciding whether a new audio call can proceed. 5. Specifies per-call bandwidth limits (as specified in Per-Call Bandwidth Parameters section), restricting the size of individual multimedia calls. Session Manager alters the SDP provided by call parties by enforcing the bandwidth limits as follows: Determines how much bandwidth to be reserved for each call and counts the determined value against the provisioned limit. If the multimedia bandwidth is beyond what is provisioned (Maximum Multimedia Bandwidth (Intra-Location) or Maximum Multimedia Bandwidth (Inter-Location)), Session Manager can reduce the multimedia bandwidth as low as the administered multimedia minimum (Minimum Multimedia Bandwidth) limit. In such cases, users experience a reduction in media (usually video) quality. Otherwise, calls are either alternate-routed or denied when limit enforcement cannot be achieved by quality reduction. Audio call quality is not modified by Session Manager. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 51

52 Configuration details If Session Manager cannot allow the multimedia minimum (Minimum Multimedia Bandwidth), then multimedia streams are removed from the call by setting their ports to zero, which results in denying the multimedia portion of the call For information about administering CAC, see Administering Avaya Aura Session Manager ( ) Redundancy and high availability Redundancy and high availability are supported in the Avaya Aura network. Centralized users in the architecture can also access the Rainy day mode when all available Avaya Aura servers are down. Redundancy and high availability from the Avaya Aura network The following redundancy and high availability options are available through the Avaya Aura network. High availability: The Avaya Aura network uses System Platform high availability. When deploying Avaya Aura System Manager, you must also install and configure System Platform. For more information about System Platform high availability, see Installing System Platform in Implementing Avaya Aura System Manager. Session Manager geographic redundancy: The IP Office Branch solution supports Avaya Aura Session Manager geographic redundancy when a back-up Session Manager is deployed in the secondary data center. If for any reason the IP Office system's primary Session Manager goes out of service, the system will automatically attempt to use the secondary Session Manager. Prioritization of the Session Manager is determined by the line number configured for a particular Session Manager. For example, if the first Session Manager is configured with line number 17 and the second Session Manager is configured with line number 18, then line number 17 has the higher priority and is considered the primary Session Manager. If for some reason you want to designate the secondary Session Manager as the primary line, you must change one or both of the line numbers associated with the Session Manager so that the secondary Session Manager number is lower than the primary line number. System Manager geographic redundancy: In deployments with Avaya Aura System Manager geographic redundancy set up, the IP Office devices added in the primary System Manager are also visible in the secondary System Manager. To use Avaya Aura System Manager geographic redundancy in the IP Office Branch solution, make sure: The initial interactions through the SCEP protocol are done between the IP Office and the primary System Manager to establish trust. 52 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

53 Redundancy and high availability The IP address for the primary and secondary System Manager are configured as trap destinations in the IP Office. This way, IP Office sends alarms and traps to both System Manager servers. When the primary System Manager server is down, the secondary System Manager server still receives this information. If the IP Office is using Avaya WebLM centralized licensing and the connection between the IP Office and the Avaya WebLM server on the primary System Manager is down, then the IP Office goes into WebLM Error Mode. In this mode, all functionality is available for a grace period of 30 days. No action is required if the Avaya WebLM server on the primary System Manager is active and reachable in less than 30 days. If there is a risk of the System Manager server not being available for 30 days, you must modify the IP Office configuration to use the Avaya WebLM server on the secondary System Manager as soon as possible. Redundancy through Rainy day support When all available Avaya Aura servers are down, centralized users can still obtain telephony services through IP Office with Rainy day series phone features in Rainy Day: The following features are available on 9600 series centralized SIP phones when registered to IP Office in Rainy day mode. Make or receive calls to or from other endpoints in the branch and to or from any type of local PSTN trunk Caller ID Multiple call appearances but not bridged appearances Call hold and consultative hold Music on hold Attended call transfer Unattended call transfer Three-party ad-hoc conferencing done locally on the phone, as well as capability to dial into Meet-Me conferencing on the IP Office up to 64-party conference Centralized voice mail coverage and access over PSTN, but no Message Waiting Indication (MWI) Automated Attendant Survivability mode indication on the phone screen Local telephone features: redial, mute, audio selection (speaker / headset / handset), Call Logs, Volume Control, local contacts, speed-dials, auto dials Station Message Detail Recording (SMDR) records stored on the IP Office for retrieval after WAN recovery Hunt groups December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 53

54 Configuration details IP Office can be configured with Centralized hunt groups for which IP Office processing is in effect only in the Rainy day mode. The IP Office administrator must configure the hunt groups on the IP Office consistent with the configuration on the central Avaya Aura Communication Manager for the Sunny day mode. Call Management IP Office can be configured with short codes using the Barred feature to restrict in the Rainy day mode what calls the Centralized user can make. The IP Office administrator must configure this consistent with the Class of Restriction (CoR) configured on Communication Manager, which is applied to the same user in the Sunny day mode. Send call to mobile phone IP Office can be configured with Mobile Twinning to send calls for the Centralized user in the Rainy day mode to a mobile number. The IP Office administrator must configure this on the IP Office consistent with the EC500 configuration on the central Communication Manager for the same Centralized user. Call forwarding Local Call Forwarding on the phone in the Rainy day mode can be configured. The Call Forwarding set on Communication Manager in the Sunny day mode has no impact on the local behavior of the phone or on the IP Office behavior in the Rainy day mode. Also, the local Call Forwarding set on the phone works only in the Rainy day mode after failback. Authorization codes IP Officecan be configured to support authorization codes that Centralized users can use in the Rainy day mode. The IP Office administrator must configure authorization codes consistent with the authorization codes configured on Communication Manager, which are available to the same Centralized users in the Sunny day mode. Centralized SIP phone users in Sunny day will hear 3 beeps to indicate that an authorization code is required. In the Rainy day mode, the Centralized SIP phone users will hear 1 beep that repeats approximately every 5 seconds. ATA endpoint features in Rainy Day: The following features are available for ATA endpoints when registered to IP Office in Rainy Day mode. Make or receive calls to or from other endpoints in the branch and to or from any type of local PSTN trunk Call hold and consultative hold Music on hold Attended call transfer Unattended call transfer ATA user can dial into Meet-Me conferencing on the IP Office (up to 64 party conference) Centralized voice mail coverage and access over PSTN, but no Message Waiting Indication (MWI) E.129, 1100, and 1200 series phone features in Rainy Day: 54 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

55 Redundancy and high availability The following features are available for E.129, 1100, and 1200 series SIP phones with IP Office in Rainy Day mode. Minor feature differences between E.129 series phones versus 1100 and 1200 series phones are indicated in the following list. Make or receive calls to or from other endpoints in the branch and to or from any type of local PSTN trunk TLS and SRTP without direct media on 1100 and 1200 series phones. E.129 series phones support direct media with TLS and SRTP. Call forwarding on the phone set instead of on the server Note: Call forwarding is not available in Rainy Day for busy and unanswered calls. Speed dial through address book Caller ID Receive multiple simultaneous calls Call hold and retrieve Consultative hold Music on hold Do not disturb status for 1100 and 1200 series phones Attended and unattended call transfer Ad-hoc conference Meet-me conference for 1100 and 1200 series phones Centralized voice mail coverage for 1100 and 1200 series phones Auto-attendant support Hunt group support SMDR support Call restriction support Survivability mode indication on phone set for 1100 and 1200 series phones Last number redial Mute and unmute Incoming and outgoing call logs Local address book Feature access codes or short codes for 1100 and 1200 series phones Centralized voice mail coverage and access over PSTN, but no Message Waiting Indication (MWI) December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 55

56 Appendix A: Call flows Overview of IP Office example call flows This section describes major IP Office call flows, but does not provide an exhaustive list of all possible call flow scenarios. Calls from IP Office user phones (i.e. deployed as a Distributed enterprise branch) 1. IP Office user phone to IP Office user phone IP Office user phone A IP Office IP Office user phone B 2. IP Office user phone to PSTN (using local trunking) IP Office user phone IP Office IP Office trunk (e.g. FXO, ISDN, SP SIP Trunk) PSTN 3. IP Office user phone to PSTN (using centralized trunking) IP Office user phone IP Office Session Manager central gateway/sbc PSTN 4. IP Office user phone to headquarters or other enterprise site IP Office user phone IP Office Session Manager target phone s controller target phone Calls to IP Office user phones (i.e. deployed as a Distributed enterprise branch) 1. From PSTN to IP Office user phone via IP Office auto-attendant (branch auto-attendant LDN is associated with local IP Office trunk) PSTN IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) IP Office auto-attendant caller enters extension number IP Office user phone 2. From PSTN direct to IP Office user phone s DID (LDN is associated with local IP Office trunk) PSTN IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) IP Office IP Office user phone 3. From headquarters (or other enterprise site) to IP Office user phone s enterprise number Originating phone originating phone s controller Session Manager IP Office IP Office user phone 4. From headquarters (or other enterprise site) to IP Office user phone via IP Office autoattendant Originating phone originating phone s controller Session Manager IP Office IP Office auto-attendant caller enters extension number IP Office user phone Calls from Centralized phones in normal mode (aka Sunny day) 1. Centralized phone A to centralized phone B in the same branch 56 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

57 Overview of IP Office example call flows Centralized phone A Avaya Aura core servers (including Session Manager and CM-FS or CM-ES) centralized phone B Note: The IP Office is not involved in handling the call in this scenario. The call flow descriptions in this document are intended to clarify the call flow between the branch and the core with focus on IP Office involvement. For brevity, they do not elaborate on the processing of the call within the core, among the different elements of the Avaya Aura server infrastructure at the enterprise core. For example, a more complete depiction of the call flow for this scenario would be: Centralized phone A Session Manager origination-side processing by the CM-FS or CM- ES responsible for user of phone A Session Manager termination-side processing by the CM-FS or CM-ES responsible for user of phone B Session Manager centralized phone B This depiction of the call flow includes the core Avaya Aura Communication Manager acting as the feature server for the centralized user. The Communication Manager Feature Servers (CM-FSs) or Communication Manager Evolution Servers (CM-ESs) for user A and user B may be the same CM server or two different CM servers, depending on the provisioning of the users on the core CM servers. Furthermore, additional application servers may be sequenced in the call flow by Session Manager if additional core sequenced applications are deployed by the enterprise. See the Avaya Aura Session Manager documentation for more information regarding the operation of the CM-FS or CM-ES with Session Manager, and regarding Session Manager application sequencing. 2. Centralized phone to IP Office user phone (dialing IP Office user phone s enterprise number) Centralized phone Session Manager CM-FS or CM-ES Session Manager IP Office IP Office user phone 3. Centralized phone to PSTN (using local trunking) Centralized phone Session Manager CM-FS or CM-ES Session Manager IP Office IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) PSTN 4. Centralized phone to PSTN (using centralized trunking) Centralized phone Session Manager CM-FS or CM-ES Session Manager central gateway/sbc PSTN Note: The IP Office is not involved in handling the call in this scenario. 5. Centralized phone to headquarters or other enterprise site Centralized phone Session Manager CM-FS or CM-ES Session Manager target phone s controller (if target phone does not register directly to SM) target phone Note: The IP Office is not involved in handling the call in this scenario. Calls to Centralized phones in normal mode (aka Sunny day) 1. From PSTN to centralized phone s DID (LDN is associated with local IP Office trunk) December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 57

58 Call flows PSTN IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) IP Office Session Manager CM-FS or CM-ES Session Manager centralized phone 2. From PSTN to centralized phone via IP Office auto-attendant (branch auto-attendant LDN is associated with local IP Office trunk) PSTN IP Office trunk (e.g. FXO, ISDN, SP SIP Trunk) IP Office auto-attendant caller enters extension number IP Office modifies extension number to user s enterprise number Session Manager CM-FS or CM-ES Session Manager centralized phone 3. From PSTN to centralized phone s DID (if LDN is ported to centralized trunks at the core) PSTN central gateway/sbc Session Manager CM-FS or CM-ES Session Manager centralized phone Note: The IP Office is not involved in handling the call in this scenario. 4. From branch IP Office user phone to centralized phone (dialing phone s enterprise number) IP Office user phone IP Office Session Manager CM-FS or CM-ES Session Manager centralized phone 5. From headquarters (or other enterprise site) to centralized phone s enterprise number Originating phone originating phone s controller Session Manager CM-FS or CM-ES Session Manager centralized phone Note: The IP Office is not involved in handling the call in this scenario. Calls from Centralized phones in survivability mode (aka Rainy day) 1. Centralized phone A to Centralized phone B in the same branch Centralized phone A IP Office centralized phone B Note: In Rainy day the centralized phones register to survivability service on the IP Office in the branch. 2. Centralized phone to IP Office user phone (dialing either IP Office user phone s enterprise number or short extension) Centralized phone IP Office IP Office user phone 3. Centralized phone to PSTN Centralized phone IP Office IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) PSTN 4. Centralized phone to headquarters or other enterprise site IP Office can be administered to send such calls over the PSTN. See below. Calls to Centralized phones in survivability mode (aka Rainy day) 1. From PSTN to centralized phone s DID PSTN IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) IP Office centralized phone 58 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

59 Centralized deployment example call flows Note: In Rainy day the centralized phones register to survivability service on IP Office in the branch. 2. From PSTN to centralized phone via IP Office auto-attendant PSTN IP Office trunk (e.g. FXO, ISDN, SP SIP trunk) IP Office auto-attendant caller enters extension number centralized phone 3. From branch IP Office user phone to centralized phone (dialing either IP Office user phone s enterprise number or short extension) IP Office user phone IP Office centralized phone Centralized deployment example call flows This section provides examples of call flows for a system that is configured in a centralized deployment. Routing concepts In the example network deployment provided in this section, all calls that are routed within Avaya Aura Session Manager are converted to E.164. The primary function for this is to support Tail-End- Hop-Off (TEHO). E.164 E.164 is a numbering format that is recommended by the International Telecommunications Union - Telecommunications (ITU-T). E.164 can have a maximum of 15 digits and is preceded by a +. Maximum of 15 digits (not including the preceding +). First part is a 1 to 3-digit country code. Second part is a national destination code. Last part is the subscriber number. Second and last parts are collectively known as the national number. Tail-End-Hop-Off (TEHO) TEHO is the process of routing a call through a private network to the closest node of the destination call, and then routing over the public network as a local call. Call flows The IP Office centralized solution revolves around SIP endpoints at a branch location that registers to a Session Manager. Local trunking is provided through the IP Office at the branch location. When December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 59

60 Call flows connectivity to the Session Manager is lost, the SIP endpoints failover and register to the IP Office for connectivity. Solution overview Figure 3: Solution overview showing the store network The Solution overview illustrates the store network. CM-1 represents a Communication Manager used for features for the store phones. CM-2 represents the primary Communication Manager used for corporate endpoints and PSTN trunking. SM represents all Session Managers. There must be at least: 1 or more Communication Managers 1 or more Session Managers 1 or more IP Offices SIP endpoints at each branch location 60 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

61 Centralized deployment example call flows Sunny day call flows The first set of call flows are for sunny day. This is when all SIP endpoints have full connectivity across the WAN back to the core and are registered to the Session Manager. All SIP trunks are in service. Internal call Figure 4: Sunny day internal call 1 Store Phone originates call to a corporate station SM sends to CM for origination processing. 3 CM identifies call as internal and routes back to SM. 4 SM sends call to destination phone at destination CM. A This call flow is similar for calls within the same branch or calls to other branches with the exception that the calls terminate at the destined branch. RTP Media stream is initially between the Store Phone and a CM-1 media gateway. This will shuffle between the Store Phone and CM-2 or another endpoint once established. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 61

62 Call flows Local PSTN dialing Figure 5: Sunny day local PSTN dialing 1 Store Phone calls local extension SM sends to CM for origination call processing. 3 CM translates the call into E.164 based on callers location and sends to SM. 4 SM adapts the call for the local carrier and sends back to original branch. Session Manager could use the E.164 formatted number to do TEHO routing at this step. 5 IP Office Branch sends to the PSTN. A B RTP Media stream is initially between the Store Phone and CM-1 media gateway. Once the call is established, the RTP Media stream will shuffle between the Store Phone and the IP Office Branch. 62 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

63 Centralized deployment example call flows Long distance and international Figure 6: Sunny day long distance and international 1 Store Phone calls long distance number SM sends to CM for origination call processing. 3 CM translates the call into E.164 based on callers location and sends to SM. 4 SM adapts the call for the local carrier and sends back to original branch. Session Manager could use the E.164 formatted number to do TEHO routing at this step. 5 IP Office Branch sends to the CO. A B RTP Media stream is initially between the Store Phone and CM-1 media gateway. Once the call is established, the RTP Media stream will shuffle between the Store Phone and the IP Office Branch. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 63

64 Call flows Incoming call Figure 7: Sunny day incoming call 1 Customer dials store extension (the branch phone number). 2 IP Office Branch sends call to VDN on CM via SM. Routing to a VDN allows reporting of branch calls. 3 SM matches call with a Route Pattern and sends to CM. 4 CM routes call to x-ported station that is bridged to all branch endpoints. (X-ported refers to AWOH (Admin With Out Hardware) stations that are administered as an endpoint without any physical hardware.) 5 SM sends call to all endpoints at the branch. A B RTP Media stream is initially between the Store Phone and CM-1 media gateway. Once the call is established, the RTP Media stream will shuffle between the Store Phone and the IP Office Branch. Sunny day: Centralized phone to Centralized phone within the branch In this scenario, the Centralized user that receives the call answers the call as expected. 64 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

65 Centralized deployment example call flows Figure 8: Media flow for a call from one Centralized user to another Centralized user within the same branch in Sunny day IP Office is not involved in this scenario. For the call signaling flow to work as expected, Avaya Aura Communication Manager must be configured for Initial IP-IP Direct Media. The following table shows the call signaling and media flow for this call scenario in more detail. Table 9: Call signaling flow description for Centralized phone to Centralized phone within the branch in Sunny day Call scenario User A makes a call to user B. The call connects successfully and user B answers the call as expected. Description of call signalling flow The following steps outline the call signaling flow shown in the image above. 1. Centralized Phone A makes a call to Centralized Phone B. 2. Avaya Aura Session Manager sends Phone B s number to Avaya Aura Communication Manager for processing. 3. Avaya Aura Communication Manager identifies the call as internal (within the branch) and routes Phone B s number back to Avaya Aura Session Manager. 4. Avaya Aura Session Manager sends the call invite to Phone B. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 65

66 Call flows Call scenario Description of call signalling flow 5. The user of Phone B answers the call. The RTP media stream flows directly between Phone A and Phone B. Related Links Direct media setting in Avaya Aura Communication Manager on page 49 Sunny Day: Centralized phone to PSTN number with Music on Hold The following image shows the call media flow for a call from a centralized phone to the local PSTN trunk in the branch. In this scenario, the call is put on hold with Music on Hold and then the call on hold is retrieved. The call on hold uses resources from the central gateway for Avaya Aura Communication Manager and local trunks in IP Office. Figure 9: Call signaling flow for centralized phone to PSTN number with Music on Hold Table 10: Call signaling flow description for Centralized phone to PSTN number with Music on Hold in a Sunny Day mode Call scenario User A makes a call to user B. The call connects successfully and user A puts the call on hold. Music on Hold plays in the background while the call is on hold. User A then retrieves the call on hold. Description of call signaling flow 1. Centralized Phone A calls the PSTN number, and sends an INVITE message to Avaya Aura Session Manager. 66 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

67 Centralized deployment example call flows Call scenario Description of call signaling flow 2. Session Manager sends an INVITE message with the PSTN number to Communication Manager for origination processing. 3. Communication Manager identifies the call as a PSTN number and uses the ARS table to route the PSTN number back to Session Manager. 4. Session Manager routes call to the destination SIP Entity that is IP Office, and thenip Office routes the call to the PSTN number. 5. After the call is established, RTP media stream is sent directly between Phone A and the PSTN number that is the IP Office number. 6. Phone A invokes Music on Hold by sending an INVITE tosession Manager with the PSTN number in the To header 7. Session Manager sends an INVITE to Communication Manager for the Music on Hold feature 8. Communication Manager exchanges H.248 messages with the gateway for Communication Manager to connect or reserve the Music on Hold resources. 9. Communication Manager sends back an INVITE to Session Manager to connect to the central gateway for Communication Manager. 10. Communication Manager exchanges more H.248 messages with the gateway for Communication Manager. 11. Session Managersends an INVITE to IP Office to connect to the central gateway of Communication Manager and put the call to PSTN with the Music on Hold feature. 12. The PSTN number is put on hold taking resources from the central gateway and using local trunks in IP Office. 13. Phone A sends an INVITE message to Session Manager to retrieve the call on hold. 14. Session Manager sends an INVITE to Communication Manager to retrieve the call from the call on hold status. 15. Communication Manager exchanges H.248 messages with the central gateway to disconnect or release the Music on Hold resources. 16. Communication Manager sends an INVITE message back to Session Manager to disconnect from the central gateway of Communication Manager. 17. Session Manager sends an INVITE to IP Office to disconnect to the central gateway of Communication Manager. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 67

68 Call flows Call scenario Description of call signaling flow 18. Communication Manager sends an INVITE message to Session Manager to connect to the centralized phone A. 19. Session Manager sends an INVITE message to Phone A and the call connects and retrieves from the previous state. 20. After the call is established, RTP media stream is set directly between Phone A and PSTN number that is in theip Office trunk. Rainy day call flows The next set of call flows are for Rainy day. In a Rainy day scenario, the SIP phones will failover to the IP Office in standalone mode. The standalone mode operates with a reduced SIP feature set which does not support all Sunny day features. In a Rainy day inbound call scenario, the process is as follows: an inbound call rings on all phones until that call is answered. Because bridged line appearances are not supported as a Rainy day feature, once that call is answered, the call will only appear on the active station, and all other stations will show idle. Note that all idle phones will continue to be available to make or answer incoming calls from the local PSTN or make and receive calls from within the store. Moving an answered call from one phone to another requires a transfer. Only internal store and PSTN dialing is supported, and any non-pstn extensions to extension dialing will not be routed. To dial any external number in Rainy day, users will need to dial 9 followed by the complete 7 or 10 digit number. Additionally, due to the dial plan convention adopted, any store to store calling, or calls from corporate locations, are only supported through the PSTN to the main CO lines provisioned. Without any additional programming, all 7 digit dialing from the corporate location or other retail store to a store operating in Rainy day will receive a wave-off tone. In order to mitigate this behavior the recommendation is to provide each station with a point of coverage that directs the calling party to primary DID for store where the extension resides. 68 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

69 Centralized deployment example call flows Incoming call failover, inbound call Figure 10: Rainy day inbound call 1 Customer dials store extension IP Office Branch sends the call directly to all registered SIP stations in the hunt group. A RTP Media is established between the Store Phone and the IP Office Branch. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 69

70 Call flows Incoming call from corporate coverage Figure 11: Rainy day incoming call from corporate user 1 Corporate user dials branch extension SM routes call to CM-1 for origination call processing. 3 CM-1 and SM identify that branch is unreachable. CM-1 routes call to coverage path for In this case the remote coverage path would be the E.164 formatted DID of the store SM sends the call back to the originating CM-2. SM adapts the call to a format that is routable at the local CM-2. 5 CM-2 sends the call to the PSTN. 6 Call is routed through the PSTN to the store through the local CO. 7 IP Office Branch routes the call to a hunt group. This hunt group in turn sends the call to all registered SIP stations at the branch. A RTP Media stream is established between the Store Phone and the IP Office Branch. 70 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

71 Centralized voice mail example call flows Centralized voice mail example call flows The following sections describe call flows for incoming calls transferred to Centralized voice mail systems. The call flow descriptions provided are examples only, and do not cover all possible scenarios. Sunny day call flows: Incoming call transferred to Avaya Aura Messaging or Avaya Modular Messaging IP Office systems deployed in Distributed, Centralized, and Mixed environments can be configured to use an Avaya Aura Messaging or Avaya Modular Messaging centralized voice mail system. The following sections describe Sunny day call and media flow scenarios for: Incoming call from centralized SIP phone to H.323 IP Office phone transferred to centralized voice mail Incoming call to ATA user in the same branch transferred to centralized voice mail Incoming call to centralized SIP user in the same branch transferred to centralized voice mail Sunny day: Incoming call from centralized SIP phone to H.323 IP Office phone transferred to centralized voice mail In this scenario, the call is transferred to a centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system in Sunny day. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 71

72 Call flows Figure 12: Call media flow for an incoming call from a centralized SIP phone to an H.323 IP Office phone The following table describes the call signaling flow in more detail. Table 11: Call signaling flow description for incoming call from a centralized SIP phone to an H.323 IP Office phone transferred to centralized voice mail in Sunny day Call scenario 1. SIP Centralized user A calls H.323 IP Office user B. 2. User B does not answer the call. 3. Call is forwarded to an Avaya Aura Messaging or Avaya Modular Messaging centralized voice mail system. 4. User A leaves a voice mail message for user B. 5. User A hangs up after leaving the message. 6. Message Waiting Indicator lights up on user B s phone to indicate that a new voice message is waiting. Description of call signalling flow 1. User A SIP Invite Session Manager Communication Manager Session Manager H. 323 IP Office user B. 2. Ringing IP Office phone Session Manager Communication Manager Session Manager user A. 3. SIP Invite sent from IP Office Session Manager centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system. 4. RTP is set up between user A, IP Office, and the voice mail system. 5. BYE is sent from user A Session Manager Communication Manager Session Manager IP Office Session Manager voice mail. 72 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

73 Centralized voice mail example call flows Call scenario Description of call signalling flow 6. NOTIFY is sent from voice mail Session Manager IP Office with Message Waiting Indication for user B. Sunny day: Incoming call to ATA phone transferred to centralized voice mail The following image shows the call media flow for a call to an ATA phone in the same branch. In this scenario, the call is transferred to a centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system in Sunny day. Figure 13: Sunny day incoming call to ATA phone transferred to centralized voice mail The following table describes the call signaling flow in more detail. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 73

74 Call flows Table 12: Call signaling flow description for incoming call to ATA phone transferred to centralized voice mail in Sunny day Call scenario 1. SIP Centralized user A calls SIP Centralized ATA user B. 2. User B does not answer the call. 3. Call is forwarded to an Avaya Aura Messaging or Avaya Modular Messaging centralized voice mail system. 4. User A leaves a voice mail message for user B. 5. User A hangs up after leaving the message. 6. Message Waiting Indicator lights up on user B s phone to indicate that a new voice message is waiting. Description of call signalling flow 1. User A SIP Invite Session Manager Communication Manager Session Manager IP Office user B. 2. Ringing ATA phone IP Office Session Manager Communication Manager Session Manager user A. 3. CANCEL is sent for the original invite and a new invite is sent from Communication Manager Session Manager centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system. 4. Media is set up between user A and the voice mail system. 5. BYE is sent from user A Session Manager Communication Manager Session Manager voice mail. 6. NOTIFY is sent from voice mail Session Manager Communication Manager PUBLISH to Session Manager NOTIFY IP Office user B with Message Waiting Indication. Sunny Day: Centralized SIP phone to Centralized SIP phone transferred to centralized voice mail In this scenario, User A calls User B. User B does not answer and the call is transferred to a centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system. The following image shows the call media flow for a call from a centralized user to another centralized user with coverage to voice mail. 74 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

75 Centralized voice mail example call flows Figure 14: Centralized user A call to centralized user B with coverage to voice mail The following table describes the call signaling flow in more detail. Table 13: Call signaling flow description for call from a centralized user to another centralized user with coverage to voice mail Call scenario 1. SIP centralized user A dials SIP centralized user B 2. User at station B does not answer the call. 3. Call is forwarded to an Avaya Aura Messaging or Avaya Modular Messaging centralized voice mail system. 4. User A leaves a voice mail message for user B. 5. User A hangs up after leaving the message. 6. Message Waiting Indicator lights up on user B s phone to indicate that a new voice message is waiting. Description of call signalling flow 1. User A SIP Invite Session Manager Communication Manager Session Manager user B. 2. Ringing user B Session Manager Communication Manager Session Manager user A. 3. A CANCEL message is sent for the original invite and a new invite is sent from Communication Manager Session Manager centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system. 4. RTP media is set up between user A, thecommunication Manager gateway, and the voice mail system. After a series of invites, RTP is set up between User A and the voice mail system. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 75

76 Call flows Call scenario Description of call signalling flow 5. BYE is sent from user A Session Manager Communication Manager Session Manager voice mail. 6. NOTIFY is sent from voice mail Session Manager Communication Manager PUBLISH to Session Manager NOTIFY user B with Message Waiting Indication status. Rainy day call flows: Incoming call transferred to Avaya Aura Messaging or Avaya Modular Messaging When configuring a branch to use Avaya Aura Messaging or Avaya Modular Messaging, an internal number is set for calls to the Centralized voice mail system to be automatically routed through the SM Line. You can also configure an additional PSTN number to ensure that calls to Avaya Aura Messaging or Avaya Modular Messaging are correctly routed to the PSTN trunk when the SM Line is not available. For configuration procedures, see Deploying Avaya IP Office Platform as an Enterprise Branch with Avaya Aura Session Manager. Rainy day media flow scenario The following image shows the media flow for an unanswered call in Rainy day. In this media flow scenario, the unanswered call is transferred to a Centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system. Important: This type of call flow scenario in Rainy day is not supported on CS 1000 Call Pilot voice mail systems. 76 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

77 Centralized voice mail example call flows Figure 15: Incoming call to IP Office phone transferred to Avaya Aura Messaging voice mail system In Rainy day, all station types (SIP, H.323, digital, and analog) are registered to IP Office. IP Office users and Centralized users leave and retrieve voice mails over the PSTN. In Rainy day conditions, DTMF digits indicate specific mailboxes, and the Message Waiting Indicator on the called user s phone does not light up. The following table describes the call signalling flow in more detail. Table 14: Call signaling flow description for incoming calls transferred to Avaya Aura Messaging in Rainy day Call scenario 1. User A dials user B. In this example, the call is local (from station to station), but the media flow would be the same for an inbound trunk call. 2. User at station B does not answer the call and the process of transferring the call to voice mail begins. 3. IP Office determines that the SM Line is not available and routes the call over the PSTN. 4. The call is routed from Communication Manager to Session Manager. Description of call signalling flow 1. Call from user A is routed to user B through the IP Office. 2. IP Office determines whether voice mail is enabled. 3. The PSTN voice mail number requires a corresponding Short Code or ARS entry for the call to be routed to the correct line in Rainy day. The PSTN number must be a valid DID number from the branch to the core voice mail system. 4. Communication Manager processes the incoming voice mail PSTN number and then transfers the number to Session Manager. 5. IP Office sends DTMF tones to Session Manager to indicate which mail box the call December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 77

78 Call flows Call scenario 5. The call is routed from Session Manager to the Avaya Aura Messaging or Avaya Modular Messaging voice mail system. Description of call signalling flow should be transferred to.session Manager then forwards the call to the Centralized Avaya Aura Messaging or Avaya Modular Messaging voice mail system. Note: IP Office must be administered to send voice mail instructions as DTMF tones. If this capability is disabled, DTMF digits are not sent automatically. Instead, the caller must manually dial the mail box number. ATA example call flows The following sections provide general call signaling and media flow information for an ATA phone to an IP Office PSTN trunk. The call flow descriptions provided in this section are examples only. This section does not cover all possible call flow scenarios for ATA users. Centralized ATA phone to IP Office PSTN trunk call flow A Centralized ATA phone is an analog phone for a Centralized user. 78 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

79 ATA example call flows Figure 16: Call signaling and media flow for calls from ATA phones to the IP Office PSTN trunk in Sunny day and Rainy day Sunny day In Sunny day, the IP Office transparently relays the dialed string from the ATA user s analog phone through the SIP INVITE sent to Avaya Aura Session Manager and then to Avaya Aura Communication Manager. This is shown in more detail in the following table. Table 15: Call signaling flow description for Centralized ATA phones Call scenario Call from ATA phone to IP Office PSTN trunk. The Centralized ATA user is registered with the IP address of IP Office. Description of call signaling flow SIP INVITE from IP Office Session Manager Communication Manager Session Manager IP Office PSTN For information about the call signaling and media flow with the Communication Manager call pickup feature, see ATA phone invoking Communication Manager call pick-up feature call flow on page 80. Rainy day In Rainy day, the SM Line is not available, so all call routing and media is handled directly by the IP Office. IP Office routes the call from the user s Centralized ATA phone to the IP Office PSTN trunk. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 79

80 Call flows ATA phone invoking Communication Manager call pick-up feature call flow In Sunny day, users can invoke the Communication Manager call pick-up feature by dialing a Communication Manager Feature Access Code (FAC) or Feature Name Extension (FNE) on the ATA user s phone. IP Office does not process the dialed string or identify the Communication Manager feature accessed. Figure 17: ATA call media flow with the Communication Manager call pick-up feature The media flows between the headquarters user A and the ATA user in the branch through IP Office. IP Office connects and interworks the media flow on the IP network side with the TDM media on the connection to the ATA user s phone. The call signaling and media flow is shown in more detail in the following table. Table 16: Call signaling flow description for call pick-up feature with Centralized ATA phones Call scenario 1. Headquarters user A in the data center makes a call to Centralized SIP user (B) in the branch. 2. ATA user hears the Centralized SIP phone (B) ringing and wants to answer the call on their Description of call signaling flow 1. User A Communication Manager SIP INVITE to Session Manager Centralized SIP user (B) 80 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

81 SRTP example call flows Call scenario ATA phone. So the ATA user dials a FAC to invoke the Communication Manager call pick-up feature and answer the call. 3. Centralized SIP user (B) and the ATA user in the branch are in the same call pick-up group, so Communication Manager delivers the call directly to the ATA user and cancels the call previously delivered to user B. Description of call signaling flow 2. SIP INVITE carrying FAC sent from IP Office Session Manager Communication Manager 3. Communication Manager SIP 200 OK message to Session Manager IP Office ATA user The Communication Manager call pick-up feature is not supported in Rainy day. SRTP example call flows This section describes the following SRTP call flows: Centralized SIP phone to IP Office PSTN trunk in Sunny day and Rainy day. IP Office user with IP phone to headquarters (HQ) user outside the branch in Sunny day. This call flow option is not available in Rainy day. This section highlights a few key SRTP call flow examples. Other call flow scenarios not directly described in this section are also possible. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 81

82 Call flows Centralized SIP phone to IP Office PSTN trunk Figure 18: Call media flow: Centralized SIP phone to IP Office PSTN trunk in Sunny day and Rainy day Sunny day In Sunny day, the following conditions must be met for the media session to use SRTP between the Centralized SIP phone and the IP Office: Signalling is done over TLS via Avaya Aura Session Manager and the core Avaya Aura Communication Manager Regardless of whether Communication Manager is configured for Initial Direct Media or IP-IP audio (shuffling), signaling and Media Encryption should be configured consistently on Communication Manager, the central Communication Manager Media Gateway, Session Manager, IP Office, and the Centralized SIP phone. The media session flow uses SRTP between the Centralized SIP phone and the IP Office. IP Office connects and interworks the SRTP flow on the IP network side with the TDM media on the PSTN trunk. The following table describes the media flow for the possible call flow scenarios. Table 17: SRTP call flow scenarios Call flow scenario Communication Manager is configured for Initial Direct Media SRTP media flow SRTP media flows directly from the Centralized SIP phone IP Office 82 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

83 SRTP example call flows Call flow scenario Communication Manager is configured for direct IP-IP audio (or shuffling), but not for Initial Direct Media SRTP media flow Two stages: 1. At the beginning of each call, media initially flows across the WAN through a Communication Manager central media resource, such as the G450 Media Gateway. 2. Once Communication Manager shuffles the call, the SRTP media flows directly from the Centralized SIP phone IP Office. Rainy day In Rainy day, the following conditions must be met for the media session to use SRTP between the Centralized SIP phone and the IP Office: Signalling is over TLS. In Rainy day, this is supported with 9600 Centralized SIP phones, but not with the Centralized SIP Avaya one-x Communicator. Media Encryption is configured on the IP Office and on the Centralized SIP phone. The media session flow uses SRTP between the Centralized SIP phone and the IP Office. IP Office connects and interworks the SRTP flow on the IP network side with the TDM media on the PSTN trunk. Related Links Bandwidth requirements on page 47 IP Office user with IP phone to headquarters user outside the branch Sunny day The call flow is similar if the call is made to the IP Office SIP trunk rather than the IP Office IP phone. This call flow scenario is not supported in Rainy day. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 83

84 Call flows Figure 19: SRTP call flow: IP Office to HQ user outside the branch in Sunny day In Sunny day, the following conditions must be met for the call signalling to negotiate the use of SRTP between IP Office and the HQ user s phone: Signalling is done on the SM Line over TLS Regardless of whether Communication Manager is configured for Initial Direct Media or IP-IP audio (shuffling), signaling and Media Encryption should be configured consistently on Communication Manager, the central Communication Manager Media Gateway, Session Manager, IP Office, and the Centralized SIP phone. IP Office negotiates SRTP separately for each call leg. SRTP is not supported to and from local IP Office user IP endpoints, so the media flow between the IP Office and the IP endpoint of the IP Office user always uses RTP. This call flow scenario has two legs, as described in the following table. Description of call leg Call Leg 1: IP endpoint (SIP or H.323) of the IP Office user Office IP Media flow: RTP or SRTP RTP Call Leg 2: IP Office HQ user s phone SRTP IP Office negotiates SRTP separately for each call leg. For example, SRTP is disabled for the endpoint of the local IP Office user, or the IP Office user uses an endpoint type in which SRTP is not supported. In such a case, the media flow between IP Office and the IP endpoint of the IP Office user will use RTP. 84 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014

85 Toll bypass functionality Toll bypass functionality The toll bypass functionality is supported only in SCN and Branch deployments. By default, the India Toll Bypass Prevention feature is applied for the India locale and disabled for other locales, but you can apply the feature for any locale. System level configuration guidelines You can create an extension for a new location by selecting Extension > Extn > Extension Location. You can apply the toll bypass functionality at the system level by selecting the Restrict Network Interconnect and Include location specific information check boxes. Trunk level configuration guidelines The Trunk Level Include location specific check box is present on the IP Office line and SM Line or on the Line tab. This option is available only if the Network type is set to Private in an Enterprise trunk. If the line is a PSTN trunk that includes SIP, then you must set the Network type of the trunk to Public. Note: Select the Trunk Level Include location specific check box only if the other end is an IP Office, Session Manager R6.3 or higher, or Communication Manager R6.3 or higher. If the other end of the trunk is not toll compliant, then clear the Include location specific check box. Troubleshooting toll bypass You can check the call status using SSA. Logs of rejected calls because of the toll bypass restriction are stored on SysMonitor with originating, terminating, and call type (public/private) details. SysMonitor is the primary tool for checking and troubleshooting rejected calls. The following are the recommended trace options: Default All Call tab, Supplementary services SIP, Events Verbose Related Links Toll bypass call flows on page 85 Toll bypass call flows The new enhancements in the IP Office Restrict Network Interconnect feature apply to endpoints and trunks. Calls can be made to or from IP phones to local PSTN public trunks only if the location of the IP phone is the same as the system location. No extra licenses are introduced as part of this enhancement. The feature is supported on both IP500V2 and IPOL and in all the editions such as Essential, Preferred, or Select. December 2014 Avaya IP Office Platform in a Branch Environment Reference Configuration 85

86 Call flows Figure 20: PSTN call flow between an IP Office users and a Centralized user in the same location A Distributed user, A, receives a PSTN call originating from Site A. The Distributed user, A, forwards the call to a Centralized user, C, in Site A. This PSTN call is allowed because the locations of the originating call and the terminating call are the same. Figure 21: PSTN call flow between two IP Office users in different locations A Distributed user, A, receives a PSTN call originating from Site A. The Distributed user, A, forwards the call to a Distributed user, E, in Site B. This PSTN call is not allowed because the locations of the originating call and the terminating call are different. 86 Avaya IP Office Platform in a Branch Environment Reference Configuration December 2014