Frequently asked questions

Last Updated : Mar 22, 2021 |
Prolog information
Metadata
Keywords:

What is the terminology used in this document to differentiate between the SIP endpoint families for programming?

  • UNIStim desk phones can be either CS1K-IP SIP endpoints (UC endpoints) or CS1K-IPCC SIP endpoints (call center endpoints).
  • Digital desk phones are subdivided into three families of SIP endpoints:
    • M3900 series digital desk phones are programmed as CS1K-39XX endpoints.
    • M2216 and M2616 digital desk phones are programmed as CS1K-2COL endpoints. Note that 2COL represents the two columns of 8 keys on these desk phones.
    • M2006 and M2008 digital desk phones are programmed as CS1K-1COL endpoints. Note that 1COL represents the single column of 6 or 8 keys on these desk phones.
    • European digital desk phones conform to this endpoint nomenclature as well, based on the number of key/lamp strips.
  • Analog desk phones are CS1K-ANA SIP endpoints.

What is the terminology used in the document to differentiate between a physical desk phone and a SIP endpoint?

  • UNIStim phones:
    • Desk phone nomenclature:
      • The terms “UNIStim desk phone” or “UNIStim phone” are used to refer to the UNIStim IP desk phone family.
      • The terms “UNIStim desk phone” or “UNIStim phone” are used along with the model number to refer to a specific UNIStim IP desk phone. For example, UNIStim 1140e desk phone or UNIStim 1140e phone.
    • SIP entity nomenclature:
      • The term “UNIStim endpoint” is used to refer to the family of UNIStim IP desk phones as SIP entities.
      • The term “UNIStim endpoint” is used along with the model number to refer to a specific UNIStim SIP entity variant. For example, UNIStim 1140e endpoint or UNIStim 1140 endpoint.
        Note that the “e” in 1140e refers to the desk phone being used with IP (the Ethernet). Similarly, the prefix “I”, which stands for IP, is often not added to the i2000 series phones.
  • M3900 series digital desk phones:
    • Desk phone nomenclature:
      • The terms M3900 series digital desk phone, M3900 series desk phone, M3900 phone, or M3900 are used to refer to the family of M3900 series digital desk phones.
      • The terms M3900 series digital desk phone, M3900 series desk phone, M3900 phone, or M3900 are used along with the model number to refer to the specific M3900 phone models. For example, M3904 phone or 3904 phone.
    • SIP entity nomenclature:
      • The terms 39XX endpoint, 39xx endpoint, or CS1K-39XX are used to refer to the family of M3900 series digital desk phones as SIP entities.
      • The terms 39XX endpoint, 39xx endpoint, or CS1K-39XX are used along with the model number to refer to a specific M3900 SIP entity variant. For example, M3904 endpoint or 3904 endpoint.
    • All other digital desk phones:
      • The 1COL and 2COL phones are not usually described as families. These phones were part of the Aries family in CS 1000.
      • The terms “2616 phones” or “2616 desk phones” are used to refer to desk phones.
      • The term “2616 endpoint” is used to refer to the SIP entity.

A multi-line digital or UNIStim phone on CS 1000 can be assigned multiple numbers (extensions). How do I configure the same functionality on Communication Manager? Are there licensing implications?

Each Device Adapter endpoint must be associated with a Communication Manager station. A Communication Manager station is administered with a single number/extension. If an additional number/extension must be associated with a Communication Manager station, the station has to “bridge” the number of another Communication Manager station by means of the bridged appearance button. This means that another Communication Manager station must be administered with the desired number as the extension. So, for every distinct number/extension used on a multi-line phone, there must be a Communication Manager station administered that has the extension of that number. Note that several stations can bridge the same number. Also note that the bridging can be administered in a Single Call Arrangement (SCA) mode (using the “regular” Communication Manager bridged appearance button) or in a Multiple Call Arrangement (MCA) mode (using the “MCA” Communication Manager bridged appearance button). This may have licensing implications. If a set of numbers/extensions is larger than the set of physical phones sharing them, additional Suite Licenses are required to administer the so-called phantom or “X-Port” stations to “host” the extra numbers/extensions.

