To support Avaya SM redundancy, you configure multiple realms on the access side and the core side of the Oracle® Enterprise Session Border Controller. These realms create the primary path and backup path for accessing a redundant Avaya SM.

Consider two Avaya SMs deployed for redundancy. You configure a core side realm for each Avaya SM and you configure two access side realms. Each access side realm is associated with the applicable core side realm, to which a UA sends registration messaging. The following illustration shows this configuration.

The operational scenario consists of the Avaya SM infrastructure providing configuration information to the UAs. The information includes the 2 proxy addresses, targeting the Oracle® Enterprise Session Border Controller access-side interfaces. The UA knows which proxy is for the primary path, and sends initial REGISTER messages by way of that path. While the primary Avaya SM is up, the UA manages all registration exchanges, including refresh and re-register procedures, on the primary path. If the primary Avaya SM stops responding, the infrastructure informs the UA that it needs to register with the backup Avaya SM. The UA registers with the backup Avaya SM using the backup path.

The UA, by way of configuration, populates the backup registration and subsequent registration messages so that the Avaya SM infrastructure knows that the registrations are for the same UA. Key elements of the messaging and their use by the Avaya dual registration infrastructure include:

• reg-id - A contact header field parameter value that specifies individual registrations. UAs use unique reg-id values to specify registrations for individual flows.
• instance-id (+sip.instance) - A URN within the contact header that specifies a UA instance. UAs use the same Instance ID information in REGISTER exchanges to indicate that the registrations belong to the same UA.
• Route - The target proxy for the message. The UA uses route headers to define the separate paths to the Oracle® Enterprise Session Border Controller.

The Avaya SM uses reg-id in conjunction with instance-ID to manage dual registrations. By keeping instance-ID the same and sending a new reg-id, the infrastructure recognizes that a redundant registration was generated because a session manager switchover occurred.

Normally, multiple reg-ids based on a single contact would trigger a "move" procedure. The presence of a single instance-ID tells the infrastructure that the reg-id change does not indicate a move.

The following example REGISTERs depict the population of these elements for the purposes of an Avaya dual registration scenario.

 REGISTER sip:example.com SIP/2.0 
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036 
Max-Forwards: 70 
From: Bob <sip:bob@example.com>;tag=d879h76 
To: Bob <sip:bob@example.com> 
Call-ID: 8921348ju72je840.204 
Supported: path, outbound
Route: <sip:ep1.example.com;lr>
CSeq: 1 REGISTER Supported: path, outbound 
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=1; 
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>" Content-Length: 0

Note the following redundant registration. The registration includes a different route header for the second Oracle® Enterprise Session Border Controller realm. It also includes a new reg-id and the same instance-ID.

 REGISTER sip:example.com SIP/2.0 
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036 
Max-Forwards: 70 
From: Bob <sip:bob@example.com>;tag=d879h76 
To: Bob <sip:bob@example.com> 
Call-ID: 8921348ju72je840.204 
Supported: path, outbound
Route: <sip:ep2.example.com;lr>
CSeq: 1 REGISTER Supported: path, outbound 
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=2; 
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>" Content-Length: 0

To map a redundant session manager to a redundant SBC, map the private IP address of the redundant session manager to the public SIP IP address configured in HTTP-ALG, Public on the SBC. For instructions, see "Map a Session Manager to a Session Border Controller."

You can map one or more session managers to an Oracle® Enterprise Session Border Controller (ESBC) to provide redundancy and load balancing.

1. Access HTTP ALG: Configuration, Session Router, HTTP ALG.
2. On the HTTP ALG page, click Add and do the following:

   name	Enter a name for this HTTP Application Layer Gateway.
   state	Select to enable this configuration.
   description	Enter a description of this HTTP Application Layer Gateway.
   private-realm-id	Select the private realm from the drop-down list.
   private-address	Enter the private IP address.
   private-destination-address	Enter the public IP address.
   destination-port	Default: 80. Valid values: 1-65535.
   public-realm-id	Select the public realm from the drop-down list.
   public-address	Enter the public IP address.
   public-port	Default: 80. Valid values: 1-65535.
   session-manager-mapping	Set the following: Set the IP address of the session manager. Set the IP address of the public interface. Set the port for SIP calls. Default:5050. Valid values:1-65535. Set the transport protocol. Default: TCP. Valid values: TCP | TLS | UDP.
   dynamic-acl	Select to enable dynamic ACL.
   max-incoming-conns	Set the maximum number of incoming connections allowed. Default: 0. Valid values: 0-4294967295.
   per-sec-ip--max-incoming-conns	Set the maximum number of HTTP connections allowed per peer. Default: 0. Valid values: 0-4294967295.

3. Click OK.
   The system lists the new map on the HTTP ALG page.
4. Save the configuration.

The rfc5636 SPL option allows the Oracle® Enterprise Session Border Controller to support Avaya Dual Registration for establishing redundant UA registration.

1. In Superuser mode, type configure terminal and press <Enter>.
   ORACLE# configure terminal
2. Type system and press <Enter>.

   ORACLE(configure)# system
   ORACLE(system)#

3. Type system and press <Enter>.

   ORACLE(system)# spl-config
   ORACLE(spl-config)#

4. Type rfc5626 and press <Enter>.

   ORACLE(spl-config)# rfc5626
   ORACLE(spl-config)#

