Multi-Device Access feature description

Last Updated : Feb 24, 2020 |
Prolog information
Note:
  • Device Adapter supports Multi-Device Access (MDA) only for UNIStim endpoints.
  • Avaya Aura® supports MDA on the SIP phones that are capable of supporting the MDA feature.
    The J-series 3PCC phones do not support the Avaya Aura® SIP messaging that is required for MDA. If a J-Series 3PCC phone registers to a Device Adapter station definition for MDA, the buttons do not map correctly. This leads to a major loss of function. Hence, Avaya recommends that you do not use a J-series 3PCC phone for MDA.
    However, MDA is supported on a J-Series Avaya Aura® phone.
Multi-Device Access is defined in the Avaya Aura® Communication Manager Feature Description and Implementation guide as follows:
“With the Multi-Device Access (MDA) feature, a SIP user can register more than one SIP device with a single extension. For example, a user has 96X1 at the desk, 96X1 in the lab, and Avaya one-X® Communicator on the laptop. All these devices are registered with the same extension 123456. When a call arrives at extension 123456, all the devices are alerted. The user can answer the call from any one of the devices. If required, the user can bridge on to the call from one of the idle devices by using the Simulated Bridge Appearance (SBA) feature. Therefore, the call can be handed off between devices without parking the call.”
An administrator must configure MDA based on the topology requirements of the user.
Depending on how an administrator has configured MDA for an Avaya Aura® user, the Avaya Aura® user can register up to 10 SIP devices with the same extension. However, if you configure MDA to include Device Adapter UNIStim endpoints in addition to other traditional Avaya Aura® SIP endpoints, Avaya recommends that out of the 10 SIP endpoints only one endpoint should be a Device Adapter UNIStim endpoint. This is because registering two or more UNIStim endpoints with the same TN is non-deterministic in MDA. If a node with the least load receives this registration request, but already has this TN registered, the registration attempt fails. The attempt to register the second or subsequent endpoint may fail because only one instance of a TN can register per node.
Note:
For MDA, ensure that all Avaya Aura® SIP endpoints that are registered concurrently with UNIStim endpoint connect to Session Manager by using secure connection (TLS).
Till Device Adapter Release 8.1.1, the administrator must also clear the Block New Registration When Maximum Registrations Active check box to ensure timely fail-over support. If the Block New Registration When Maximum Registrations Active check box was selected, fail over was delayed because Device Adapter waits for the existing registration to be declared failed by Session Manager. Hence, the Block New Registration When Maximum Registrations Active check box must be clear to support MDA and fail over in case of network problems. 
In Device Adapter Release 8.1.2, enhancements in fail over handling removes this restriction. For more information, see Multi-Device Access feature administration.
This is a true MDA environment where two or more endpoints are registered concurrently with Session Manager.
Concurrently registering two or more UNIStim endpoints with the same TN is non-deterministic in MDA. Because the other Avaya Aura® SIP endpoints do not register to Device Adapter, fail-over is not a problem for the Avaya Aura® SIP endpoints. Therefore, having one Device Adapter UNIStim endpoint and nine 96x1 endpoints, all registered concurrently is permissible. But, having just two Device Adapter UNIStim endpoints register concurrently might lead to service failure.
The intent of MDA is to allow a single user to move to another part of the office and use a SIP endpoint in that location just like the user’s desk phone. After the SIP endpoint is registered, the endpoint is a local copy of the user’s phone. Therefore, even if the maximum number of simultaneously registered devices is set to more than one and if more than one endpoints are registered, only one endpoint is in use at a time because a single user is supposed to use this service.
For example, the user has two or more sets registered in the MDA user station definition. When a call arrives, all registered stations are alerted. When the user answers at one station, the other stations end the alerting, but will show the call status in the icon or lamp associated with the call appearance. The user cannot place other calls from the same call appearance on any of the other endpoints that are registered for MDA, until the call ends. But, if the user switches phones or asks someone else to join the call at one of the other endpoints that the user registered for MDA, the other endpoints can join the call as Simulated Bridge Appearances (SBA). This behavior is similar to the SCA feature of CS 1000, except that CS 1000 does not support MDA. For CS 1000, the calls are made to different user stations and the true bridged appearances are applicable.
Note:
Because these are two instances of a single extension joining a call, Avaya Aura® neither considers it as a conference nor indicates that a conference exists.
With MDA, you can define a single user station of any normal endpoint type. Prior to Device Adapter, this could be a variant of either the 96x1 or J-series phone. With Device Adapter, you can configure MDA for the CS 1000 IP stations.
Other stations may or may not be able to register as this user station based on whether the endpoint type has a mapping function on System Manager to correctly map feature button types. The mapping function allows the buttons to be defined. The service is provided to all endpoints that can register as this user as per the button definition of the user station. For example, 96X1, J-Series, or CS1K-IP can register as a CS1K-IP endpoint.
Note that different CS1K-IP endpoints may not have the same number of programmable feature buttons. Using an endpoint with fewer buttons results in loss of these feature buttons.
If a user SIP registers with station types that differ from the station definition, then to avoid loss of keys, Avaya recommends that you use an endpoint with the least number of keys as the primary station.
In addition, the CS1K-IP endpoints and Avaya Aura® SIP endpoints have not only different number of buttons, but many features that use a Feature Key in CS 1000 use an item from the Feature List on the Avaya Aura® SIP endpoint. As a result, an exact mapping between the CS 1000 endpoints and Avaya Aura® SIP endpoints may not be possible.
However, even if the appropriate buttons defined on the station definition are not available or cannot be mapped on a station type, you can use the appropriate FACs to perform the function of these missing buttons, and register the endpoint as the user station.
Note:
If a user who is on a call by using a device that is configured for MDA tries to join the call by using another device that is configured for MDA, Communication Manager verifies the status of the Exclusion feature for the device. If the Exclusion feature is enabled for the device, then the other device cannot join the call until the user who enabled the Exclusion feature disables the Exclusion feature in Communication Manager.
For information about MDA and Sequential Registration in Call Center Elite, see Sequential Registration and MDA in a Call Center Elite environment in Appendix H: Call processing features and services.