Avaya Session Manager (SM) Redundancy
To support redundancy in Avaya SM deployments, the Oracle® Enterprise Session Border Controller can use the mechanisms for maintaining multiple connections defined in RFC 5626. In an Avaya SM deployment, this scenario is referred to as Dual Registration.
RFC 5626 specifies a method of maintaining connections between UAs and proxies, and outlines a general means for UAs to establish connection redundancy. The Oracle® Enterprise Session Border Controller can use RFC 5626 specifically for redundancy in Avaya SM Dual Registration deployments. Such a deployment allows the network to continue to provide service by way of a redundant Avaya SM, when the primary Avaya SM stops responding.
Oracle® Enterprise Session Border Controller configuration requires adding the rfc 5626 SPL option. In addition to adding the SPL option, the Oracle® Enterprise Session Border Controller configuration design separates Avaya SMs and UA traffic by way of using realms.
How Avaya Session Manager (SM) Redundancy Works
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 uniquereg-idvalues 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: 0Note 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: 0Registration Caching
Enabling the RFC 5626 SPL option causes the Oracle® Enterprise Session Border Controller to store a single, entire contact header in its registration cache for the AOR. When an Avaya SM switchover occurs, the Oracle® Enterprise Session Border Controller updates the AOR by replacing the contact header with the new one. The Oracle® Enterprise Session Border Controller does not store more than one contact per AOR. The Oracle® Enterprise Session Border Controller establishes a flow with only the active Avaya SM.
Session Manager Mapping
- The primary session manager to the primary SBC IP address
- One or more redundant session managers to one or more redundant SBCs
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."
Map a Session Manager to a Session Border Controller
You can map one or more session managers to an Oracle® Enterprise Session Border Controller (E-SBC) to provide redundancy and load balancing.
- Note the private IP address of the session manager and the public SIP interface IP address of the session border controller that you want to map.
Map the private IP address of the session manager to the public SIP interface IP address of the E-SBC.
Configure Avaya Session Manager (SM) Redundancy
The rfc5636 SPL option allows the Oracle® Enterprise Session Border Controller to support Avaya Dual Registration for establishing redundant UA registration.
The rfc5626 option must be configured at the global level under spl-config or using the Web GUI. The rfc5626 option is not recognized in the session-agent, realm-config, or sip-interface.
To configure the rfc5626 option:
system
spl-config
spl-options rfc5626You 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 Client Failover
Avaya telephones (clients) require notification when the connection between the access Oracle® Enterprise Session Border Controller (E-SBC) 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 E-SBC 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 E-SBC also deletes all registrations associated with the out-of-service Session manager from the E-SBC registration cache.
The following diagram shows atypical Avaya topology consisting of a single Avaya client (a telephone), a single E-SBC, and a single Avaya Session Manager that provides subscription and registration services for the telephone. If connectivity between the E-SBC 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 E-SBC 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 E-SBC 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 E-SBC. If a Session Manager goes out-of-service, the E-SBC 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.
Avaya Attended-Transfer-Enable SPL
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:
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.