configuration — survivable sip proxy (ssp)

Configuration — Survivable SIP Proxy(SSP)

SE13NN42100-506, 02.02

September 2010

© 2010 Avaya Inc.

All Rights Reserved.

Notice

While reasonable efforts have been made to ensure that theinformation in this document is complete and accurate at the time ofprinting, Avaya assumes no liability for any errors. Avaya reserves theright to make changes and corrections to the information in thisdocument without the obligation to notify any person or organization ofsuch changes.

Documentation disclaimer

“Documentation” means information published by Avaya in varyingmediums which may include product information, operating instructionsand performance specifications that Avaya generally makes availableto users of its products. Documentation does not include marketingmaterials. Avaya shall not be responsible for any modifications,additions, or deletions to the original published version ofdocumentation unless such modifications, additions, or deletions wereperformed by Avaya. End User agrees to indemnify and hold harmlessAvaya, 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, statementor content provided on these sites and does not necessarily endorsethe products, services, or information described or offered within them.Avaya does not guarantee that these links will work all the time and hasno control over the availability of the linked pages.

Warranty

Avaya provides a limited warranty on its Hardware and Software(“Product(s)”). Refer to your sales agreement to establish the terms ofthe limited warranty. In addition, Avaya’s standard warranty language,as well as information regarding support for this Product while underwarranty is available to Avaya customers and other parties through theAvaya Support Web site: http://support.avaya.com. Please note that ifyou acquired the Product(s) from an authorized Avaya reseller outsideof the United States and Canada, the warranty is provided to you bysaid Avaya reseller and not by Avaya.

Licenses

THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYAWEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO/ AREAPPLICABLE TO ANYONE WHO DOWNLOADS, USES AND/ORINSTALLS AVAYA SOFTWARE, PURCHASED FROM AVAYA INC.,ANY AVAYA AFFILIATE, OR AN AUTHORIZED AVAYA RESELLER(AS APPLICABLE) UNDER A COMMERCIAL AGREEMENT WITHAVAYA OR AN AUTHORIZED AVAYA RESELLER. UNLESSOTHERWISE AGREED TO BY AVAYA IN WRITING, AVAYA DOESNOT EXTEND THIS LICENSE IF THE SOFTWARE WAS OBTAINEDFROM ANYONE OTHER THAN AVAYA, AN AVAYA AFFILIATE OR ANAVAYA AUTHORIZED RESELLER; AVAYA RESERVES THE RIGHTTO TAKE LEGAL ACTION AGAINST YOU AND ANYONE ELSEUSING OR SELLING THE SOFTWARE WITHOUT A LICENSE. BYINSTALLING, DOWNLOADING OR USING THE SOFTWARE, ORAUTHORIZING OTHERS TO DO SO, YOU, ON BEHALF OFYOURSELF AND THE ENTITY FOR WHOM YOU ARE INSTALLING,DOWNLOADING OR USING THE SOFTWARE (HEREINAFTERREFERRED TO INTERCHANGEABLY AS “YOU” AND “END USER”),AGREE TO THESE TERMS AND CONDITIONS AND CREATE ABINDING CONTRACT BETWEEN YOU AND AVAYA INC. OR THEAPPLICABLE AVAYA AFFILIATE (“AVAYA”).

Copyright

Except where expressly stated otherwise, no use should be made ofmaterials on this site, the Documentation, Software, or Hardwareprovided by Avaya. All content on this site, the documentation and theProduct provided by Avaya including the selection, arrangement anddesign of the content is owned either by Avaya or its licensors and isprotected by copyright and other intellectual property laws including thesui generis rights relating to the protection of databases. You may notmodify, copy, reproduce, republish, upload, post, transmit or distributein any way any content, in whole or in part, including any code andsoftware unless expressly authorized by Avaya. Unauthorizedreproduction, transmission, dissemination, storage, and or use withoutthe express written consent of Avaya can be a criminal, as well as acivil offense under the applicable law.

Third-party components

Certain software programs or portions thereof included in the Productmay contain software distributed under third party agreements (“ThirdParty Components”), which may contain terms that expand or limitrights to use certain portions of the Product (“Third Party Terms”).Information regarding distributed Linux OS source code (for thoseProducts that have distributed the Linux OS source code), andidentifying the copyright holders of the Third Party Components and theThird Party Terms that apply to them is available on the Avaya SupportWeb site: http://support.avaya.com/Copyright.

Preventing Toll Fraud

