Avaya Session Border Controller for Enterprise 7.1 SP5 Release Notes

Release 7.1 SP5 Issue 1 July 2018

Notice

While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to the information in this document might be incorporated in future releases.

Documentation disclaimer

Avaya Inc. is not responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications, additions, or deletions were performed by Avaya. Customer and/or End User agree 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 the Customer or End User.

Link disclaimer

Avaya Inc. is not responsible for the contents or reliability of any linked Web sites referenced elsewhere within this documentation, and Avaya does not necessarily endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all the time and we have no control over the availability of the linked pages.

Warranty

Avaya Inc. provides a limited warranty on this product. 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 through the Avaya Support Web site: http://support.avaya.com

License

USE OR INSTALLATION OF THE PRODUCT INDICATES THE END USER'S ACCEPTANCE OF THE TERMS SET FORTH HEREIN AND THE GENERAL LICENSE TERMS AVAILABLE ON THE AVAYA WEB SITE http://support.avaya.com/LicenseInfo/ ("GENERAL LICENSE TERMS"). IF YOU DO NOT WISH TO BE BOUND BY THESE TERMS, YOU MUST RETURN THE PRODUCT(S) TO THE POINT OF PURCHASE WITHIN TEN (10) DAYS OF DELIVERY FOR A REFUND OR CREDIT.

Avaya grants End User a license within the scope of the license types described below. 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 End User. "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. "Software" means the computer programs in object code, originally licensed by Avaya and ultimately utilized by End User, whether as stand-alone Products or pre-installed on Hardware. "Hardware" means the standard hardware Products, originally sold by Avaya and ultimately utilized by End User.

License type(s)

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 e-mail 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 Product that permits one user to interface with the Software. Units may be linked to a specific, identified Server.

Except where expressly stated otherwise, the Product is protected by copyright and other laws respecting proprietary rights. Unauthorized reproduction, transfer, and or use can be a criminal, as well as a civil, offense under the applicable law.

Third-party components

Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements ("Third Party Components"), which may contain terms that expand or limit rights to use certain portions of the Product ("Third Party Terms"). Information identifying Third Party Components and the Third Party Terms that apply to them is available on the Avaya Support Web site: http://support.avaya.com/ThirdPartyLicense/

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 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 +1-800-643-2353 for the United States and Canada. For additional support telephone numbers, see the Avaya Support Web site: http://support.avaya.com

Trademarks

Avaya and the Avaya logo are either registered trademarks or trademarks of Avaya Inc. in the United States of America and/or other jurisdictions. All other trademarks are the property of their respective owners.

Downloading documents For the most current versions of documentation, see the Avaya Support Web site: http://support.avaya.com

Avaya support

Avaya provides a telephone number for you to use to report problems or to ask questions about your product. The support telephone number is 1-800-242-2121 in the United States. For additional support telephone numbers, see the Avaya Support Web site: http://support.avaya.com

Table of Contents Overview...... 5 Documentation ...... 6 Upgrade path ...... 7 For 7.1 SP1 and 7.1 SP2 release to 7.1 SP5 upgrade using GUI...... 13 Rollback path ...... 13 Download files ...... 15 List of Fixed Issues ...... 16 Known Issues ...... 16

Overview This document provides information about the new enhancements in ASBCE Release 7.1 Service Pack 5, and the known issues for this release. This build is only for JITC customers and supported with only DoD profile, with Normal profile this service pack features are not supported.

Following are the main features released in 7.1 Service Pack 5:

• Character encoding interworking: SIP is a text-based protocol and uses the UTF-8 charset. When SBC receives the SIP message which has certain headers/fields in a different character encoding, it should be able to convert those byte sequences in the SIP message to UTF-8 encoding. • Enterprise Authentication and Authorization based on LDAP service • Certificate Based Authentication for GUI and CLI users

Documentation The latest documentation for 7.1 is available on support.avaya.com.

No. Title Link

1. Avaya Session Border Controller for Enterprise Overview and Specification http://support.avaya.com/css/P8/documents/101026875

2. Deploying Avaya Session Border Controller for Enterprise http://support.avaya.com/css/P8/documents/101026879

3. Deploying Avaya Session Border Controller in Virtualized Environment http://support.avaya.com/css/P8/documents/101026877

4. Upgrading Avaya Session Border Controller for Enterprise http://support.avaya.com/css/P8/documents/101026883

5. Administering Avaya Session Border Controller for http://support.avaya.com/css/P8/documents/101026873 Enterprise

6. Troubleshooting and Maintaining Avaya Session Border Controller for http://support.avaya.com/css/P8/documents/101026881 Enterprise

