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 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

Registration 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.