What are the options for deploying Device Adapter?

Device Adapter is deployed co-resident with Avaya Aura® on premise or in the Cloud with an option for remote site deployment for local survivability. For more information, see the following topics:

How is local survivability configured?

Local survivability requires the Device Adapter and Avaya Breeze® platform instances to be deployed co-resident with Branch Session Manager and the local gateway. Device Adapter registers to Branch Session Manager for continued service if connectivity to the primary and secondary Session Managers becomes unavailable. For more information, see Device Adapter deployment for Local Survivability.

Can Device Adapter be deployed on a General-Purpose Avaya Breeze® platform cluster with other snap-ins?

Device Adapter is a CPU-intensive, call processing application. Device Adapter must be deployed on a Core Platform cluster only. Only Device Adapter snap-in and selected Avaya-developed snap-ins such as CallEventController and EventingConnector can be installed. Device Adapter snap-in cannot be co-resident with any other snap-in on this cluster type.

How is data migrated from CS 1000 to an Avaya Aura® solution?

Avaya ProVision is used to migrate the CS 1000 endpoint information to the Avaya Aura® solution. Avaya ProVision can do the following:
  • Create a data set corresponding to a CS 1000 instance by collecting data from the running instance.
  • Create a data set corresponding to a Communication Manager instance by collecting data from the running instance.
  • Migrate stations from a CS 1000 solution to an Avaya Aura® solution on a group-by-group basis.
    Note:
    All members of a groups should be migrated during the same step, and to the same Communication Manager instance, to preserve group features such as Multiple Appearance Directory Numbers (MADN).
    Note:
    • The class of service (CLS) of CS1K_IPCC stations is AGN or SPV.
    • The stations belonging to multiple CS 1000 instances can be migrated to the same Communication Manager instance if sufficient Communication Manager capacity exists. Avaya ProVision provides a directory number prefixing mechanism to resolve directory number conflicts, and TN replacement mechanism to avoid TN conflicts. However, you may still encounter TN conflicts.
      Till Device Adapter Release 8.1.1, this TN conflict could be resolved by configuring the appropriate System ID and deploying multiple Device Adapter instances.
      In Device Adapter Release 8.1.2, you can migrate endpoints from multiple CS 1000s to a single Avaya Breeze® platform cluster. This is because ProVision of the latest release, which is used with Device Adapter Release 8.1.2, allows you to modify the TNs during migration.
  • ProVision creates System Manager Managed Elements for Media Gateway Controllers.

What licensing is required for Device Adapter?

For information about the licensing required for Avaya Device Adapter Snap-in, see Licensing.

How is an endpoint associated with a Device Adapter cluster?

Device Adapter is deployed on a cluster of Avaya Breeze® platform servers referred to as the Device Adapter cluster.
A CS 1000 endpoint is associated with the whole Device Adapter cluster by associating the Cluster IP with the S1 (primary) and S2 (secondary) server values of the endpoint. This association between an endpoint and Device Adapter cluster is not administered in System Manager. The endpoint can then register with any Device Adapter cluster by changing the Cluster IP in the S1 Server or S2 Server settings.
Note:
The SecureLink IP is used instead of the Cluster IP in single server deployments.
Important:
A Device Adapter cluster is allocated to a specific CS 1000 system. All endpoints registered to the cluster must belong to the CS 1000 system allocated to the cluster.

Can an endpoint be associated with more than one Device Adapter cluster?

A CS 1000 endpoint can be associated with a maximum of two clusters, the primary and secondary Device Adapter cluster. This is achieved through the S1 (primary) and S2 (secondary) server settings. Each cluster consists of multiple Avaya Breeze® platform servers and nodes.
Registration with the primary cluster provides high availability failover from a single node failure. Registration with the secondary cluster provides geographic redundancy. Existing calls are preserved but cannot be modified after the originally registered node fails.