7. Avaya SBCE 7.x Security Configuration and Best Practices Guide https://downloads.avaya.com/css/P8/documents/101014066

Upgrade path

1. Avaya SBCE with releases prior to 7.1 SP1 or 7.1 SP2 must be upgraded to 7.1 SP2 release. Following upgrade paths are supported: 1. 7.1 SP1  7.1 SP5 (GUI &CLI both supported, GUI is recommended). 2. 7.1 SP2  7.1 SP5 (GUI &CLI both supported, GUI is recommended).

Upgrade Instructions

Upgrades are supported on both, Hardware deployment as well as VMware deployment. Please make sure that the system being upgraded does support the upgrade path mentioned above and all upgrades need to be done during a maintenance window. If an upgrade is performed on a production system, it is quite likely that active/ongoing calls will be dropped. For information about the latest releases for 7.1, please refer http://support.avaya.com.

Note: Before starting with the upgrade, ensure that Avaya SBCE servers in the deployment have unique hostnames. In case two or more servers have the same hostname, change the hostname. For more information, see Troubleshooting and Maintaining Avaya Session Border Controller. Also, please take a snapshot of the systems before proceeding with the upgrade.

In a multi-server deployment, the upgrade sequence for 7.1.X releases is:

1. Primary EMS 2. Secondary EMS 3. Avaya SBCE pair: a. Avaya SBCE with lower node ID b. Avaya SBCE with higher node ID

Note: (applicable for CLI, in GUI method lower node is selected automatically)You can find the node IDs in /usr/local/ipcs/etc/sysinfo. Before upgrading, ensure that the EMS or Avaya SBCE with lower node id is secondary to avoid losing ongoing calls.

Note: Please refer “Upgrading Avaya Session Border Controller for Enterprise” document on Avaya Support site for procedure to upgrade the SBCE to latest version

Upgrade EMS and SBCE using CLI:

Pre-requisites:

➢ PRE-REQ_1: Customers with hotfix (sbce-7.1.0.1-07-hotfix-12222016.tgz ) installed on top of 7.1 SP1 release, must follow below steps as pre-requisite to start the upgrade:

a. Check whether hotfix “sbce-7.1.0.1-07-hotfix-12222016.tgz” is installed on the server by executing “ipcs-version” command, then verify that application shows up version as “Application : 7.1.0.1-12805”. The output of “ipcs-version” command is as follows:

[ipcs@hostname ~]$ ipcs-version SBCE Version : 7.1.0.1-07-12368 GUI : 7.1.0.1-12624 Database : 7.1.0.1-12368 Kernel : 2.6.32-642.11.1.el6.AV1 Application : 7.1.0.1-12805 ICU : 7.1.0.1-12815 PCF Module : 7.1.0.1-12604

b. Run the following commands on EMS and SBCE’s, before initiating the upgrade

i. Login to EMS/SBCEs and then switch to root using “su – root” ii. “touch /archive/SBC-RPM-Repository/RPMs/sbce-bin-7.1.0.1- 12937.x86_64.rpm”

➢ PRE-REQ_2: If ASG is enabled on SBCE, perform below procedure before initiating upgrade.

a. Login to EMS and SBCE and switch user to root login. b. Move /etc/asg/lacfile to /archive/backup/

mv /etc/asg/lacfile /archive/backup

c. Disable ASG Authentication.

Sbce-asg-control.py –u d. After performing above steps from 1 to 3 and making sure other prerequisites are checked, the upgrade can be started.

Note: To restore ASG authentication after the SBCE is upgraded to 7.1 SP5, copy the lacfile to /etc/asg/ directory using below command while logged in as root user. mv /archive/backup/lacfile /etc/asg/

Procedure:

1. Copy the Upgrade package, GPG signature file (ending with .asc file extension) and Key Bundle file to /home/ipcs directory on the respective device (EMS, SBCEs) using ipcs user on port 222. You can use SFTP or SCP tools to access the server. 2. Connect to the system using SSH client. 3. Using root login, move the upgrade tar file and GPG signature file (ending with .asc file extension) from the /home/ipcs directory to /archive/urpackages directory. 4. Ensure that the md5sum of the upgrade tar file matches the checksum given in the name of the file. You can use the md5sum command to verify whether the md5sum and the checksum match. 5. Create directory ‘sig’ under /home/ipcs directory.

mkdir /home/ipcs/sig

6. Copy and untar Key Bundle file i.e. sbce-x.x.x.x-xx-xxxxx-signatures.tar.gz tarball in /home/ipcs/sig. 7. Change directory to /home/ipcs/sig.