“Toll fraud” is the unauthorized use of your telecommunications systemby an unauthorized party (for example, a person who is not a corporateemployee, agent, subcontractor, or is not working on your company'sbehalf). Be aware that there can be a risk of Toll Fraud associated withyour system and that, if Toll Fraud occurs, it can result in substantialadditional charges for your telecommunications services.

Avaya Toll Fraud Intervention

If you suspect that you are being victimized by Toll Fraud and you needtechnical assistance or support, call Technical Service Center TollFraud Intervention Hotline at +1-800-643-2353 for the United Statesand Canada. For additional support telephone numbers, see the AvayaSupport Web site: http://support.avaya.com. Suspected securityvulnerabilities with Avaya products should be reported to Avaya bysending mail to: [email protected].

Trademarks

The trademarks, logos and service marks (“Marks”) displayed in thissite, the Documentation and Product(s) provided by Avaya are theregistered or unregistered Marks of Avaya, its affiliates, or other thirdparties. Users are not permitted to use such Marks without prior writtenconsent from Avaya or such third party which may own the Mark.Nothing contained in this site, the Documentation 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 writtenpermission 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,and “Linux” is a registered trademark of Linus Torvalds.

Downloading Documentation

For the most current versions of Documentation, see the AvayaSupport Web site: http://support.avaya.com.

Contact Avaya Support

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

2 Configuration — Survivable SIP Proxy (SSP) September 2010

http://support.avaya.com

http://www.avaya.com/support/LicenseInfo

http://support.avaya.com/Copyright




Contents

Chapter 1: New in this release.................................................................................................5Features............................................................................................................................................................5Other changes...................................................................................................................................................5

Chapter 2: Introduction.............................................................................................................7

Chapter 3: Survivable SIP Fundamentals...............................................................................9Overview of Survivable SIP Proxy (SSP) Fundamentals..................................................................................9Functional description.....................................................................................................................................10OAM interface.................................................................................................................................................13

Chapter 4: Planning and engineering....................................................................................15Supported client types.....................................................................................................................................15SSP capacity guidelines..................................................................................................................................15Limitations and restrictions for the Network SPS............................................................................................16Feature interactions and limitations for the SSP.............................................................................................17Standards compliance.....................................................................................................................................21

Chapter 5: Configuring an Avaya CS 2100 SSP network.....................................................23Accessing NRSM............................................................................................................................................24Configuring the Network SIP Proxy Server (SPS)..........................................................................................25Job aid.............................................................................................................................................................26Job aid.............................................................................................................................................................27Job aid.............................................................................................................................................................28Job aid.............................................................................................................................................................29Job aid.............................................................................................................................................................29Job aid.............................................................................................................................................................30Configuring the realm on the Survivable SIP Proxy (SSP).............................................................................31Job aid.............................................................................................................................................................32Job aid.............................................................................................................................................................32Configuring System Wide Settings on the Survivable SIP Proxy (SSP).........................................................33Job aid.............................................................................................................................................................35Job aid.............................................................................................................................................................35Job aid.............................................................................................................................................................36Job aid.............................................................................................................................................................37Job aid.............................................................................................................................................................37Job aid.............................................................................................................................................................38

Chapter 6: Provisioning and distribution guidelines...........................................................41Provisioning emergency fallback routes..........................................................................................................41Job aid.............................................................................................................................................................42Job aid.............................................................................................................................................................42Manual bulk import and export of User Endpoints..........................................................................................43Manual bulk import from remote system on Network SPS..............................................................................44Manual bulk import from remote system on SSP............................................................................................45Scheduled ESA Data Synchronization............................................................................................................47Scheduled ESA Data Synchronization – Network SPS..................................................................................48Scheduled ESA Data Synchronization - SSP.................................................................................................49Avaya CS 2100 SSL provisioning guidelines for the Survivable SIP Proxy....................................................50

Configuration — Survivable SIP Proxy (SSP) September 2010 3

Chapter 7: SSP ESA interoperating with MG 9000 ESA.......................................................55

Chapter 8: Call flows...............................................................................................................57Normal mode...................................................................................................................................................57ESA mode.......................................................................................................................................................58SIP SSP call flow and dial plan setup.............................................................................................................60Registration call flow.......................................................................................................................................63Detailed solution examples.............................................................................................................................64

Chapter 9: Upgrading or downgrading an SSP or Network SPS........................................69Obtaining release software.............................................................................................................................70Performing an upgrade...................................................................................................................................71Performing a downgrade.................................................................................................................................72Handling errors during upgrades or downgrades............................................................................................75RPM file corruption..........................................................................................................................................75Incomplete or corrupted installation................................................................................................................75Not running rpm as superuser.........................................................................................................................76Corrupted backup info file...............................................................................................................................76Database corruption........................................................................................................................................77


Chapter 1: New in this release

The following sections detail what's new in Avaya Communication Server 2100 Configuration —Survivable SIP Proxy (SSP), NN42100-506 for release SE13.

Navigation

• Features on page 5

• Other changes on page 5

FeaturesThere are no feature changes to the document in this release.

Other changesUpdated the procedure Configuring the Network SIP Proxy Server (SPS) on page 25 toreflect the security enhancements associated with the Avaya Communication Server 2100 -Adaptive Application Engine/Session Server Lines (Avaya CS 2100-A2E/SSL).


New in this release


Chapter 2: Introduction

The Avaya Communication Server 2100 Configuration — Survivable SIP Proxy (SSP), NN42100-506describes the Survivable SIP Proxy application and how to configure it in an Avaya CS 2100 network.

Navigation

• Survivable SIP Fundamentals on page 9

• Planning and engineering on page 15

• Configuring an Avaya CS 2100 SSP network on page 23

• Provisioning and distribution guidelines on page 41

• SSP ESA interoperating with MG 9000 ESA on page 55

• Call flows on page 57

• Upgrading or downgrading an SSP or Network SPS on page 69


Introduction


Chapter 3: Survivable SIP Fundamentals

This chapter provides descriptive information for the Survivable SIP Proxy (SSP) and configuration tasks.

Navigation

• Overview of Survivable SIP Proxy (SSP) Fundamentals on page 9

• Functional description on page 10

• OAM interface on page 13

Overview of Survivable SIP Proxy (SSP) FundamentalsThe SSP was developed around the use of the SIP Proxy Server (SPS) on Linux as anEmergency Stand Alone (ESA) service for SIP signaling elements. The SPS on Linux is usedfor communication purposes between elements that are loosely coupled devices marked bysignaling links, device density, and/or geographic area. This loosely coupled set of SIPsignaling devices is known as a community of interest (COI). The SPS on Linux acts as a SIPsignaling controller for a given COI in ESA conditions.

When operating in this capacity, the SPS on Linux is known as a Avaya Survivable SIP Proxy(SSP). Therefore, the SSP, as a device, must be located within the COI in which it operates.

There was previously no Avaya device within the Avaya CS 2100 portfolio that behaves in amanner necessary to support Avaya CS 2100 ESA functionality. The Media Gateway 9000(MG 9000) has the ability to terminate telephony calls within the community. However, theability to connect calls outside of the community when in the ESA mode, did not previouslyexist. The basic software of the SPS is now utilized for routing outside of a community. In thiscase it is reused and modified to provide the needed capability for ESA operation. The followingdiagram illustrates a high-level view of the SSP within its COI in relation to the Avaya CS 2100core switching devices.

Although the following diagram is intended to show the relative position of the SSP in acustomer network, the connections representing the relationship of one signaling element toanother is depicted as well. The connections between the Network SPS and each SSP NetworkRouting Service (NRS) illustrate a data relationship whereas the connections shown betweenthe Avaya CS 2100 SSL interface and each SSP depict a call processing and signalingrelationship. Also shown in the following figure is a high-level view of the logical segmentationof COIs within their respective domains.


Figure 1: Position of SSPs in an Avaya CS 2100 network

Functional descriptionIn order to provide SSP operations, the following modifications were made to the SPS on Linux:

• Element management changes that enable the manipulation of internal data structuresin order to create the necessary behavior of the SSP (that is, configuration interface).

• Table control modifications that store emergency stand alone routing information.

• Routing changes that allow the SSP to act as an egress and ingress device into a givencommunity needing SIP signaling services upon entering ESA mode.

• Communication with the Network SPS in order to receive updated routing informationfrom a centralized location (for example, the Avaya CS 2100 SSL interface or a NetworkSPS).

When not in ESA mode, the SSP provides egress only to the outbound server (Avaya CS 2100SSL); incoming calls from the outbound server to SIP clients bypass the SSP. When in ESAmode, the SSP operates within a given COI by behaving as the egress and ingress of SIPsignaling to either user devices (for example, a SIP telephone set) or gateway-like devices (forexample, MG 9000, Audiocodes MG 3200, a 3rd party call server). When the COI has not beenisolated (that is, ESA mode), the SSP can act as a tandem SIP signaling device that will merelyforward SIP signaling to the outbound server listed within the System Wide Settings table.Upon isolation (that is, the SSP cannot contact either the listed outbound server set or the

Survivable SIP Fundamentals


listed network SPS set), emergency routes are exposed so that the endpoints within thecommunity will have the ability to contact endpoints outside of the community.

The NRSM is the primary means to configure the Network SPS and the SSP. It can be accessedthrough Internet Explorer by typing the Fully Qualified Domain Name (FQDN). The FQDN wasgiven to the Network SPS/SSP at installation time and should be mapped to the IP address inthe Windows host file if on that operating system.

See Accessing NRSM on page 24 for information on how to access and use the NRSM.

In order to configure the SPS on Linux as an SSP, a craftsperson should choose the SSP valuein the drop down items within the System Wide Settings tab of the Network Routing ServiceManager (NRSM). To be able to make this choice, the proper key code values must be enteredin the System Wide Settings through the NRSM page by choosing the Avaya CS 2100 optionand populating the necessary fields. Once the key code is verified, the ability to datafill othernecessary fields becomes available. These fields define the network elements that the SSPwill utilize in order to make signaling connections as well as download necessary endpoint androuting data housed within a network database.

The Network SPS is responsible for maintaining its own database of User Endpoints importedfrom the Avaya CS 2100 SSL, and Gateway Endpoints and routes, which are provisionedmanually, and distributing this information to each of its served SSPs. The Users on a AvayaCS 2100 SSL are provisioned on the Avaya CS 2100 core using OSSGate on the CMTplatform. User provisioning information is transmitted from the core to the SSL through anNCAS link where it is stored in the SSL's local database. The Network SPS obtains the Usersdirectly from the Avaya CS 2100 SSL through a connection to the Avaya CS 2100 SSL’s localdatabase. The SSPs that subtend the Network SPS import User Endpoint, Gateway Endpoint,and route information through a connection to the database of the Network SPS. A specialsection of System Wide Settings is used to hold information that the Network SPS or SSPneeds to contact the remote database from which it imports information.

User Endpoint importation is capable of operating in two modes: unattended and manual. Theunattended importation of User Endpoints is performed by a background task, which executesevery six hours (four times daily). This means that when changes are made to user provisioningon the Avaya CS 2100 SSL system, the Network SPS and SSP will automatically update toreflect those changes within a maximum of six hours. Manual synchronization can beperformed at any time. After all User Endpoints are imported, unattended mode exports all ofthe User Endpoints to a CSV file which can be uploaded to a management host from theNetwork SPS or SSP through the Bulk Export for User Endpoints page on the NetworkRouting Service Manager (NRSM). See Manual bulk import and export of User Endpoints onpage 43 for more information.

The manual importation of User Endpoints is accomplished by navigating to the UserEndpoints tab on the Endpoints page of the NRSM user interface and clicking the Importbutton. The User Endpoints tab also provides an Export button to allow manual bulk exportof User Endpoints to a CSV file.

There are differences in the operation of unattended and manual modes of User Endpointimportation. In manual mode, a file dialog is presented when the Import button is clicked. User

Functional description


Endpoints are first imported from the selected file (if it exists). This could be the file of exportedUser Endpoints created by unattended mode or it could be the file of User Endpoints created bymanual export. Once importation from the file is complete, information is then imported froma remote database (if network database access is enabled through configuration of the networkdatabase fields in System Wide Settings). In unattended mode, User Endpoints are importedonly from the remote database (network database access is enabled); no attempt is made toimport from a file.

Once the SSP has been properly configured, it will begin sending a status (that is, a heartbeat)OPTIONS request to the servers configured in the System Wide Settings table. The SSPutilizes these servers to transmit SIP call processing signaling. All call processing from theSSP is destined for the active server, which is defined using the following precedence:

1. Primary Outbound Server

2. Secondary Outbound Server

If none of these servers can be utilized as active (that is, none are reachable), the SSP will fallinto ESA mode where previous datafilled emergency routes will become exposed. Thisbehavior indicates that the SSP has been isolated from the call processing network. Theseexposed emergency routes are used to route call processing signaling traffic in and out of thecommunity of interest.

Figure 2: Signaling path during isolation

See Call flows on page 57 for an example of call flows and corresponding datafillrequirements.



OAM interfaceThe Network Routing Service Manager (NRSM) is the primary means to configure the NetworkSPS and the SSP. It can be accessed through Internet Explorer by typing the FQDN. The FQDNwas given to the SPS/SSP at installation time and should be mapped to the IP address in theWindows host file if on that operating system. Log in to the Element Manager using the Adminuser and password that was set up at SPS/SSP installation time.

NRSM is the web-based management application for the SSP. Its responsibility is to configurethe proxy server, populate the network numbering plans and perform maintenance operations.It also provides third party access interfaces by supplying a J2EE web service interface on theserver.

The NRSM is designed by using the latest Java technologies and Model View Controllerarchitecture for Web User Interfaces (WUI) and server implementations. The applicationresides in a Java web container where it accepts requests from web browsers, parses serverrequests, and serves web pages back to the client browsers. The server application plays thekey role in the overall process.

The NRSM application is composed of multiple logic modules on its server.

• Web User Interfaces (WUI)

• Business Logic

• Data Access

• Open SPS Manager Web Service Interfaces

• Application Resources

The NRSM is designed as a plug-in application to the Quantum framework which means itmust follow design requirements for user interface components, security, and web services tofit into the framework. The Quantum framework and NRSM are installed in two Redhat PackageManagement (RPM) files during the installation of the SSP.

OAM interface


Chapter 4: Planning and engineering

This chapter provides information on capacity guidelines, restrictions, dependencies and interactions.

Navigation

• Supported client types on page 15

• SSP capacity guidelines on page 15

• Limitations and restrictions for the Network SPS on page 16

• Feature interactions and limitations for the SSP on page 17

• Standards compliance on page 21

Supported client typesThe following client types are supported:

• LG-Ericsson 6800 series

• LG-Ericsson 8800 series

• Polycom SoundPoint IP series

SSP capacity guidelinesThe following capacity guidelines apply to the Survivable SIP Proxy (SSP):

• Each SSP is limited to 2000 endpoint registrations (either dynamic or static).

• Each SSP can have no more than 10,000 routing entries.

• At least one Network SPS pair must exist.

• An SSP cannot be datafilled as a redirected endpoint.

• A physical user endpoint (that is, a telephone set) within an SSP community should beconfigured to register with the SSP of that community.

• Once the SSP is fully configured, it must be restarted for all changes to take effect.


• The maximum number of Emergency Fallback routes is limited to five (5).

• Each MG 9000 community of interest (COI) must have its own SSP with no other typesof SIP endpoints that rely upon the MG 9000 COI’s SSP.

Limitations and restrictions for the Network SPSThe following limitations apply to the Network SIP Proxy Server (SPS):

• The number of user endpoints (that is, telephone sets) datafilled within the Network SPS islimited to 100,000

• The number of routing entries is limited to 180,000.

• The craftsperson must not enter more than 1,000 gateway endpoints into the NetworkSPS database.

• A physical endpoint (that is, a telephone set or a gateway) must not be configured toregister with the Network SPS.

• The Network SPS must be configured to operate with SSP communities and the SSL onthe Avaya CS 2100, and be used solely for the purpose of supporting the ESA capability ofthe SSP communities.

• Provisioning multiple Root Domains with identical sub-domains on Avaya CS 2100Session Server Lines is not supported in SSP ESA. The Avaya CS 2100 SSL system isless restrictive regarding the naming of sub-domains than the SPS regarding the namingof L1 Domains. The SPS requires that L1 Domain names be unique within the system,not just within a Service Domain. If, for example, the following two domain hierarchieswere provisioned on Avaya CS 2100 SSL

fsva.nortel.net

|-- realm0.fsva.nortel.net

|-- 444.realm0.fsva.nortel.net

fsva.nortel.com

|-- realm0.fs

Planning and engineering


va.nortel.com

|-- 445.realm0.fsva.nortel.com

and each sub-subdomain had Users provisioned within it, when a scheduled or manual importfrom the Avaya CS 2100 SSL to the Network SPS was performed, errors would result whenan attempt is made to add the second instance of realm0. See Avaya CS 2100 SSL provisioningguidelines for the Survivable SIP Proxy on page 50 for guidelines for provisioning domainhierarchies on Avaya CS 2100 SSL.

• Provisioning multiple Users in the same sub-sub-domain with Directory Numbers whoselast four digits are identical on Avaya CS 2100 Session Server Lines is not supported inSSP. The Avaya CS 2100 SSL system is less restrictive regarding the format of DirectoryNumbers than the SPS. The last four (4) digits of a Directory Number is referred to as theL0 Directory Number on the SPS. L0 Directory Numbers are required to be unique withinan L0 Domain. Directory numbers on the Avaya CS 2100 SSL which are identical in theirlast 4 digits will cause errors when Avaya CS 2100 SSL Users are imported by the NetworkSPS.

• A database restore operation on a server running SSP 1.0 (Network SPS or SSP) mustbe performed using a database backup file created through a database backup operationon a server running SSP 1.0. Performing a database restore operation on SSP 1.0 using abackup file created on a non-SSP 1.0 load (for example, an SPS 5.5 load) is notsupported.

Feature interactions and limitations for the SSPWhen communication is lost to the primary call server, the SSP provides basic call processing.Similar to traditional Emergency Stand Alone (ESA) products, such as RCC2 and MediaGateway 9000, feature support in ESA is very limited. SIP clients provide intelligent featuresimplemented within the firmware, for example, three way calling and forwarding. However,these features may not be fully functional in the ESA mode. The goal of ESA is to provide theend user with basic call capability until full services can be restored.

The following feature interactions are associated with the SSP:

1. Because the SSP attempts to tandem all requests and responses from outside ofthe community to an endpoint within its community, it should not be datafilled as aredirect endpoint. If it is datafilled as a redirect endpoint, the 3xx (or REFER) ispassed to an endpoint within the community—the SSP itself is not redirected.

2. While the endpoint data is extracted from the SSL on the Avaya CS 2100, thecraftsperson must datafill routing information in the Network SPS in order for theproper data to be downloaded to the individual SSP communities. Manual datafillincludes translations data that is not present on the Avaya CS 2100 SSL. Forexample, dialing a private ESN is done through translations on the core switching

Feature interactions and limitations for the SSP


device. In order to locally terminate private dialing within a community experiencingESA, this data must be manually provisioned within the network SPS. Otherwise,the private dialed number will be forced out of the ESA route to the core switchingdevice, which may be a more expensive route. Therefore, in essence, the onlyinformation retrieved from the Avaya CS 2100 SSL is the North American E.164directory number.

3. Supported SIP user sets have visual indicators that show when the registrationservice from the SSL is unavailable (that is, the service is in ESA mode). Forexample, the LG Ericsson 68xx series sets indicate ESA mode with a slow flashingred DN light, and the Polycom series sets indicate ESA mode with an open DN icon.The SSP itself will present a critical log to the craftsperson when in ESA. For thirdparty Foreign Exchange Station (FXS) gateways, refer to the appropriate third partydocumentation.

4. In order to receive ESA services, a user must login to the system through their homeSSP that contains their user information from the SSL.

5. In ESA mode, the octothorpe (that is, #) key cannot be entered as the end-of-digitstring. If entered, the SSP sends a “404 – Not Found” and the call will be sent totreatment.

6. Multiple Appearance Directory Numbers (MADN)/Hunt Groups are not supportedin ESA mode. SSL users assigned to MADN and Hunt Groups have no directorynumber (DN). MADN and Hunt Groups share the alias of the group defining theMADN or Hunt Group. The end result is a failure of the MADN or Hunt Group to becorrectly provisioned on the SSP. In order to support this functionality, MADN andHunt groups can be configured on the client, but are not survivable. Only one DNappearance can be provisioned for ESA mode. All other DN appearances are to beconfigured on "non-survivable" line appearances. The non-survivable lineappearances must be configured to communicate directly with SSL.

7. Multiple user logins are not supported in ESA mode. SSL provides the ability for thesame user (for example, [email protected]) to log in to multiple clients (that is,PC Client, Hard Client, etc.). Some clients also provide the ability to register multipleusers against different line appearances. This registers the same user againstmultiple IP addresses, or multiple users against the same IP address. The SSPallows one appearance of a user. It allows only one line appearance per client. Inorder to work around this functionality difference, do the following: Provision onlyone DN appearance for ESAmode. Configure all other DN appearances on non-survivable line appearances. The non-survivable line appearances must beconfigured to communicate directly with SSL.

8. FXS/FXO gateways are normally configured with multiple SIP accounts defined forthe analog stations (that is, FXS/FXO). Due to the previous restriction with allowingmultiple logins on the same device, the FXS/FXO gateways cannot be configuredto register to the SSP. Therefore, the FXS/FXO analog station gateways must beconfigured on the SSP as gateways. The analog station gateways should registerdirectly with SSL (that is, REGISTRAR points directly to SSL). During Normal mode,these devices communicate directly to the SSL. During ESA mode, the gateways



communicate directly to the SSPs. For ESA mode, gateway routes will be requiredto properly route calls to and from the gateway.

9. When attempting to utilize the backup proxy for an LG-Ericsson client, there is asubstantial delay in completing calls. By design, LG-Ericsson clients send allrequests to the primary proxy, even if the primary proxy is not reachable. In somecases, this causes the LG-Ericsson client to wait for the requests to time out,causing significant delay in the call completion. Currently, if the primary proxy isunavailable and the phone is set with default values, it will take approximately 15seconds for a client to receive ring back. There is a T1_timer value, which can beconfigured via the TFTP configuration files, which will reduce this time toapproximately 8 seconds. Use the following command to decrease this time period.This command specifies the T1 timer value (between 100 - 640 msec). The defaultvalue is 250 msec.

[VOIP]timer_t1 nnnfor example,

timer_t1 25010. When attempting to use a backup ESA proxy, and if the Session Server Lines (SSL)

is not reachable, Polycom calls will fail to complete. The SSP can be configuredin an Active/Standby (that is, client S1/S2) configuration. If for some reason, theprimary SSP is out-of-service and the SSL proxy is not reachable, calls utilizing thePolycom client will not complete. The Polycom client, in this scenario, sends auser@ip-address schema, causing the SSP to respond with a 404-Not Found.

11. The SSP will enter ESA within five to seven seconds of a heartbeat failure (that is,OPTIONS). The heartbeat is configurable and by default is sent every 60 seconds.With the default of 60 seconds, this means there could be as much as one minute,seven seconds, for a detection of isolation to occur by the SSP. In addition, clientshave their own registration timer. Prior to the client-registration timer expiration,there is no ESA indication on the client. It is recommended to leave the SSPheartbeat at 60 seconds and the client expiration timer at the minimum value of 300seconds (five minutes). Exiting ESA: The SSL will de-register users based on theoriginal registration timer set by the client. If this amount of time has expired, while inESA, then calls will not complete after exiting ESA until the clients re-register withSSL. This would be the maximum of the registration timer configured in the client.As stated above, the registration timer is recommended to be configured as theminimum value allowed on the SSP (that is, 300 seconds).

12. Client isolation (normal versus survivable mode) indication is client dependent. Theclient documented behavior (when a 200OK to the REGISTRATION is not received)is the indication that is provided to the end user. For example, LG-Ericssonindication of isolation is a solid red LED on the line appearance. Polycom indicationis a hollow phone icon on the line appearance. Audiocodes FXS/FXO provides no

Feature interactions and limitations for the SSP


indication. MG 9000 Native can provide an ESA notification tone. MG 9000 ABIprovides no ESA indication.

13. Any emergency dialing (that is, 911) is subject to the timer restrictions (see 9 onpage 19 through 11 on page 19).

14. Patching and Upgrades are subject to the timer restrictions above. An Active/Active environment is possible with the SSPs; however, the same timer restrictionsfor the SSP entering ESA are imposed.

15. The mechanisms to determine SSP ESA status are logs and operationalmeasurements (OMs). There is no visual indication, for an SSP, indicating ESAstatus. The following show examples of the logs that are produced:

CRITICAL (Mar 26 08:48:14): spProxyRouter:1639 Dropping intoESA!CRITICAL (Mar 26 08:48:14): spProxyRouter:1640 Local RoutingDB exposed!

16. There are dial plan limitations with regards to the interoperability of the MG 9000and SSL. The MG 9000 only supports 7-digit and 10-digit dialing in ESA. The SSLclients can support additional dialing plans; however, 7-digit and 10-digit dialing forSSL to SSL lines requires an additional access-code digit to be sent. Due to thisrestriction, the MG 9000 and SSL lines cannot reside within the same community(that is, client dialing plans are independent).

17. The Avaya CS 1000 can be utilized as a trunk gateway. The Avaya CS 1000 requiresan access code to be received, for proper routing of incoming SIP calls. In the caseof the MG 9000, it allows 7-digit and 10-digit dialing in ESA. The SSP does notperform post-translations. Therefore, the Avaya CS 1000 cannot be utilized as atrunk gateway for the MG 9000.

18. There is a fundamental restriction with SIP PBX interoperability with the Avaya CS1000 SPS. The Avaya CS 1000 SPS/SSP utilizes ephemeral ports, which the SIPPBX does not handle appropriately. This will be addressed by SIP PBX in a futurerelease; however, a temporary patch has been created in the SPS/SSP which allowsthe defining of a specified port. With this implementation, there is still an issue wherethe SIP PBX challenges INVITES coming from the SSP. Any gateway that does notsupport the challenge request (that is, SIP 407) will not interoperate with the SIPPBX gateways. The MG 9000 is an example of such a gateway. As a result, theAYT audit will fail and must be turned off at the SIP PBX. Therefore in normal modeboth the MG 9000 and SSP must be in ESA. If for some reason the MG 9000 is inESA, but the SSP is not, the SSP will attempt to route this MG 9000 call to the core(SIP PBX). The call will be challenged with a 407 and the MG 9000 does not supportthe 407 SIP message.

19. The LG-Ericsson client firewall setting must be disabled.

20. The SSP inherently supports 4-digit dialing and 7/10-digit dialing with an accesscode. 3-digit and 5-digit dialing is not inherently supported. 7-digit and 10-digit,without an access code, is also not inherently supported. The L0 Directory Numbercan be provisioned in the SSP to support 3-digit, 5-digit, 7-digit dialing, by



specifically provisioning the L0 Directory Number with the 3-digit, 5-digit, or 7-digitDN. If configured in this fashion, the NRS data synchronization must be disabled.If the synchronization is not disabled, the manually configured directory numberswill be overwritten with the data received from the SSL.

21. The MG 9000 will reject any SIP request when not experiencing ESA.

22. Calling name and number are not traditionally ESA-supported features. When acommunity experiences ESA, these features are dependent upon the client in ESA.

23. ESA Entry/Exit: Depending on the nature of the network isolation, speech path mayremain during ESA entry and exit; however, it is not guaranteed. In addition, anyfeature attempt (such as HOLD/Retrieve, 3WC, etc.) will result in the call beingterminated. MG 9000 calls will drop upon ESA exit, due to existing functionality inthe MG 9000.

24. In order to utilize the Mediant 1000/MG 3200 as an ESA route from an SSP, thefollowing configuration must be completed on the Mediant 1000/MG 3200. Thisconfiguration allows the appropriate ringback tones to be implemented in ESA modewhen calls are made from users such as SSL and MG 9000 users, terminating to aMediant 1000/MG3200 that is configured as an ESA route. Configure the Mediant1000/ MG 3200 as follows: In the Mediant 1000/MG 3200 configuration GUI, fromthe Protocol Management tab, navigate to the Protocol Definition tab. Set theEnable Early Media parameter to Enable.

25. A database restore operation on a server running SSP 1.0 (Network SPS or SSP)must be performed using a database backup file created through a database backupoperation on a server running SSP 1.0. Performing a database restore operationon SSP 1.0 using a backup file created on a non-SSP 1.0 load (for example, anSPS 5.5 load) is not supported.

Standards complianceThe SSP complies with the following standards:

• RFC 3261

• RFC 3966

• Avaya SIP Interoperability Specification

Standards compliance


Chapter 5: Configuring an Avaya CS 2100SSP network

Configuration of the SSP for Avaya CS 2100 includes the procedures listed in this section.

Figure 3: SSP configuration task flow

Before configuration can begin on the SSP, the customer must have a Customer Name, Customer ID, andKey code. These values together unlock the SSP configuration values.

Installation and commissioning of the Network SPS and SSP should precede these configurationprocedures and sound network connections should exist between the elements.

Users should be set up in such a manner that they are accessible to be provisioned. Refer to Avaya CS2100 SSL provisioning guidelines for the Survivable SIP Proxy on page 50 before performing theconfiguration procedures.


In order for the Network SPS to know how to contact the Avaya CS 2100’s SSL (if present) to retrieveUser Endpoint information, configuration of the Network SPS is dependent on certain configuration itemsof the Avaya CS 2100 SSL itself. The values of these configuration items are located in the installationproperties file which is used for initial installation and any subsequent software upgrades of the Avaya CS2100 SSL. For more information, see Configuring the Network SIP Proxy Server (SPS) on page 25.

Use the following navigation list to see the procedures shown in the preceding taskflow:

• Accessing NRSM on page 24• Configuring the Network SIP Proxy Server (SPS) on page 25• Configuring the realm on the Survivable SIP Proxy (SSP) on page 31• Configuring System Wide Settings on the Survivable SIP Proxy (SSP) on page 33

Accessing NRSMPerform the following procedure to change the access to the Network Routing Service Manager(NRSM).

The NRSM is the primary means to configure the Network SPS and the SSP. It can be accessedthrough Internet Explorer by typing the Fully Qualified Domain Name (FQDN). The FQDN wasgiven to the Network SPS/SSP at installation time and should be mapped to the IP address inthe Windows host file if on that operating system. Log in to the Element Manager using theAdmin user and password that was set up at Network SPS/SSP installation time.

The NRSM is used to:

• configure the proxy server• populate the network numbering plan• perform maintenance operations• provide third party access interfaces by supplying a J2EE web service interface on the

server

1. Log in to the Element Manager using the Admin user and password that was set upat Network SPS or SSP installation time.

2. Select the Network SPS or SSP to configure from the menu.The main NRSM page appears.

3. Select a configuration menu from the Common Manager menus on the left side ofthe NRSM page.To install a Network SPS, configure the Network Database fields in System WideSettings to specify the CS 2100 SSL. See Configuring the Network SIP ProxyServer (SPS) on page 25 for more information. To install an SSP, configure theNetwork Database fields in System Wide Settings to specify the Network SPS.

Configuring an Avaya CS 2100 SSP network


See Configuring System Wide Settings on the Survivable SIP Proxy (SSP) onpage 33 for more information.

Configuring the Network SIP Proxy Server (SPS)Use this procedure to set values in the NRSM to allow synchronization of Network SPS andAvaya CS 2100 endpoints.

Prerequisites

The following prerequisites are necessary to perform this procedure:

• Before configuration can begin on the Network SPS, you must have all of the followingthree values, which together unlock the SSP configuration values:

- a Customer Name- a Customer ID- a Key code

See the Job aid on page 26following this procedure for the rules associated with thesefields.

• Configuration of the Network SPS is dependent on certain configuration items of theAvaya CS 2100 SSL (if present). This information is required in order for the Network SPSto know how to contact the Avaya CS 2100 SSL to retrieve User Endpoint information.The information is located in the installation properties file which is used for initialinstallation and any subsequent software upgrades of the Avaya CS 2100 SSL.

• The Network SPS should be installed, and sound connections should exist between itand the Avaya CS 2100 SSL database.

Note that If the Network Database fields are filled in, data will be automatically synchronizedevery 6 hours (at 12:00 AM, 6:00 AM, 12:00 PM and 6:00 PM). Refer toScheduled ESA DataSynchronization on page 47 for more information. Manual synchronization can be performedat any time by doing a Bulk Import operation from the User Endpoints page. Refer to Manualbulk import and export of User Endpoints on page 43 for more information. The Key code isrequired as described in 4 on page 25.

1. Log in to the Element Manager.

2. Select the NRSM application.

3. Select System Wide Setting from the left menu.

4. Select Avaya CS 2100 from the Call Server Type list.The Customer Name, Customer ID, and Key code fields are displayed.

5. Fill in each field with the appropriate value, and click Validate. For more information,see the Job aids at the end of this procedure.

Configuring the Network SIP Proxy Server (SPS)


If the entered values are correct, the Network SPS configuration fields aredisplayed.

6. Select the NRS from the SPS Type pull down menu.

7. Fill in the following fields as described in theJob aid on page 27 following thisprocedure:

• Network Database Name

• Network Database IP Address

• Network Database Port

• Network Database User Name

• Network Database Password

8. Select Save.

Job aidThe following table describes Customer Name, Customer ID, and Key fields:

Field Description RulesCustomerName

The Customer Name is theAvaya customer's assigned"legal entity" name.

The following rules apply:

• uppercase and lowercase letters, digits,spaces, and special characters (`~!@#$%^&*()-_=+[{]}\|;:'",<.>/?) are permitted inany position

• other characters (for example, non-printable control characters) are notpermitted

Customer ID The Customer ID isidentical to the Avayacustomer's assigned SiteID.


• up to 15 characters in length

• uppercase and lowercase letters, anddigits are permitted

• other characters are not permitted

Key Customers access the KRSapplication to generatekeys from the CustomerName and Customer ID.



• consists of lowercase letters and digits



Job aidPrior to Avaya CS 2100 release SE13, all network database parameters are contained in cleartext in the installation properties file on the Avaya CS 2100 SSL System Manager server. ForAvaya CS 2100 release SE13, the network database IP address continues to be containedwithin the installation properties file in clear text. Use the same method to obtain the IP addressas for prior releases.

For Avaya CS 2100 release SE13 and subsequent releases, the Adaptive Application Engine(A2E) is deployed on the SSL system. As a result of security hardening in A2E, some of thenetwork database access parameters are no longer available as clear text items. This appliesespecially to the SSL database username and password. These are assigned by theadministrator when A2E is initially installed or, when the SSL is upgraded to A2E release 7.0. Ifthe system is being upgraded, the SSL database password will be changed from its previousvalue because of additional security restrictions on the password. As a result of these changes,the administrator of the Network SPS must obtain the SSL database parameters from the SSLadministrator, who should know the database username and password, or should haverecorded them in a secure place.

The administrator may not know or have recorded the SSL database name and port.

Use the following two procedures to obtain the database name and port if unknown.

1. To obtain the database name, using an SSH client such as putty, access the SSLdatabase server and log in as the ntsysadm user.

2. Change to the ntdbadm user by executing the command:

su ntdbadmand enter the ntdbadm password when prompted.

3. Access the Oracle SQL user interface by executing the command:

sqlplusand enter the database username and password.

4. At the SQL> prompt, enter the following command to display the database name:

SELECT sys_context('USERENV', 'DB_NAME') FROM dual;5. When finished, type quit to exit from the Oracle SQL user interface.

The following shows an example of obtaining the database name:

SQL> SELECT sys_context('USERENV', 'DB_NAME') FROM dual;SYS_CONTEXT('USERENV','DB_NAME----------------------------------------------------------------------- mcpdb SQL> quit [ntdbadm@REGAEMS1 ntsysadm]$

Job aid


1. To obtain the database port, using an SSH client such as putty, access the SSLdatabase server and log in as the ntsysadm user.

2. Change to the ntdbadm user by executing the command:

su ntdbadmand enter the ntdbadm password when prompted.

3. Show the contents of the listener.ora file by executing the following command:

cat /opt/mcp/db/product/10.2.0/network/admin/listener.oraThe following shows an example of obtaining the database port :

[ntdbadm@REGAEMS1 ntsysadm]$ cat /opt/mcp/db/product/10.2.0/network/admin/listener.ora LISTENER = (DESCRIPTION_LIST = (DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = 47.104.37.110)) (PORT=5121) ) )SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = mcpdb)(ORACLE_HOME = /opt/mcp/db/product/10.2.0) (GLOBAL_DBNAME =mcpdb.mcpworld) ) ) ADMIN_RESTRICTIONS_LISTENER=ON[ntdbadm@REGAEMS1 ntsysadm]$

Job aidThe following figure shows the default settings for the Avaya SPS customer information afterinstallation.



Job aidThe following figure shows the customer information on the Network SPS after the Call ServerType of CS2100 is selected.

Job aidThe following figure shows the System Wide Settings on the Network SPS after clicking theValidate button.

Job aid


Job aidThe following figure shows the System Wide Settings on the Network SPS with the networkdatabase fields filled in.



Configuring the realm on the Survivable SIP Proxy (SSP)Use this procedure to configure the realm on the Survivable SIP Proxy (SSP).

The realm on a particular SSP must be configured to be identical to the L1 Domain that will beimported from the Network SPS. The realm is also identical to the first level sub-domain on theAvaya CS 2100 SSL (see Provisioning and distribution guidelines on page 41). The realm islocated on the Server Configuration page, which is presented when the link for a particularSSP is clicked on the Enterprise Common Manager page.

1. Point the browser to the Enterprise Common Manager.

2. On the Enterprise Common Manager page, select an SSP. See the Job aid onpage 32 Job aid following this procedure.The server configuration page is presented.

3. Click the Edit button.

4. In the Realm Name field, enter the realm name. See the Job aid on page 32 Jobaid following this procedure.

5. Click the Save button.

Configuring the realm on the Survivable SIP Proxy (SSP)


Job aidThe following figure shows an example of the server configuration page.

Job aidThe following figure shows an example of a realm name.



Configuring System Wide Settings on the Survivable SIPProxy (SSP)

Use this procedure to set values in the NRSM to allow synchronization of the Network SPS.

Prerequisites


• The installation of SSP must be complete.• Sound network connections to the Network SPS are necessary.

If Network Database fields in System Wide Settings are configured, data will be synchronizedautomatically every six hours (at 12:15 AM, 6:15 AM, 12:15 PM and 6:15 PM). Refer to Scheduled ESA Data Synchronization on page 47 for more information. Manualsynchronization is performed by doing a Bulk Import operation from the User Endpoints page.Refer to Manual bulk import and export of User Endpoints on page 43 for more information.The Key code is required to see the SSP configuration page.

Configuring System Wide Settings on the Survivable SIP Proxy (SSP)




3. Select System Wide Setting from the left menu.

4. Select CS 2100 from the Call Server Type list.The Customer Name, Customer ID, and Key code fields are displayed.

5. Fill in each field with the appropriate Avaya-supplied values, and click Validate.If the entered values are correct, the Network SSP configuration fields aredisplayed.

6. Select the SSP from the SPS Type pull down menu.

7. Fill in the fields as follows: Note that the Network DB ID and Network DB Protocolare not used on the SSP.

• the Primary Network Database IP Address with the ELAN address of thePrimary Network SPS

• the Alternate Network Database IP Address with the ELAN address of theAlternate Network SPS

• the Network Database Port (typically 1313)

• the Network Database User Name

• the Network Database Password

8. Fill in the Network SPS fields as follows:

• Select SSP from the SPS Type pull down menu.

• Fill in the Network SPS Primary IP Address with a valid IP address to theSSP from which routing information will be synchronized

• Fill in the Network SPS Primary Port with a valid port value to the SSP fromwhich the routing information will be synchronized

• Fill in the Network SPS Primary Protocol

• Fill in the Network SPS Secondary IP Address with a valid IP address to theSSP from which routing information will be synchronized

• Fill in the Network SPS Secondary Port with a valid port value to the SSPfrom which the routing information will be synchronized

• Fill in the Network SPS Secondary Protocol

• Fill in the Heartbeat Timer value in seconds. The default and minimum value is60 seconds.

• Fill in the Registration Timer value in seconds. The default value is 3600seconds (1 hour). If datafilled as zero (0), this indicates that the SSP will notregister.



• Select how the outbound servers will be configured.None Present, PrimaryOnly, Primary and Secondary). Depending on the selection made above, fillin the IP address and port of the outbound servers in the fields appropriately.

9. Select Save.

Job aidThe following table describes Customer Name, Customer ID, and Key fields:

Field Description RulesCustomerName

The Customer Name is theAvayacustomer's assigned"legal entity" name.


• uppercase and lowercase letters, digits,spaces, and special characters (`~!@#$%^&*()-_=+[{]}\|;:'",<.>/?) are permitted inany position

• other characters (for example, non-printable control characters) are notpermitted

Customer ID The Customer ID isidentical to the Avayacustomer's assigned SiteID.



• uppercase and lowercase letters, anddigits are permitted

• other characters are not permitted

Key Customers access the KRSapplication to generatekeys from the CustomerName and Customer ID.



• consists of lowercase letters and digits

Job aidThe following figure shows the default settings for the SSP customer information afterinstallation.

Job aid


Job aidThe following figure shows the customer information on the SSP after the Call Server Typeof CS2100 is selected.



Job aidThe following figure shows the System Wide Settings on the Network SPS after clicking theValidate button and setting the SPS Type to SSP.

Job aidThe following figure shows the System Wide Settings on the SSP with the Network SPS fieldsfilled in.

Job aid


Job aidThe following figure shows the System Wide Settings on the SSP with the Outbound Serverfields filled in.



Job aid


Chapter 6: Provisioning and distributionguidelines

This chapter provides descriptions of manual bulk import and export operations, scheduled ESA datasynchronization, and provisioning guidelines.

• Provisioning emergency fallback routes on page 41• Manual bulk import and export of User Endpoints on page 43• Scheduled ESA Data Synchronization on page 47• Avaya CS 2100 SSL provisioning guidelines for the Survivable SIP Proxy on page 50

Provisioning emergency fallback routesUse this procedure to set values in the NRSM to provision emergency fallback routes whennetwork connectivity is lost.

Important:It is recommended that Emergency Fallback Routes be configured only on the Network SPSand be downloaded to the SSP using unattended ESA Data Synchronization or manual BulkImport.

Prerequisites


The installation of Network SPS must be complete.



3. Select Routes from the left menu.

4. Select Standby Database .

5. Select the Emergency Fallback Routes tab.

6. Select a specific Service Domain, L1 Domain, L0 Domain, and Gateway Endpoint.The Add button is enabled.

7. Press the Add button.


8. Fill in the route cost.

9. Select Save.

10. Select Emergency Fallback Routes to search for existing emergency fallbackroutes.

11. To delete a route, select the checkbox next to the route ID and press Delete.

12. Select Confirm.

Job aidThe following figure shows the emergency fallback route configuration.

Job aidThe following figure shows adding a new emergency fallback route.

Provisioning and distribution guidelines


Manual bulk import and export of User EndpointsIn order to facilitate provisioning of Network SPSs and SSPs, this feature provides the abilityto manually bulk import and export User Endpoints. You can import User Endpoints from acomma separated value (CSV) file only, or from a remote system only, or from both CSV fileand remote system. You can export User Endpoints to a CSV file only.

Although the user interface for performing export and import of User Endpoints is the same forboth Network SPS and SSP, there are some operational differences between Network SPSand SSP. See Manual bulk import from remote system on Network SPS on page 44 and Manual bulk import from remote system on SSP on page 45.

Bulk Export and Import operations for User Endpoints are accessed through the Export andImport Buttons on the User Endpoints page. User Endpoint information can only be importedto the Standby Database. Therefore, the Standby Database must always be selected (nearthe top of the User Endpoints page) in order to enable the Import button. You can exportUser Endpoints from either the Active or Standby database.

Clicking the Export button on the User Endpoints page performs an export operation andpresents a page for performing retrieval of exported files. This page has a dropdown list anda Download Endpoints button. The dropdown list allows selection of either the UserEndpoints just exported manually by having clicked the Export button on the User Endpointspage (Download Current), or the User Endpoints exported by the most recent execution of aScheduled ESA Data Synchronization (Download Scheduled). Once the desired export file isselected, clicking the Download Endpoints button intitiates a file dialog for saving the exportdata as a CSV file on the local computer.

Manual bulk import and export of User Endpoints


Clicking the Import button presents a page for optional selection of a CSV file and initiatingthe import operation. This page contains two buttons: Browse and Submit. Clicking theBrowse button initiates a file dialog to select a CSV file on the local computer from which toimport User Endpoints. If the desired operation is to import from a remote database only, thefile selection is bypassed by simply clicking the Submit button. (This assumes that NetworkDatabase fields in System Wide Settings have been configured to enable access to the remotedatabase.) Refer to Configuring the Network SIP Proxy Server (SPS) on page 25 for NetworkSPS or Configuring System Wide Settings on the Survivable SIP Proxy (SSP) on page 33 forSSP.) The results of the import operation are displayed in the text area in the middle of theBulk Import for User Endpoints page. Once the import is complete, imported data is presentin the Standby Database only. A manual cutover and commit operation must be performed tocommit the imported data to the Active Database. If there were User Endpoints that failed tobe imported, in addition to display of information so indicating in the results text area displaysthat information, and a link is presented which can be clicked to initiate a file dialog to save theEndpoints in error and status information to a CSV file on the local computer.

In order to bulk import from a CSV file, the file must be present on the computer from whichthe NRSM user interface is being operated. The CSV file can be created manually or byperforming a bulk export operation and saving the export file on the local computer. An “empty”CSV file with instructions but no User Endpoint information can be created by performing abulk export with no provisioned User Endpoints present. The CSV file can then be opened ina spreadsheet application by double-clicking it.

Manual bulk import from remote system on Network SPSWhen the Network database access fields in System Wide Settings are properly configuredon the Network SPS and a manual bulk import operation is performed, the Network SPSimports provisioned Users from the Avaya CS 2100 SSL. For properly provisioned Users, (see Avaya CS 2100 SSL provisioning guidelines for the Survivable SIP Proxy on page 50)information is extracted from each User and used to create a User Endpoint which is thenadded to the Standby Database. There are some User Endpoint fields on the Network SPSfor which no equivalent information exists on the Avaya CS 2100 SSL, and these fields are leftset to their default values, which are typically blank. If any of these fields is subsequentlymodified manually on the Network SPS, the modifications will be preserved by subsequentmanual imports from the Avaya CS 2100 SSL as long as the modified User Endpoint continuesto be present on both the Avaya CS 2100 SSL and the Network SPS. The fields for which noequivalents exist on the Avaya CS 2100 SSL are:

• Trust Node

• Tandem gateway endpoint name

• E.164 Country Code (always defaulted to "1")

• Authentication Enabled

• Authentication Password



The Avaya CS 2100 SSL has no knowledge of any gateways that might exist in a particularSSP community or any routing configured against the gateways. Gateway Endpoints andRoutes are entities that should be manually provisioned on the Network SPS in order for themto be imported to the SSP.

When bulk importing User Endpoints on the Network SPS, the Avaya CS 2100 SSL system isconsidered authoritative. The bulk import function always attempts to keep the User Endpointson the Network SPS completely synchronized with their corresponding Users on the AvayaCS 2100 SSL. Any changes made to Users on the Avaya CS 2100 SSL, such as a changeto the Directory Number, will cause corresponding User Endpoints on the Network SPS to bemodified. Any removal of Users on the Avaya CS 2100 SSL will cause the corresponding UserEndpoints to be removed from the Network SPS. Any move of a user from one domain toanother will cause the User Endpoint to be deleted from the old domain and re-added to thenew domain. This also applies to any User Endpoint information that was imported from theCSV file—any such User Endpoint information that does not exist in the information importedfrom the Avaya CS 2100 SSL will be modified or removed.

It is recommended to perform a manual bulk export on the Network SPS when Gateways orRoutes have been added or modified, or when any of the above User Endpoint fields has beenmodified.

Manual bulk import from remote system on SSPAlthough there is a need for manual provisioning on the Network SPS to supplement the Userinformation imported from the Avaya CS 2100 SSL, there is no need for manual provisioningon the SSP. With network database access enabled in System Wide Settings, a manual bulkimport from the User Endpoints page on an SSP will import User Endpoints, Gateways, andRoutes from the Network SPS. In addition, any manual additions of new User Endpoints,Gateways, or Routes or manual modification to existing ones that are performed on the SSPwill be automatically reversed on any subsequent manual bulk import operation on the SSP.All needed provisioning modifications to User Endpoints and all additions of GatewayEndpoints and Routes or modifications to them must be performed on the Network SPS.

Manual bulk import from remote system on SSP


Figure 4: User Endpoints page showing manual Import and Export buttons



Figure 5: User Endpoints bulk export file dialog

Figure 6: User Endpoints bulk import file dialog

Scheduled ESA Data SynchronizationBoth Network SPS and SSP provide the capability to automatically provision Domains, UserEndpoints, Gateway Endpoints and Routes through an unattended process that downloadsprovisioning data from a remote system. This process executes at six-hour intervals. Theexecution times are not configurable. The process can be enabled or disabled through the

Scheduled ESA Data Synchronization


Network Database fields of System Wide Settings. If the primary and alternate IP addressesof the remote system’s database servers are entered into these fields, the process is enabled. Ifthe primary and alternate fields are set to the value “0.0.0.0”, the process is disabled.

Scheduled ESA Data Synchronization – Network SPSThe purpose of scheduled ESA Data Synchronization on the Network SPS is to periodicallyretrieve User information from the Avaya CS 2100 SSL and to create corresponding UserEndpoints on the Network SPS together with any required Domains. Domains on the NetworkSPS corresponding to those on the Avaya CS 2100 SSL are created only if there are Usersprovisioned in those Domains on the Avaya CS 2100 SSL. In addition, the Domains must beformatted according to specific guidelines in order for their Users to be added as UserEndpoints on the Network SPS. Refer to Avaya CS 2100 SSL provisioning guidelines for theSurvivable SIP Proxy on page 50. Note that the Network SPS does not have subtendingsubscribers and does not process calls; it only serves as an intermediate repository ofprovisioning information, which is distributed to SSPs.

Scheduled ESA Data Synchronization does not fully automate the process of provisioning theNetwork SPS. SPS User Endpoints have information that is not present on the Avaya CS 2100SSL and default values are used for this information when User Endpoints are created. Anydesired changes to this information must be made manually on the Network SPS. In addition,Gateway Endpoints and Routes are not imported from the Avaya CS 2100 SSL, which has noknowledge of gateways that are present within subtending Communities Of Interest or therouting of calls from User Endpoints to gateways. Gateway Endpoints and Routes must bemanually provisioned on the Network SPS in such a manner that they will be correctly importedfrom the Network SPS to the SSP. That is, Gateway Endpoints and Routes (as well as UserEndpoints) must be provisioned in a L1 Domain whose name corresponds to the configuredRealm on the SSP on which those entities will ultimately reside.

Part of the ESA Data Synchronization process cleans up stale information. For example, staleinformation would result from deleting a User on the Avaya CS 2100 SSL, or from moving aUser from one Domain to another. The set of User Endpoints on the Network SPS is comparedto the set of Users retrieved from the Avaya CS 2100 SSL. Any User Endpoints that are presenton the Network SPS but not present on the Avaya CS 2100 SSL are removed. After stale UserEndpoints are removed, L0 Domains, L1 Domains, and Service Domains are examined in thatorder, and any domains having no User Endpoints are removed. In general, it is notrecommended to manually provision domains and User Endpoints on the Network SPS.Specifically, manual provisioning of User Endpoints on the Network SPS that do not exist onthe Avaya CS 2100 should not be done with Network Database fields in System Wide Settingsconfigured to enable access to the Avaya CS 2100 because these manually provisioned UserEndpoints will be removed during the next Scheduled ESA Data Synchronization.

Any modifications that the scheduled ESA Data Synchronization process makes are to theStandby Database. When it concludes its operation it checks to determine whether it has made



any modifications to the Standby Database and if so, performs a cutover and commit operation,propagating the changes to the Active Database.

Scheduled ESA Data Synchronization on the Network SPS occurs daily at 12:00 AM, 6:00 AM,12:00 PM and 6:00 PM. These intervals are not configurable. However, if immediatesynchronization is required to pick up provisioning changes on the Avaya CS 2100 SSL, aManual Bulk Import operation can be performed. Refer to Manual bulk import and export ofUser Endpoints on page 43.

Scheduled ESA Data Sychronization creates two files: a log file (in XML format) and an exportfile (in CSV format). While it is executing, it writes information to the log file describing thecreation of new User Endpoints or Domains as well as any modifications to existing UserEndpoints or Domains. It also writes information about any Users that it retrieves from theAvaya CS 2100 SSL that do not meet the formatting requirements to be added as UserEndpoints, and it writes information about any errors that it encounters in finding, creating, ormodifying User Endpoints and Domains. When Scheduled ESA Data Synchronizationcompletes, it exports all User Endpoints in the Active Database to an export comma-separated value (CSV) file, which is formatted identically to the export file produced by aManual Bulk Export operation. No backups are done to the log file or the export file. Each timeScheduled ESA Data Synchronization begins execution it opens new copies of these files,overwriting the existing ones.

Scheduled ESA Data Synchronization - SSPThe purpose of Scheduled ESA Data Synchronization on the SSP is to retrieve the set ofprovisioned objects that represent its Community of Interest from the Network SPS. Thisconsists of User Endpoints and Domains that have been created from information importedfrom the Avaya CS 2100 SSL, any manual modifications to User Endpoints and Domains thathave been made to default values, and any Gateway Endpoints and Routes that have beenmanually provisioned on the Network SPS.

Scheduled ESA Data Synchronization on the SSP executes daily at 12:15 AM, 6:15 AM, 12:15PM, and 6:15 PM. These times are not configurable. Scheduled ESA Data Synchronization onthe SSP is in other respects identical to that on the Network SPS. It imports provisioning datainto the standby database and, if modifications have been made upon completion of theimportation, a cutover and commit operation is performed. It produces a log file and a CSV fileof exported endpoints. The file of exported endpoints can be retrieved manually. For moreinformation, see Manual bulk import and export of User Endpoints on page 43.

Scheduled ESA Data Synchronization - SSP


Avaya CS 2100 SSL provisioning guidelines for theSurvivable SIP Proxy

This section describes a recommended method for provisioning domains and users on theAvaya CS 2100 Session Server Lines (SSL) system, which provides the SSP with the abilityto recognize user endpoints, and direct dialing among subscribers subtending a particular SSPwhile in ESA mode.

Any user that is not provisioned according to this method will be reachable from other userson the same SSP (when in ESA mode) only through a translated route which will typically bea more expensive route (for example, a PSTN route). This method is based on arranging andnaming the domains on the Avaya CS 2100 SSL system in which users are located so as todefine the Service Domain, L1 Domain, L0 Domain, and SSP in which the users are located.

In this provisioning method, all users subtending a particular SSP in a particular ServiceDomain, L1 Domain, and L0 Domain are assigned on the SSL system to a unique sub-domain of a sub-domain of a Root Domain where the following correspondences hold:

• The Avaya CS 2100 SSL Root Domain corresponds to a Service Domain on the NetworkSPS or SSP. Multiple Root Domains can be provisioned on the Avaya CS 2100 SSLsystem, and therefore multiple Service Domains can be imported to the Network SPS.However, because the SSP retrieves only those Endpoints and Routes which belong toan L1 Domain whose name matches its configured realm, only a single Service Domainwill ever be present on an SSP.

• The first level sub-domain below the Avaya CS 2100 SSL Root Domain corresponds tothe SIP realm that is configured on the SSP. This also becomes the name of the L1 Domainon both the Network SPS and the SSP when user provisioning information is imported.The realm defines the subset of all SSL users which belong to a particular SSP. Multiplefirst level sub-domains can be provisioned below a Root Domain on the Avaya CS 2100SSL system, each one corresponding to a single SSP realm, and thus to a single SSP.Because only one realm can be configured on an SSP, only one L1 Domain is permitted onthe SSP. See Configuring the realm on the Survivable SIP Proxy (SSP) on page 31.

• The second level sub-domain below the Root Domain is a set of digit characters whichcorresponds to both L1 DN prefix and the L0 Domain name on the SSP. Multiple secondlevel sub-domains are permitted under a first level sub-domain, and thus multiple L1 DNPrefixes/L0 Domains are permitted on the SSP.

The following diagram shows SSL provisioning and distribution of data steps that follow thecompletion of the previous configuration procedures.



Figure 7: SSL Provisioning and distribution

In the previous example, there are two separate remote networks (that is, communities), eachcontaining a set of subscribers (users) and an SSP. There is a logical order to the provisioningand distribution of endpoint data as indicated by numbered items in the above diagram, asfollows:

1. Domains and related items such as Service Packages are created directly on theAvaya CS 2100 SSL system through its Provisioning Client. In this example, theRoot Domain is fsva.nortel.net. Under the Root Domain there are two sub-domains: realm0.fsva.nortel.net and realm1.fsva.nortel.net. These two sub-domains match the realm names configured on SSP0 and SSP1, respectively.Under each of these sub-domains is one or more sub-domains that are namedaccording to the dial plan in use within the network subtending the SSP. In the aboveexample, sub-domain realm0.fsva.nortel.net has two sub-domains:444.realm0.fsva.nortel.net and 445.realm0.fsva.nortel.net.

2. Users are provisioned through OSSGate. Follwing is an example OSSGatecommand to add user u1401 to domain 444.realm0.fsva.nortel.net:

NEW $ 9971401 ibn bnrrch 0 0 214 ssl1 00 0 01 0 SIP_DATA SIP_PACKAGE realm0-

Avaya CS 2100 SSL provisioning guidelines for the Survivable SIP Proxy


basic +SIP_URI [email protected] SIP_SUBDOMAIN 444.realm0.fsva.nortel.net +SIP_CLIENT_TYPE rua SIP_LOCATION richardson SIP_PASSWD 1234 $ +dpl y 10 dgt cnd noama name public u1401 $ cnamd noama cwt cwi 3wc $

3. Domain and User information is imported from the Avaya CS 2100 SSL databaseby the Network SPS.

4. Additional manual provisioning is performed on the Network SPS to add GatewayEndpoints and Routes and to add information to Domains and User Endpoints that isnot present on the Avaya CS 2100 SSL.

5. Domains, Gateway Endpoints, Routes, and User Endpoints are imported by theSSP from the Network SPS.

The following figures show examples of the Root Domain, first level sub-domain, and secondlevel sub-domain from the perspective of the Avaya CS 2100 SSL provisioning client. Notethat these are illustrative examples only; complete information for provisioning the Avaya CS2100 SSL system is beyond the scope of this document.

Refer to the following documents for more information:

• Session Server Lines Fundamentals, NN10437-111

• Session Server Lines Configuration, NN10437-511

• Session Server Lines Installation and Commissioning, Installation Method 35-1391

The following figures show examples for provisioning the Avaya CS 2100 SSL system.



Figure 8: Root Domain in Avaya CS 2100 SSL Provisioning Client

Figure 9: First level sub-domain in Avaya CS 2100 SSL Provisioning Client

Avaya CS 2100 SSL provisioning guidelines for the Survivable SIP Proxy


Figure 10: Second level sub-domain in Avaya CS 2100 SSL Provisioning Client



Chapter 7: SSP ESA interoperating with MG9000 ESA

The following information describes how the Media Gateway 9000 (MG 9000) interoperates withEmergency standalone (ESA) functionality.

Note that the Network Survivable SIP Proxy Server (SPS) is referred to as an Emergency SIP Proxy Server(E-SPS) in the MG 9000 environment.

ESA mode allows inter-nodal calls to complete when the MG 9000 is cut off from the call server. InternodalESA allows groupings of Media Gateway nodes into “communities of interest” (COI). All nodes in acommunity can communicate with each other during ESA, allowing calls to complete inside the communityduring ESA.

MG 9000 lines served by an Avaya CS 2100 can make calls to other MG 9000 lines in the same COI whileoperating in ESA. This feature enhances MG 9000 ESA functionality so that calls can be made outsidethe MG 9000 COI using a Network Survivable SIP Proxy Server (SPS).

Refer to Carrier VoIP Nortel MG 9000 Configuration, NN10096-511 which contains a procedure toprovision a remote SPS server for Avaya CS 2100 interoperability. The purpose of the procedure is toenable MG 9000 lines served by a Avaya CS 2100 to make calls outside of the MG 9000 COI whileoperating in ESA mode using a Network SPS.


SSP ESA interoperating with MG 9000 ESA


Chapter 8: Call flows

The following information describes normal and ESA mode call flows, and provides datafill examples fordial plan setup, as well as detailed solution examples.

• Normal mode on page 57

• ESA mode on page 58

• SIP SSP call flow and dial plan setup on page 60

• Registration call flow on page 63

• Detailed solution examples on page 64

While emergency routes are exposed during the isolation of a community, the SSP will attempt to routelocal calls within the community of interest (COI) based upon the datafilled endpoints within the community(L0 domain). Each datafilled endpoint will have either a gateway routing entry or a user based phone entrybased upon the dial plan rules. If the SSP is unable to successfully terminate a call within its owncommunity during ESA, the call will be forwarded to the ESA route. The ESA route will target a specificendpoint in the community whose responsibility is to forward the call out of the community (L0 domain).Each community can be comprised of a heterogenous mix of endpoint types with the exception of acommunity that involves an MG 9000 COI.

Normal modeThe following figure illustrates outgoing calls from the COI into the core switching system ofthe Avaya CS 2100, as well as incoming calls from the core switching system into the COI.


Figure 11: Endpoint to endpoint call flow (normal mode)

This call flow depicts calls occurring in normal mode (that is, the community is not isolated fromthe core switching device). In normal mode, the SSP acts as a tandem outbound proxy thattargets calls to the core switching device’s SIP interface (for example, SIP PBX). All outgoingcalls traverse the SSP (as noted by the circles in the diagram) whereas all incoming callsbypass the SSP landing directly on the terminating endpoint. However, this behavior changesupon the community becoming isolated from the core switch interface.

ESA modeThe following figure illustrates the call flows of the community devices upon experiencing anisolation event (ESA mode).

Call flows


Figure 12: Endpoint to endpoint call flow (ESA mode)

With respect to community isolation, the SSP routes calls locally using the dial plan datafilled atthe Network SPS. If the call cannot terminate locally, the SSP will use one of the exposedemergency fallback routes datafilled within the routes tab of the EM.

While DID calls have the ability to terminate within the community, this case is somewhatimpractical since, in normal mode, calls terminate on the community through the core switchingdevices. If DID calls were expected to terminate on the community, the outside user wouldhave to know that the community was isolated (that is, in ESA mode) and know what to dial toget into the community.

The exception to this event is where local PSTN trunks may terminate on the community and, innormal mode, calls tandemed into the central core switching device. In a practical sense, thistype of operation may be of some benefit so that a customer can dial a call locally into thecommunity, shuffle it up to the core with the core sending the call over the customer’s datanetwork to a remote location.

For example, a call in Dallas could terminate locally on a COI gateway, and that call then betandemed over the customer data network to Mumbai, India without incurring internationalcharges. Furthermore, if that particular community were to become isolated from the core, theterminating DID calls could still survive, fundamentally offering a survivable PSTN hop-off. Thistype of call is illustrated in the PSTN to gateway scenario of the call flow (see Figure 11:

ESA mode


Endpoint to endpoint call flow (normal mode) on page 58 and Figure 12: Endpoint to endpointcall flow (ESA mode) on page 59).

SIP SSP call flow and dial plan setupIf a dial plan were applied to the previous ESA mode call flow (see Figure 12: Endpoint toendpoint call flow (ESA mode) on page 59), keeping in mind the domain structure, the followingtable should be followed in order to properly route calls in and out of the COI.

Note that the gateways (GW EP) in the following tables refer to regular SIP trunking gatewaysand SIP to PSTN trunking gateways. Gateways such as analog station gateways (ASG) oranalog telephone adapters (ATA) are specialty gateways that vary widely in their operation ofSIP to TDM conversions and the method by which they register the phone sets that theyrepresent.

Terminating endpoint

type

Domaintype

(originating)

Domaintype

(terminating)

Dial plantype

Domainlevel

datafill

Routingdatafill

Endpointdatafill

User EP L0 domain(privatenumbers)

L0 domainof originator

4 digit None None 4 digit DNin UserEndpointtab



5 digit None None 5 digit DNin UserEndpointtab 1.


L0 domainof originator(same L1domain)

7 digit +accesscode

L1 accesscodedatafilled

None L1 DNprefix and4 digit DNor 5 digitDN

GW EP L0 domain(privatenumbers)


4 digit None Commonand uniquePrefixdatafilledagainst theendpoint

None

1 This effectively means that the first digit of the DN must appear in both the E.164 subscriber number as well as the 7 digitprivate number in order to be able to provide the functionality (for example, if the subsriber number = 985-3522 and the 7digit private number = 555-3522, then the 5 digit DN can be datafilled as 53522 in the User Endpoint tab) with an L1 DNprefix of 55 and a subsriber DN prefix of 98.

Call flows



type

Domaintype

(originating)

Domaintype

(terminating)

Dial plantype

Domainlevel

datafill

Routingdatafill

Endpointdatafill



5 digit None Commonand uniquePrefixdatafilledagainst theendpoint

None


type

Domaintype

(originating)

Domaintype

(terminating)

Dial plantype

Domainlevel datafill

Routingdatafill

Endpointdatafill


L0 domaindifferentthanoriginator(same L1domain)

7 digit L1 accesscodedatafilled

Commonand uniquePrefixdatafilledagainst theendpoint

None


L0 domaindifferentthanoriginator(same L1domain)

> 7 digit L1 accesscodedatafilled

Commonand uniquePrefixdatafilledagainst theendpoint

None

User EP E.164subscriber(publicnumbers)

E.164subscriber

7 digit Subscriberaccess codedatafilled(differentthan the L1access codefor privateL1)

None Subscriber Nxxdatafilledagainstthe user

User EP E.164national(publicnumbers)

E.164national

10 digit Nationalaccess codedatafilled(differentthan the L1access codefor privateL1)

None NationalNPAdatafilledagainstthe user

User EP E.164International (publicnumbers)

E.164International

11 digit Internationalaccess codedatafilled(different

None International CCdatafilled

SIP SSP call flow and dial plan setup



type

Domaintype

(originating)

Domaintype

(terminating)

Dial plantype


Routingdatafill

Endpointdatafill

than the L1access codefor privateL1)

againstthe user

GW EP E.164subscriber(publicnumbers)

E.164subscriber

7 digit Subscriberaccess codedatafilled(differentthan the L1access codefor privateL1)

SubscriberNxxdatafilledagainst theGW EP

None

GW EP E.164national(publicnumbers)

E.164national

10 digit Nationalaccess codedatafilled(differentthan the L1access codefor privateL1)

NationalNPAdatafilledagainst theGW EPGW

None

GW EP E.164International (publicnumbers)

E.164International

11 digit Internationalaccess codedatafilled(differentthan the L1access codefor privateL1)

International CCdatafilledagainst theGW EC

None

ASG/ATA E.164International (publicnumbers)

E.164International

11 Internationalaccess codedatafilled(differentthan the L1access codefor privateL1)

Full E.164International DNshould bedatafilledagainst theATA as aGW route

None

ASG/ATA E.164national(publicnumbers)

E.164national

10 Nationalaccess codedatafilled(differentthan the L1access codefor privateL1)

Full E.164NationalDN shouldbedatafilledagainst theATA as aGW route

None

Call flows



type

Domaintype

(originating)

Domaintype

(terminating)

Dial plantype


Routingdatafill

Endpointdatafill

ASG/ATA E.164subscriber(publicnumbers)

E.164subscriber

7 Subscriberaccess codedatafilled(differentthan the L1access codefor privateL1)

Full E.164SubscriberDN shouldbedatafilledagainst theATA as aGW route

None

ASG/ATA L1 domain(privatenumbers)

L1 domain(privatenumbers)

7 L1 accesscodedatafilled(differentthan the E.164 accesscode)

Full 7 digitDN mustbedatafilled inthe L0domainroutes forthisendpoint

None



5 None Full 5 digitDN mustbedatafilledas a routein the L0domain

None



4 None Full 4 digitDN mustbedatafilledas a routein the L0domain

None

Registration call flowThe following figure shows the registration process of the SSP.

Registration call flow


The SSP will send a “heartbeat” to the datafilled outbound server. If that heartbeat goesunanswered, the SSP state changes from normal mode to ESA mode and the emergencyroutes become exposed. Once this event takes place, all registrations that are received fromthe SSP (which would typically be forwarded to the outbound server) are answered with a 503Service Unavailable response. This response can be used by the registering endpoints as anindication that communication has been lost with the core switch. In essence, the SSP takesover the registration responsibility of the outbound server. However, while the SSP state is setto normal mode, registration information is merely passed between the registering endpointand the outbound server.

The exception to this registration process tends to be where analog station gateways (ASGs)and analog telephone adapters (ATAs) are concerned. In these cases, the devices must beconfigured such that the registration is sent directly to the outbound server, but all othersignaling is configured in proxy mode in order to have it sent to the SSP. In this case the ASGand ATA devices are datafilled in the SSP as a static gateway so that all outgoing signaling(with the exception of the REGISTER request) will traverse the SSP.

Detailed solution examplesThe following diagram shows a detailed example of call flows in normal mode.

Call flows


Figure 13: Normal mode

The following diagram shows a detailed example of call flows in ESA mode.

Detailed solution examples


Figure 14: ESA mode

The following diagram shows a detailed example of call flows in normal mode with generic SIPPBXs.

A trunk gateway (that is, Mediant 1000/2000, etc) is utilized in "survivable” mode to route callsto a trunk gateway. During normal mode, this trunk gateway can be utilized for trunking betweenthe Avaya CS 2100 and other PBXs/PSTN. To accomplish trunking in normal mode, SIP PBXtrunks are required between the SSP/SIP PBX and between the trunk gateway/SIP PBX.

SIP PBX to Trunk gateway: As with clients, the SIP PBX can communicate directly with thetrunk gateway, bypassing the SSP all together. An SIP PBX trunk is required between the SIPPBX and Trunk gateway.

Trunk gateway to SIP PBX: The trunk gateway communicates with the SSP, which in turnstandems SIP messaging to the SIP PBX. A SIP PBX trunk is required between the SSP andthe SIP PBX.

Call flows


Figure 15: Normal mode with generic SIP PBXs

Detailed solution examples


Call flows


Chapter 9: Upgrading or downgrading anSSP or Network SPS

This chapter provides information on upgrading or downgrading the SSP 1.0 application (Network SPSand SSP).

After an SSP 1.0 system is initially commissioned, it may be necessary to upgrade the system to applyfixes or enhancements, or to downgrade to a previous release. This is done by Redhat PackageManagement (RPM) replacement.

SSP 1.0 software releases are in the form of a zip file with the following naming convention:ssp-1.0-5.75.16.xx-00.zip

The zip file contains the SSP 1.0 application files. The SSP 1.0 application (both Network SPS and SSP)consists of the following RPM files:

• - Jboss-Quantum-5.75.16.xx-00.i386.rpm• - avaya-cs1000-solid-5.75.16.xx-00.4.50.0090.i686.rpm• - avaya-cs1000-sps-5.75.16.xx-00.i386.rpm• - nrsm-5.75.16.xx-00.i386.rpm• - nrsmWebService-5.75.16.xx-00.i386.rpm

The xx in the above file names indicates a 2-digit version number, which is the same for both the zipfile and all RPMs in a particular release. Each time a release is issued, the version number is incremented.Within this document:

• upgrading refers to replacing a currently installed RPM with another RPM whose version is greaterthan or equal to the existing RPM

• downgrading refers to replacing a currently installed RPM with another RPM whose version is lowerthan the existing RPM

A list of all the currently installed RPMs on an SSP or Network SPS (including version numbers) can beobtained by logging into the server as the Avaya user and executing the following command:

rpm -qaBecause the list produced by the above command is extensive, it can be piped through grep to find thecurrently installed RPM for a particular application, as in the following examples:

rpm -qa | grep Jboss rpm -qa | grep solid rpm -qa | grep sps rpm -qa | grepnrsm- rpm -qa | grep nrsmWeb

• Obtaining release software on page 70• Performing an upgrade on page 71


• Performing a downgrade on page 72• Handling errors during upgrades or downgrades on page 75

Obtaining release softwareUse this procedure to obtain SSP release software. The SSP 1.0 software release is obtainedvia download from the Technical Support Portal on http://www.avaya.com as follows.

1. Point your web browser to Avaya’s home page at http://www.avaya.com and log in.

2. On the home page, click the Support tab, and then the Training tab.The Technical Support page is displayed.

3. On the Technical Support page, click the Voice, Multimedia & UnifiedCommunications link.

4. Under the Communication & Application Servers heading, click theCommunication Server 2100 link.

5. On the Communication Server 2100 page, on the Software section click the Showall >> link.

6. Locate the Survivable SIP Proxy 1.0 load that you want to download and click its link.A download link for the zip file is displayed.

7. Right-click on the download link and select Save Link As ….

ResultThere are multiple options for getting the necessary files onto the Network SPS or SSP serversfor upgrading or downgrading.

If the intermediate host to which the SSP 1.0 release zip file was saved is network accessiblefrom the Network SPS and SSP servers and supports ftp or sftp, the zip file can be downloadedto a working directory on each server.

Another alternative is to burn the zip file to a CD-ROM and copy it from the CD-ROM to aworking directory on each server. For this method, perform the following steps:

1. In order to access files on a CD-ROM it must first be mounted. To mount the CD-ROM, log in to the Network SPS or SSP server as the Avaya user from either adirectly attached console or via a Secure Shell (SSH) client such as putty

2. Execute the following command: su root (When prompted, enter the superuserpassword.) mount /dev/hda exit cd /media/cdrecorderYou are now in the root directory of the CD-ROM.

Upgrading or downgrading an SSP or Network SPS


http://www.avaya.com

http://www.avaya.com

Once the SSP 1.0 release zip file is placed in a working directory on the Network SPS or SSPserver, it must be unzipped to extract the RPMs. Do the following:

1. To unzip a zip file on a Network SPS or SSP, log in to the server as the Avaya user viaa directly attached console or via a Secure Shell (SSH) client such as putty

2. Execute the following command: unzip <release_file_name>This extracts the set of RPMs into the current working directory. (See the followingexample.)

Job aid

The following shows and example of the unzip process:

[nortel@ssp0-0 tmp]$ unzip ssp-1.0-5.75.16.21-00.zip inflating:Jboss-Quantum-5.75.16.21-00.i386.rpm inflating: nortel-cs1000-solid-5.75.16.21-00.4.50.0090.i686.rpm inflating: nortel-cs1000-sps-5.75.16.21-00.i386.rpm inflating: nrsm-5.75.16.21-00.i386.rpminflating: nrsmWebService-5.75.16.21-00.i386.rpm [nortel@ssp0-0 tmp]$

Performing an upgradeUse this procedure to perform an RPM upgrade. These steps should be performed by logginginto the SSP or Network SPS server as the Avaya user. Login can be from a directly attachedconsole device (keyboard, video, and mouse) or remotely over a network from a host running aSecure Shell (SSH) client such as Putty.

1. Use the cd command to change to the directory containing the RPMs.

2. Stop all applications with the following command:su rootEnter the root password when prompted.appstart stop

3. For each RPM file, upgrade with the following command:rpm -U --force <new_rpm_filename>

4. When all RPMs have been successfully upgraded, restart all applications with thefollowing command:appstart start

5. When application startup is finished and the command prompt is returned, exit fromthe root user with the following command:

Performing an upgrade


exit

ResultJob aid

The following is an example of upgrading the RPM files. In this example, the existing spsapplication RPM is "avaya-cs1000-sps-5.75.16.20-00" and the supplied RPM upgrade file is"avaya-cs1000-sps-5.75.16.21-00.i386.rpm". The following shows the commands used, andthe responses produced.

[root@ssp0-0 rpm]# rpm -U --force avaya-cs1000-sps-5.75.16.21-00.i386.rpm Expanding libraries and modules for theSPS application package... executing post install... creatingapplication directories ... ln: `libosip2.so.3': File exists ln:`libosip2.so': File exists ln: `libosipparser2.so.3': File exists ln:`libosipparser2.so': File exists creating config directories ... SPSservice installation has completed. [root@ssp0-0 rpm]#

Performing a downgradeUse this procedure to downgrade the currently installed RPMs to a previous version. Thisprocedure can also be used to downgrade RPMs to an identical version in order to recoverfrom an incomplete or corrupted installation. These steps should be performed by logging intothe SSP or Network SPS server as the Avaya user. Login can be from a directly attachedconsole device (keyboard, video, and mouse) or remotely over a network from a host running aSecure Shell (SSH) client such as Putty.

1. Use the cd command to change to the directory containing the RPMs.

2. Stop all applications with the following commands:su rootEnter the root password when prompted.appstart stop

3. For each of the five SSP 1.0 RPMs, query each RPM for its name and remove it byexecuting the following commands:rpm –qa | grep <application_name>where<application name>is a short string identifying the application such as “Jboss”, “solid”, “sps”, “nrsm-” or“nrsmWeb”. This will list the RPM name of the installed RPM.)



rpm –e –nodeps <installed_rpm_name>4. Install the five downgrade RPMs by executing the following command for each RPM

file:rpm –ivh <new_rpm_filename>

5. When all RPMs have been successfully downgraded, start the applications with thefollowing command:appstart start

6. When application startup is finished and the command prompt is returned, exit fromthe root user with the following command:exit

7. When the avaya-cs1000-sps application is downgraded, directory /etc/opt/nortel/sps and its contents are removed. If, prior to downgrading, the network databaseaccess fields in Systemwide Settings were configured to enable remote databaseaccess in order to import provisioning data from a CS 2100 SSL or from a NetworkSPS, the information file used to locate the remote database must be manuallyrecreated before network database access will be functional. Do this as follows:

a. Wait until the Jboss and nrsm applications are fully initialized. Thistypically takes about five minutes after the applications are started.

b. Using a web browser, log in to the Enterprise Communications Manager(ECM).

c. Locate the network element that was just downgraded and click on itslink to get to its NRSM.

d. Navigate to Systemwide Settings and click the Save button. This willre-create the network database information file.

ResultJob aid

The following shows an example of querying and removing the currently installed RPMs.

[root@ssp0-0 rpm]# rpm -qa | grep Jboss Jboss-Quantum-5.75.16.20-00[root@ssp0-0 rpm]# rpm -e --nodeps Jboss-Quantum-5.75.16.20-00Unstalling the package... Deleting../opt/nortel/Jboss-Quantum[root@ssp0-0 rpm]# rpm -qa | grep solid nortel-cs1000-solid-5.75.16.20-00.4.50.0090 [root@ssp0-0 rpm]# rpm -e --nodepsnortel-cs1000-solid-5.75.16.20-00.4.50.0090 Unstalling the Soliddatabase server package done [root@ssp0-0 rpm]# rpm -qa | grep spsnortel-cs1000-sps-5.75.16.20-00 [root@ssp0-0 rpm]# rpm -e --nodepsnortel-cs1000-sps-5.75.16.20-00 Uninstalling the package...Deleting.. /opt/nortel/sps Deleting.. /etc/opt/nortel/sps[root@ssp0-0 rpm]# rpm -qa | grep nrsm- nrsm-5.75.16.20-00[root@ssp0-0 rpm]# rpm -e --nodeps nrsm-5.75.16.21-00 Unstalling the

Performing a downgrade


package... Deleting../opt/nortel/nrsm [root@ssp0-0 rpm]# rpm -qa |grep nrsmWeb nrsmWebService-5.75.16.20-00 [root@ssp0-0 rpm]# rpm -e --nodeps nrsmWebService-5.75.16.20-00 Unstalling the package...Deleting../opt/nortel/nrsmWebService [root@ssp0-0 rpm]#Job aid

The following shows an example of installing the downgraded RPMs. In this example the RPMsbeing downgraded to are version 19.

[root@ssp0-0 rpm]# rpm -ivh Jboss-Quantum-5.75.16.19-00.i386.rpmPreparing... ########################################### [100%]Installing Jboss application server for Quantum... 1:Jboss-Quantum########################################### [100%] InstallationCompleted. [root@ssp0-0 rpm]# rpm -ivh nortel-cs1000-solid-5.75.16.19-00.4.50.0090.i686.rpm Preparing...########################################### [100%] 1:nortel-cs1000-solid ########################################### [100%] executingSolid DB post install... Installation nortel Solid database servercompleted. [root@ssp0-0 rpm]# rpm -ivh nortel-cs1000-sps-5.75.16.19-00.i386.rpm Preparing...########################################### [100%] Expandinglibraries and modules for the SPS application package... 1:nortel-cs1000-sps ########################################### [100%]executing post install... creating application directories ... ln:`libosip2.so.3': File exists ln: `libosip2.so': File exists ln:`libosipparser2.so.3': File exists ln: `libosipparser2.so': Fileexists creating config directories ... SPS service installation hascompleted. [root@ssp0-0 rpm]# rpm -ivh nrsm-5.75.16.19-00.i386.rpmPreparing... ########################################### [100%]Installing NRS RPM 1:nrsm########################################### [100%] mkdir: cannotcreate directory `/etc/opt/nortel/nrs': File exists InstallationCompleted. [root@ssp0-0 rpm]# rpm -ivhnrsmWebService-5.75.16.19-00.i386.rpm Preparing...########################################### [100%] InstallingnrsmWebService RPM 1:nrsmWebService########################################### [100%] InstallationCompleted. [root@ssp0-0 rpm]#



Handling errors during upgrades or downgradesThis section describes how to handle various errors you may encounter during an upgrade ordowngrade.

RPM file corruptionThe rpm utility will not install a corrupted RPM file. When the rpm utility is used to create anRPM file, it computes an MD5 digest over the contents of the file and inserts the digest valueinto the file. When the rpm utility is used to install an RPM file, it computes the MD5 digest andcompares it to the digest in the RPM file. If the two are not identical, the rpm command willdisplay an error message and refuse to install the RPM file.

The following shows and example of this error:

[nortel@ssp0-0 rpm]$ rpm -U --forcenrsmWebService-5.75.16.21-00.i386.rpm error:nrsmWebService-5.75.16.21-00.i386.rpm: MD5 digest: BADExpected(f02d17f0320084064a6c007cf050e251) !=(86ef0d4ab400f9836f2d95df9c7485b3) error:nrsmWebService-5.75.16.21-00.i386.rpm cannot be installed[nortel@ssp0-0 rpm]$If this error is encountered, a non-corrupted RPM file must be obtained with which to re-runthe command.

Incomplete or corrupted installationIn order to install an RPM file correctly, the rpm command must run to completion and displayan Installation Completed message. If the installation is interrupted eitherintentionally or as a result of an unforeseen occurrence such as a power fault, the RPM willnot be correctly installed. An incomplete or corrupted installation is indicated whenever thereis a failure of a service to start, or when error messages are displayed when executing theappstart start command, or when a Network SPS or SSP fails to become fully operationalafter a server reboot.

It is not always obvious which RPM installation is corrupted. Also, there are dependenciesbetween some RPMs which can become broken when an RPM install is incomplete. Althoughusing rpm -U --force (as described in the section Performing an upgrade on page 71) to

Handling errors during upgrades or downgrades


force an upgrade of the RPM to the same version may fix some incomplete or corruptedinstallations, it is not guaranteed to do so. The most reliable way to recover from an incompleteor corrupted installation is to remove all RPMs using rpm –e, and then re-install the identicalRPMs using rpm –ivhin a manner similar to that described in the section Performing adowngrade on page 72.

Not running rpm as superuserWhen the rpm command is being used to modify an existing installation, such as during anupgrade, it must be run from the superuser (root) account. Attempting to execute the rpmcommand as a user other than the superuser causes an obscure error message to be displayedand the rpm command will not execute. If this occurs, execute su root, enter the superuserpassword when prompted, and re-execute the rpm command.

The following shows an example of this error, the recovery from the error.

[nortel@ssp0-0 rpm]$ rpm -U --force Jboss-Quantum-5.75.16.21-00.i386.rpm error: can't create transaction lock[nortel@ssp0-0 rpm]$ su root Password: [root@ssp0-0 rpm]# rpm -U --force Jboss-Quantum-5.75.16.21-00.i386.rpm Installing Jbossapplication server for Quantum... Installation Completed.[root@ssp0-0 rpm]#

Corrupted backup info fileIn some cases, an incomplete or corrupted RPM installation can result in a missing or corruptedbackup info file. This will be identified by an error message being periodically displayed at theterminal window when logged into a server.

The following shows an example of this error:

[root@ssp0-0 rpm]# May 28, 2009 11:27:19 AMcom.nortel.enterprise.nrs.bckup.BackupTimer startPeriodicReadOfFileINFO: Backup info could not be read... period read failed.java.lang.NullPointerException atcom.nortel.enterprise.nrs.bckup.BackupTimer.startPeriodicReadOfFile(Unknown Source) atcom.nortel.enterprise.nrs.bckup.BackupTimer.run(Unknown Source) atjava.lang.Thread.run(Thread.java:595)To resolve this error, follow the procedure in Incomplete or corrupted installation on page 75.



Database corruptionIn some cases, an incomplete or corrupted RPM installation can result in corruption of thedatabase. It is advisable to perform periodic automated or manual backups of the databaseso that a recovery from corruption is possible without resorting to manually re-provisioning.Use this procedure to recover from a corrupted database.

1. Remove all RPMs and re-install them as described in Incomplete or corruptedinstallation on page 75. When the RPMs have all been re-installed, perform thefollowing steps before executing the appstart start command. (Note that thesesteps are performed as the superuser.)

2. Enter the command cd /var/opt/nortel/solid.

3. Enter the command rm -rf *.

4. Enter the command appstart start.

5. When startup is complete, log in to the ECM.

6. Click on the link for the Network SPS or SSP that is being recovered

7. Navigate to Tools, Restore and perform a restore operation using an SSP 1.0backup file that was previously created on this server through an automated ormanual backup.

Database corruption


configuration — survivable sip proxy (ssp)

Documents