Are endpoints able to connect to different Device Adapters simultaneously?

An endpoint is registered to a single Device Adapter server in a Device Adapter cluster at any one time. The endpoint registers with another server in the cluster if the connected registered server or the link to the server fails. The endpoint registers with the secondary Device Adapter cluster if none of the servers in the primary cluster are available.

Does Device Adapter require user provisioning information from System Manager?

Yes. Device Adapter requires user provisioning information from System Manager.

How is Device Adapter administered?

System Manager provides a graphic interface to administer Device Adapter. The Avaya Breeze® platform section of System Manager is used to create the Avaya Breeze® platform cluster, install the snap-in, and administer all attributes. Media Gateways are administered as Managed Elements in System Manager.

Can multiple Device Adapter instances be deployed to accept overlapping TNs to support two CS 1000 systems consolidating to one Communication Manager?

There are two ways to perform a migration where several CS 1000 systems are migrated to the same Avaya Aura® solution.
  1. The TN space of the migrated systems is manually merged in such way that any overlap of endpoint TNs is eliminated.
    • This may require a lot of manual administrative changes.
    • This assumes that the desired capacity can be achieved using a single TN space.
    • A single Device Adapter cluster can be used for all CS 1000 systems.
      Note:
      A single Device Adapter cluster using multiple CS 1000 system leads to Terminal Number overlap.
    • This assumes that the desired capacity can be achieved using a single Device Adapter cluster.
  2. The TN space on each CS 1000 system is left as is even though there might be overlaps in usage of endpoint TNs.
    • This avoids the need for the manual TN space merger.
    • This requires deployment of a dedicated Device Adapter cluster for each migrated CS 1000 system.
    • This migration solution has better scalability.
  3. When collapsing multiple CS 1000 systems into a single Avaya Breeze® platform cluster, ProVision can be used to change TNs to avoid TN overlapping.
Note:
The System ID, Loop, and Shelf value for each MGC in a solution should be unique.

How many endpoints are supported by a single Device Adapter node?

The capacity of a virtual machine running the snap-in depends on the resources reserved for the virtual machine and if any other snap-ins are deployed on the same Avaya Breeze® platform cluster.
In addition, the capacity of a virtual machine running the snap-in for a call center environment also depends on the capacities and capabilities of the call center. Because every call center environment is different, no fixed capacity rules can be defined. The figures provided in this section for a CC environment are guidelines for cluster considerations in a CC environment.
The capacity figures provided in this section apply when Device Adapter is the only snap-in installed on the cluster.
Cluster capacity for a UC environment:
  • Up to 1000 endpoints per Device Adapter node running on an Avaya Breeze® platform Profile 2 virtual machine.
  • Up to 5000 endpoints per Device Adapter node running on an Avaya Breeze® platform Profile 4 virtual machine.
  • Up to 40 MGCs with digital or analog endpoints per Device Adapter node running on an Avaya Breeze® platform Profile 4 virtual machine.
    However, the number of endpoints, including the endpoints on the MGCs and the UNIStim endpoints, cannot exceed the maximum of 5000 on an Avaya Breeze® platform Profile 4 virtual machine.
Cluster capacity for a CC environment:
  • Up to 1000 UC or 1000 CC endpoints, or a total of 1000 UC + CC endpoints per Device Adapter node running on an Avaya Breeze® platform Profile 2 virtual machine.
  • Up to 5000 UC or 5000 CC endpoints, or a total of 5000 UC + CC endpoints per Device Adapter node running on an Avaya Breeze® platform Profile 4 virtual machine.
For more information, see Avaya Breeze platform cluster considerations.

How many Device Adapter nodes are administered by a single System Manager pair?