# cd /home/ipcs/sig

# tar -zxvf sbce-7.1.0.5-01-15824-signatures.tar.gz

8. Run the below commands as root user to install the file.

# rpm --import RPM*

# cp –rf /home/ipcs/sig/RPM* /etc/pki/rpm-gpg/

9. Check whether the /usr/local/ipcs/temp directory exists. If it does not exist, create the directory by using the following command:

# mkdir /usr/local/ipcs/temp

10. As a root user delete the files in /usr/local/ipcs/temp directory

# rm -rf /usr/local/ipcs/temp/*

11. Untar the upgrade package to /usr/local/ipcs/temp.

# tar -zxvf /archive/urpackages/sbce-7.1.0.5-01-15824- 45ffd3a04794025a869931364b324877.tar.gz -C /usr/local/ipcs/temp/

The system extracts the upgrade tar file in the temporary directory.

12. Change the permission of ursbce file to make it executable

# cd /usr/local/ipcs/temp

# chmod +x ursbce.py

13. Start the upgrade using ursbce.py script.

#./ursbce.py --upgrade --daemonize

This step will reboot the system.

For upgrade from 7.1 SP1 to 7.1 SP5 and 7.1 SP2 to 7.1 SP5 follow standard GUI upgrade procedure. Refer below section i.e. “Upgrading EMS and SBCE using GUI”.

Upgrading EMS and SBCE using GUI

Pre-requisites:

➢ PRE-REQ_1: Customers with hotfix (sbce-7.1.0.1-07-hotfix-12222016.tgz )installed on top of 7.1 SP1 release, must follow below steps as pre-requisite to start the upgrade:

b. Run the following commands on EMS and SBCEs, before initiating the upgrade i. Login to EMS/SBCEs and then switch to root using “su – root” ii. “touch /archive/SBC-RPM-Repository/RPMs/sbce-bin-7.1.0.1-12937.x86_64.rpm”

➢ PRE-REQ_2: If ASG is enabled on SBCE, perform below procedure before initiating upgrade. a. Login to EMS and SBCE and switch user to root login. b. Move /etc/asg/lacfile to /archive/backup/

mv /etc/asg/lacfile /archive/backup

c. Disable ASG Authentication.

Sbce-asg-control.py –u d. After performing above steps from 1 to 3 and making sure other prerequisites are checked, the upgrade can be started.

Note: To restore ASG authentication after the SBCE is upgraded to 7.1 Sp2, copy the lacfile to /etc/asg/ directory using below command while logged in as root user. mv /archive/backup/lacfile /etc/asg/

Before you begin Download the Upgrade package, GPG signature file (ending with .asc file extension) and Key Bundle file i.e. sbce-x.x.x.x-xx-xxxxx-signatures.tar.gz file to a local or remote PC using Avaya Product Licensing and Delivery System (PLDS). Please refer to Download files section for information on files to be downloaded.

About this task Uploading larger files using a browser can sometimes be unreliable, especially when using older browser versions such as Internet Explorer (IE7, IE8), or Firefox 3.x. Uploading large files through a browser might result in a failed upload or checksum error.

Note: The GPG signature file i.e. sbce-7.1.0.5-01-15824- 45ffd3a04794025a869931364b324877.tar.gz.asc and Key Bundle file i.e. sbce-7.1.0.5-01- 15824-signatures.tar.gz file are only required for upgrade from 7.1 SP1.

Upgrading EMS:

Procedure 1. Log in to the EMS web interface with administrator credentials. 2. In the left navigation pane, click System Management. The system displays the System Management screen. 3. Click the Key Bundles tab. 4. In Upload Key Bundle, click the Choose File button to upload Key Bundle File (sbce-7.1.0.5-01- 15824-45ffd3a04794025a869931364b324877.tar.gz.asc). 5. Click Upload. 6. Click the Updates tab. 7. In System Upgrade, select Upgrade from uploaded file. 8. Upload the Upgrade package by clicking on the Choose File button. Navigate to the folder containing the downloaded upgrade file and upload it. 9. Upload the Signature file by clicking on the Choose File button. Navigate to the folder containing the downloaded GPG signature file (sbce-7.1.0.5-01-15824- 45ffd3a04794025a869931364b324877.tar.gz.asc) and upload it. 10. Click Upgrade. The system starts uploading package and shows the status of upload in a pop-up window. 11. After the package gets uploaded successfully, click Start Upgrade. The system displays Upgrade Status screen with the upgrade log file in a viewable window. After the upgrade is complete, the system displays the Return to EMS tab. 12. Click Return to EMS to log back in to EMS. 13. Login to EMS and verify the version to see if upgrade was successful.