5. Type done to save your work.
6. Save and Activate your configuration.

system
	spl-config
		spl-options          rfc5626

You can also configure the rfc5626 option using the Web GUI. The procedure consists of simply opening the spl-config dialog, adding the SPL option, then saving and activating.

Avaya telephones (clients) require notification when the connection between the access Oracle® Enterprise Session Border Controller (ESBC) and the Avaya Session Manager, which provides client subscription and registration services, stops responding. In the absence of such notification, the Avaya client can become unreachable for up to 24 hours. Oracle addresses this problem by enabling the ESBC that loses connectivity with an Avaya Session manager to transmit a TCP/FIN(ish) to all Avaya clients previously supported by the unreachable Session Manager. The TCP/FIN alerts clients of the need to re-register when connectivity to the Session Manager is restored.

In addition to issuing alerts to impacted clients, the ESBC also deletes all registrations associated with the out-of-service Session manager from the ESBC registration cache.

The following diagram shows atypical Avaya topology consisting of a single Avaya client (a telephone), a single ESBC, and a single Avaya Session Manager that provides subscription and registration services for the telephone. If connectivity between the ESBC and the Session Manager is lost, the Avaya client requires a TCP/FIN(ish) message that alerts the client to invalidate its subscription status and to re-subscribe when the TCP connection becomes available. Without receipt of the TCP/FIN, the phone remains unaware of its state change and will not receive notifies from the Session Manager until it re-subscribes (which by default is 24 hours later).

The ESBC supports redundant access topologies, based on RFC 5626—Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). This topology accomplishes redundancy by registering an Avaya telephone to multiple Session Managers, as shown below.

In the preceding diagram, the ESBC maintains connections with two Avaya Session Managers, which both share state information and act as a registrar and proxy for the Avaya telephone. The client establishes redundancy with two TCP connections to the domain. Redundant connections are differentiated by a unique reg-id contact header field parameter. In the preceding illustration, two reg-ids TLSRegID 1 and TLSRegID 2 are created for different Session Managers on the same ESBC. If a Session Manager goes out-of-service, the ESBC sends a TCP/FIN message to the Avaya client for the reg-id associated with the unavailable Session Agent, and deletes all associated registration cache entries.

Legacy Oracle® Enterprise Session Border Controller software versions do not fully support the standard attended transfer scenario as it is described in RFC 5589, which describes best practices for call control and transfer of SIP-based call sessions. In a deployment in which the IP addresses on the public, or access, side of the Oracle® Enterprise Session Border Controller are not routable from the private or core sides, the flow will fail. The Attended-Transfer-Enable SPL addresses this issue.

Within an Avaya environment, each Avaya endpoint is known by a different URI on the access side of the Oracle® Enterprise Session Border Controller than it is on the core side. Currently, when the REFER message sent from the Transferor to the Transferee crosses from the access side to the core side, the URIs in the Refer-to and Referred-by headers are not changed from the URIs known on the access side to those known on the core side. Often this is easily overcome because the REFER that eventually reaches the Transferee still contains access-side URIs, which are known to the Transferee. Thus, the transferee can construct the INVITE correctly. In an environment in which some element of the core, such as an Avaya Session Manager (SM) or Call Manager (CM) has more control over the calls, this element may use the Refer-to and Referred-by URIs in its logic. For this reason, the Refer-to and Referred-by headers must contain the core-side URIs for those endpoints because the core element will have no knowledge of the access-side URIs

In order to control the flow properly, certain key URIs must be mapped from access-side to core-side and vice versa in the following messages:

• The REFER send from the Transferor to the Transfer Target
• The INVITE with Replaces header sent from the Transferee to the Transfer Target
• All subsequent requests sent from the Transferee to the Transfer Target in the dialog established by the INVITE with Replaces header

The Avaya Attended Transfer SPL provides RFC 5589 conformity by mapping access-side and core address as follows:

1. When transferor-->transfer target INVITE passes through the E-SBC from access to core, change the Refer-to URI from the access URI to the corresponding core URI.
2. When transferor-->transfer target INVITE passes through the E-SBC from access to core, change the Referred-by URI from the access URI to the corresponding core URI.
3. When transferor-->transfer target INVITE passes through the E-SBC from core to access, change the Refer-to URI from the core URI to the corresponding access URI
4. When transferor-->transfer target INVITE passes through the E-SBC from core to access, change the Referred-by URI from the core URI to the corresponding access URI.
5. When transferree-->transfer target INVITE with Replaces header passes through the SBC from access to core, change the Request-URI from the access URI to the corresponding core URI.
6. When transferree-->transfer target INVITE with Replaces header passes through the SBC from access to core, change the Referred-by URI from the access URI to the corresponding core URI.
7. When transferree-->transfer target INVITE with Replaces header passes through the SBC from core to access, change the Request-URI from the core URI to the corresponding access URI.
8. When transferree-->transfer target INVITE with Replaces header passes through the SBC from core to access, change the Referred-by URI from the core URI to the corresponding access URI
9. When any subsequent request in the dialog initiated by the INVITE with Replaces header passes through the SBC from access to core, change the Request-URI from the access URI to the corresponding core URI.
10. When any subsequent request in the dialog initiated by the INVITE with Replaces header passes through the SBC from core to access, change the Request-URI from the core URI to the corresponding access URI.