In a solution managed by a single System Manager pair, the maximum number of Device Adapter nodes supported in an Avaya Breeze® platform cluster is 50.
This number is the same regardless of whether the Device Adapter nodes are on Avaya Breeze® platform profile 2 or 4. To the System Manager, it is the existence of the node and not its profile that has the impact.

How many Device Adapter clusters are administered by a single System Manager pair?

If each cluster has exactly one Device Adapter node, then there can be no more than 50 clusters because the maximum number of nodes supported is 50.
Cluster capacity is increased by adding Device Adapter nodes to the cluster. Adding nodes to a cluster also creates a high-availability environment where the failure of one node is compensated by the other cluster participants. The maximum number of nodes in a cluster is currently limited to 6 (5+1 for High Availability).
The total number of clusters administered by a single System Manager pair varies based on how many clusters are single node or High Availability (1+1, 2+1, 3+1, 4+1, or 5+1) clusters. These cluster sizes can be mixed, as long as the sum does not exceed a total of 50 virtual machine nodes.

Is an endpoint firmware upgrade required to use Device Adapter?

UNIStim and 39XX endpoints are upgraded to the latest supported firmware version the first time it connects to Device Adapter. Subsequent upgrades will also be handled by the snap-in.

Is a loadware upgrade required for Media Gateway Controllers to use Device Adapter?

Yes. There is a new Device Adapter-specific loadware that the MGC is upgraded to when the MGC connects to Device Adapter for the first time.

How does Device Adapter use the high availability features of Avaya Breeze® platform?

Device Adapter has two points of high availability support.
  • High availability between endpoints and Device Adapter is part of Device Adapter:
    • For UNIStim endpoints, UNIStim endpoints handle the fail over.
    • For analog and digital endpoints, the MGC of the analog and digital endpoints handles the fail over.
  • High availability between Device Adapter and the Avaya Aura® components, including Session Manager, is provided by Avaya Breeze® platform.
For more information, see High Availability and Geo-Redundancy.
Device Adapter Release 8.1.1 and earlier used the Sequential Registration feature to provide fail-over support between Device Adapter and Avaya Aura® for endpoints. You can use the Multi-Device Access feature configuration fields, which is part of the Session Manager user profile configuration, to configure Sequential Registration.
To configure Sequential Registration, you must set the maximum number of simultaneously registered devices to 1, and allow new registrations. Sequential Registration allows only one device to be registered at one time.
In Sequential Registration, Session Manager terminates an existing registration when a new device registration request is received. Sequential Registration is crucial for providing endpoint fail-over support and other useful operations.
Sequential Registration provides the following fail over and operational support:
  • An endpoint can re-register without waiting for the original SIP registration to fail. This fail-over mechanism minimizes the recovery time.
  • Sequential Registration for UNIStim endpoint registration is supported since Device Adapter Release 8.0.
  • Since Device Adapter Release 8.0.1, Sequential Registration also provides fail-over support for analog and digital endpoints that are on an MGC in an event of a network failure. However, the Sequential Registration feature itself is not supported for analog and digital endpoints.
For more information, see Sequential Registration.
Device Adapter 8.1.2 allows an improved recovery. Session Manager uses the device ID to identity an endpoint. In Release 8.1.2, irrespective of which Device Adapter node handles the endpoint, Device Adapter sends the same device ID to Session Manager during endpoint registration. In an event of the network failure when the endpoint fails over and tries to re-register, Session Manager processes the endpoint registration request as re-registration request through a different path because the device ID is the same. Session Manager does not wait for the original registration to fail to allow the re-registration. Hence, you can configure Sequential Registration to allow new registrations, although you may use the Sequential Registration configuration to block new registrations.
Regardless of the release, Device Adapter takes full advantage of the Avaya Breeze® platform clustering mechanism.

High Availability between Device Adapter and Avaya Aura®