Upgrading HA SBCE Pairs

Before you begin Ensure that EMS servers are upgraded before upgrading HA pairs and status of HA SBCEs is “Commissioned (Upgrade required)”

Avaya SBCE pair in HA, repeat the procedure for each HA pair. Procedure 1. In the Updates tab, click System Management and then click Upgrade. The system displays the Upgrade Devices window. 2. Select the check box for HA-SBC device to be upgraded. Note: SBCE automatically chooses the SBCE out of a HA SBCE pair that needs to be upgraded first and allows the user to choose only that SBCE. The checkbox for the other SBCE in HA pair is greyed out. 3. Click Next. The system displays a window that states that the Device is upgraded. 4. Click Finish. The system displays the Upgrade Devices window. 5. Select the check box for the other SBCE in HA pair to be upgraded. 6. Click Next. The system displays the message that the Device is upgraded. 7. Click Finish. After the EMS software has been upgraded, the system displays the following status for SBC boxes and HA pairs on the Updates tab: One or more devices are in an upgrade required state. If you would like to upgrade these devices now, please click the Upgrade button below. You may also choose to rollback your EMS at this point. HA system pairs and all other SBC systems must be upgraded before this message is resolved.

Upgrading Avaya SBCE servers

Before you begin Ensure that the EMS servers are upgraded before upgrading Avaya SBCE servers. About this task This procedure upgrades Avaya SBCE servers that are not in an HA pair. When more than one Avaya SBCE server is available, repeat this step for each Avaya SBCE server. Procedure 1. In the left navigation pane, click System Management > Upgrade. The system displays the Upgrade Devices message box. 2. Select the check box next to the devices that you want to upgrade. The devices can be upgraded one at a time or as a group. If you select more than one device, the devices are put in a queue and upgraded one at a time. 3. Click Next. The system displays a message box indicating that the device is upgraded. 4. Click Finish. After the EMS software has been upgraded, the following message is displayed for SBC boxes and HA pairs on the Updates tab: One or more devices are in an upgrade required state. If you would like to upgrade these devices now, please click the Upgrade button below. You may also choose to rollback your EMS at this point. HA system pairs and all other SBC servers must be upgraded before this message is resolved.

For 7.1 SP1 and 7.1 SP2 release to 7.1 SP5 upgrade using GUI

Please refer the “Upgrading EMS and SBCE using a GUI” section.

Rollback path

Following rollback paths are supported:

1. Rollback from 7.1 SP5 7.1 SP1 2. Rollback from 7.1 SP5 7.1 SP2

For more information refer to Rollback procedure.

Note: SBCE with lower node id is rolled back first. Node id can be found in /usr/local/ipcs/etc/sysinfo file.

Rollback sequence

In a multi-server deployment, the rollback sequence is:

1. Primary EMS 2. Secondary EMS 3. Avaya SBCE pair: c. Avaya SBCE with lower node ID d. Avaya SBCE with higher node ID

You can find the node IDs in /usr/local/ipcs/etc/sysinfo. Before upgrading, ensure Avaya SBCE with lower node id is secondary to avoid losing ongoing calls in HA setup.

Rollback from 7.1 SP5 to 7.1 SP1

Procedure 1. Create a temp folder in path /usr/local/ipcs/ 2. Untar the rollback package to temp directory. cd /usr/local/ipcs/temp tar –zxvf /archive/urpackages/<7.1 Sp1 package.tar.gz> 3. Run pre rollback script. sh /usr/local/ipcs/icu/scripts/pre_rollback.sh 4. Run the ursbce.py script for rollback ./ursbce.py --rollback --daemonize

Rollback from 7.1 SP5 to 7.1 SP2:

Procedure 1 Create a temp folder in path /usr/local/ipcs/ 2 Untar the rollback package to temp directory. cd /usr/local/ipcs/temp tar –zxvf /archive/urpackages/<7.1 Sp2 package.tar.gz> 3 Run pre rollback script. sh /usr/local/ipcs/icu/scripts/pre_rollback.sh 4 Run the ursbce.py script for rollback ./ursbce.py --rollback --daemonize

Download files

Name Description sbce-7.1.0.5-01-15824- Upgrade file required for upgrading to 7.1 SP5. 45ffd3a04794025a869931364b324877.tar.gz Download ID: SBCE0000076 md5sum: 45ffd3a04794025a869931364b324877

sbce-7.1.0.5-01-15824-signatures.tar.gz This is a signatures tar file that consists of required integrity check keys used for all packages on SBCE Download ID: SBCE0000077 system. It is uploaded in key bundles under System management. md5sum: e1d06ff12d039490ef5fc42acea8e771 This signature file shall be used for upgrades from 7.1 SP1.

sbce-7.1.0.5-01-15824- SHA2 Signature for Upgrade Package. This will be used 45ffd3a04794025a869931364b324877.tar.gz.asc to validate the upgrade package integrity. This ASC file shall be used for upgrades from 7.1 SP1 and 7.1 SP2. Download ID: SBCE0000078 md5sum: 45ffd3a04794025a869931364b324877

List of Fixed Issues

The following table summarizes the issues fixed in this release:

Defect ID Summary

RHEL Security Updates RHSA-2018:1062 RHEA-2018:2300: microcode_ctl enhancement update RHEA-2018:1934 : microcode_ctl bug fix and enhancement update

AURORA-13464 RHEA-2018:1922: ca-certificates bug fix update RHSA-2018:1929: libvirt security update RHSA-2018:1124: python-paramiko security update High- RHSA-2018-2180 gnupg2 [RHSA-2018:0169-01] Important: kernel security and bug fix update

AURORA-13189 RHSA-2018:2164 : High- RHSA-2018-2164 kernel SPECTRE RHSA-2018:1651

AURORA-13139 [RHSA-2018:0101-01] Important: bind security update [RHSA-2018:0095-01] Important: java-1.8.0-openjdk security update

AURORA-13127 RHSA-2018:2241: Moderate: java-1.8.0-openjdk security update [RHSA-2018-0008]:High kernel security update

AURORA-12989

AURORA-11735 [RHSA-2017:1679-01] [RHSA-2017:1202-01] Important: bind security update [RHSA-2018:0469-01] Important: dhcp security update

AURORA-13453 RHBA-2018:2163: dhcp bug fix update

AURORA-13444 Package Updates (NIIST and OpenSCAP)

AURORA-13446 Update BouncyCastle to 1.59

AURORA-13445 AURORA-13444 Update Tomcat to 8.5.28 AURORA-14221 Build to build upgrade support AURORA-14200 Remote worker traffic started on DELL 210 with release 7.1.0.5-01-15705. AURORA-14074 Traffic ran for 17 hours and looks like SBC crash on primary and secondary same time and again primary sbc became primary and secondary became secondary

Known Issues

• For ASG enabled systems: a. init, craft, inads, sroot login from CONSOLE works fine. b. init, craft, inads login works fine on ssh login. We have to press Enter thrice at login prompt to get the challenge and product id. c. init, craft, inads login works fine from the GUI, when tomcat is restarted as user root, this is a work around with 7.1 SP5 release. d. After logging in as user init with asg challenge and response, su - sroot, will not give challenge and response. This is a known limitation. If there is a requirement to login as sroot, please login directly as user sroot to get challenge and response from the console. 16 © 2018 Avaya Inc. All Rights Reserved.

• Adding a new SBCE on 7.1 SP5 EMS fails 1. Before adding new SBCE to 7.1 EMS, upgrade new SBCE to 7.1 SP5 from CLI by using the following steps. 2. Copy 7.1 SP5 upgrade package to new SBCE using ipcs user login on port 222. 3. Login into SBCE and switch user to root. 4. Move the 7.1 SP5 upgrade to /archive/urpackages. mv /home/ipcs/ /archive/urpackages/ 5. Clear /usr/local/ipcs/temp directory and extract the 7.1 SP5 upgrade package into it. rm –rf /usr/local/ipcs/temp tar –xvzf -C /usr/local/ipcs/temp cd /usr/local/ipcs/temp 6. Start the upgrade by running below command. ./ursbce_ignoreNodeId.py -U --IgnoreNodeId --daemonize" 7. After the SBCE gets upgrade successfully, add the SBCE to existing EMS.

• Others

Issue Summary Workaround

AURORA- This can be worked around by adding a Reverse Proxy SP5 : Not able to add

Policy entry (under Global Profiles). Using the default 13630 reverse proxy values is fine. DoD Password restrictions AURORA- are not applied for SBC

Change the password using SBCEConfigurator.py script. 13548 which is on 7.1.0.4-01- 14973 with DoD profile. Remote workers are in Here the issue is related to MAC address changed in VM AURORA- down state after upgrading Environment. It's possible that the interfaces might

13519 form 7.1 SP1(with hot fix change in virtual environment and this would cause the 12222016) to SP4-7.1.0.4- passphrase to change which cannot be used to decrypt 01-14973 build the private key. Workaround is re-installing certificates.