The Avaya Breeze® platform clustering mechanism monitors the connection between Avaya Breeze® platform server and Session Manager. When an outage is detected, Avaya Breeze® platform server tries to fail over to another instance of the primary Session Manager. If the fail-over attempt at the primary Session Manager is not successful, Avaya Breeze® platform server tries to fail over to the alternate Session Manager. After the connection is established, Device Adapter initiates the re-registration request.

High Availability between Device Adapter and the endpoint by using the Avaya Breeze® platform load balancer and TPS capabilities

Installing Device Adapter on a cluster creates a Device Adapter cluster. The Device Adapter cluster is similar in function to a CS 1000 TPS Node. The Avaya Breeze® platform load balancing node is similar in function to the CS 1000 TPS Node Leader server and distributes the endpoint registrations over the nodes in the Device Adapter cluster. The Avaya Breeze® platform load balancing node binds to the Cluster IP. The Avaya Breeze® platform Cluster IP is analogous to the TPS Node IP.
If one of the Avaya Breeze® platform nodes fails or a network outage separates the endpoints from their current node, the endpoints that were registered on the failing node or on the failing LAN segment re-register through the load balancing node. The load balancing node distributes the endpoint registrations over the remaining nodes in the Device Adapter cluster. If there is an insufficient capacity – for example, the cluster was not set up as N+1 – the endpoints that are attempting to register fail to register. However, this behavior is also seen in CS 1000 when a number of TPS nodes fail and no alternate load balancing server was defined, resulting in the number of devices that require registration exceed the available capacity.
SIP registration by Device Adapter requires registering the endpoint to Session Manager. Normally, Session Manager allows one endpoint to register as a user identity.
When a network failure occurs:
  • Till Device Adapter Release 8.1.1, the original endpoint registration through Device Adapter to Session Manager may not have failed yet; therefore, a new registration request fails. Sequential Registration resolved this registration delay by allowing Session Manager to force the original registration to end and register the new device before the keep-alive signaling detects the failure.
  • In Device Adapter Release 8.1.2, the TPS registration uses the hardware identity (device ID) of the device to register. This device ID does not change if the device changes the TPS nodes in a cluster or TPS (Avaya Breeze® platform cluster) load balancers. Hence, the re-registration is allowed even if the prior registration has not ended. The re-registration request is processed as a request to extend the current registration. Hence, Sequential Registration becomes optional.
If the Avaya Breeze® platform load balancing node fails, another node takes over the load balancing duties. However, there might be some registrations in progress when the load balancer node failed. Sequential Registration processes these incomplete registrations and works in parallel with the load balancer fail-over. Any incomplete registrations that were in progress when the load balancing node failed successfully reattempt the registration for the endpoint by using Sequential Registration.
However, the following are the limitations:
  • In an Avaya Breeze® platform cluster, only the dedicated active and standby servers can take over the Cluster IP, even if the cluster consists of more than two servers. This is different from CS 1000 where any TPS on a server in CS 1000 can act as the primary TPS and take over the Node IP.
    If both the Avaya Breeze® platform active and standby servers are down, no phones or media gateways can register.
  • If a Device Adapter stops working, by getting uninstalled, or failing on the currently active server, no phones or media gateways can register, even if Avaya Breeze® platform works properly.

How is general troubleshooting and traffic monitoring handled?

The monitoring and troubleshooting tools available for SIP endpoints in Session Manager and Communication Manager are also available for Device Adapter endpoints. Device Adapter also provides troubleshooting tools equivalent to those provided by the CS 1000 TPS.

Does Device Adapter support handing off a call from the desk phone to the Avaya Workplace Client on a mobile device?

The desk phone does not have features to perform such a hand off. The hand off is performed by Avaya Workplace Client.

When is user data first imported into the PPM?

User data is first imported into the PPM when one of the following events occurs:
  • When the Personal Directory data is imported from CS 1000 to Device Adapter.
  • When the user registers their phone for the first time.
  • When the administrator adds the user manually using the Personal Directory command line interface.

How is Corporate Directory support implemented?

LDAP Corporate Directory support is implemented using Avaya Aura® Device Services.

What IPE cards are supported after migration from CS 1000?

Refer to the section Supported TDM hardware for information on supported IPE cards.

Are faxes and modems supported?

Yes, modems are supported in the Device Adapter but fax is supported only in pass through mode. DSP MPT feature is used to increase fax reliability using the G.711 codec.

Are attendant consoles supported?

No. Attendant consoles are not supported currently.

How are Device Adapter endpoints associated with Communication Manager stations?

Device Adapter endpoints are associated with Communication Manager stations in the following ways:
  • A Communication Manager station representing a Device Adapter endpoint associates the station with a unique System ID and TN combination.
    A Communication Manager station administered with the Station Type of CS1k-xxxx has System ID and TN attributes. These two attributes form a unique combination at the solution level for every station representing a Device Adapter endpoint.
  • A Device Adapter cluster is administered with a System ID.
    When a Device Adapter endpoint registers with a Device Adapter it submits a TN attribute value. Device Adapter locates the Communication Manager station that contains the same unique combination of the cluster System ID and the TN value submitted by the endpoint.
Note:
Migrating multiple CS 1000 systems into a single Avaya Breeze® platform cluster may cause TN conflicts. Hence, System ID is used to facilitate the migration and reduce TN conflicts. Till Device Adapter 8.1.1, using the System ID lessened the probability of TN conflicts, but required you to deploy a separate Device Adapter cluster for each migrated CS 1000 system. Provision of the latest release, which is used with Device Adapter 8.1.2, allows you to modify TNs and resolve TN conflicts during the migration. Therefore, you can migrate endpoints from multiple CS 1000 systems into a single Avaya Breeze® platform cluster.

How are Device Adapter endpoints associated with Session Managers?

Device Adapter endpoints are associated with Primary, Secondary, and Branch Session Managers in the following way:
  • A user’s Communication Profile, administered in System Manager User Management, associates a Communication Manager station with a Primary, Secondary, and Branch Session Manager.
  • A Communication Manager station is associated with a unique System ID and TN combination.
  • A Device Adapter cluster is administered with a System ID.
    When a Device Adapter endpoint registers with a Device Adapter it submits a TN attribute value. Device Adapter locates the Communication Manager station that contains the same unique combination of the cluster System ID and the TN value submitted by the endpoint. Device Adapter then uses the Session Manager information to determine the Primary, Secondary, and Branch Session Manager for the endpoint.
    Note:
    Device Adapter does not support different Primary, Secondary, and Branch Session Manager for different endpoints in the same Device Adapter cluster.

How are Device Adapter endpoints associated with a Node?

The Avaya Device Adapter Snap-in has a configuration attribute called Node ID. The Node ID is an integer between 0 and 9999. One Device Adapter cluster is configured with a single Node ID. This is functionally similar to the Node ID used in CS 1000 TPS clusters, where one Node ID is assigned to each TPS cluster.
A UNIStim endpoint submits a Node ID and TN when it registers with a Device Adapter cluster. The registration is rejected if the Node ID submitted by the endpoint does not match the Node ID of the cluster.
Note:
The two least significant digits of the Node ID are ignored during the matching operation. For example, Node ID 300 and 310 are considered a match.
Consider the following if a CS 1000 system with multiple TPS clusters that have different Node IDs is being migrated using a single Device Adapter cluster:
  • The Device Adapter cluster must have sufficient capacity to accept all endpoints from the multiple TPS clusters.
  • All endpoints must be configured to use the Node ID of the Device Adapter cluster. This may mean changing the configuration of some endpoints while leaving others unchanged after the migration. This can be done using the same configuration file the endpoints will use to get the new S1 and S2 values.

How does ProVision/NMT interact with the CS 1000 and Avaya Aura® systems?

ProVision/NMT can only retrieve information from the CS 1000 solution. It can retrieve and send information to Avaya Aura® applications such as System Manager and Communication Manager.