Use of the mnemonic MGC implies use of MGXPEC. Although the form factors are different, the handling is the same.

Registration of the MGC with Device Adapter is invisible to the end user. Registration with Session Manager is also invisible.

However, if the MGC fails to register or if a specific endpoint fails SIP registration, it is visible to the user.

Normally, the MGC registers with the server S1. If the registration fails, it tries to register to server S2. This continues until registration succeeds. However, until the registration succeeds, the endpoints are unable to do any call processing or service operations, unless those operations are totally within the station firmware.

The station is physically attached to the MGC and does not need to register with the MGC. Subsequently, Device Adapter attempts SIP registration on behalf of all possible Terminal Numbers (TN) on the MGC. The MGC does not know what has been provisioned, and therefore, Device Adapter cannot know. Device Adapter sends a request for the information.

If the SIP registration succeeds, then the endpoint at that TN exists in the programming. The details sent by PPM are transmitted to the station as applicable. For example, 39xx endpoints may get display information, but all stations that are time and date compatible will receive the time of day. Note that analog and digital 200X endpoints do not have button labels generated by programming. The analog stations do not have feature buttons and the digital 200X stations have paper labels.

If SIP registration for a TN fails, the most probable reason is that no station has been defined for that TN. If the station exists and System Manager has a station defined for that TN and the registration fails, the logs can indicate the reason for the failure. This can include having an invalid station type versus endpoint type. A digital endpoint cannot be programmed as an analog endpoint and vice versa. Further, a 39XX cannot be programmed as a 2616 or 2008, and so forth.

In all cases, if the registration is expected to succeed but fails, it typically means either a network failure or a configuration problem. If all endpoints fail to register, the network is the most probable problem. But, whenever a subset of the stations successfully registers while others do not, verify the endpoint configuration on System Manager or Communication Manager.

The registration depends on values in EEPROM of the MGC. It is easier to migrate by putting the original call server IP address on Device Adapter than to change the programming on the MGC. After initialization, the MGC establishes its proprietary communication path (PBX-link) towards the primary Device Adapter Cluster IP written in EEPROM (mgcsetup). The primary Device Adapter Cluster IP should be the former Call Server IP.

IPSec is used to secure the traffic.

MGC supports triple registration, that is, with a primary server, a secondary server, and usually a local back-up tertiary server. MGC always tries to register first to the primary. If that fails, it registers to the secondary (alternate 1) or tertiary (alternate 2). Typically, if the MGC is registered to an alternate and the primary recovers or the link recovers, MGC re-registers to the primary. For Device Adapter, the server is the Device Adapter cluster and not a specific server.

After the PBX-link is established, Device Adapter performs load balancing to spread the endpoints as evenly as possible across Device Adapters in the cluster. If the Device Adapter load balancer decides that the MGC should be registered to another server, the MGC closes the PBX link connection and opens a new one with the Avaya Breeze® platform server IP provided to it.

MGC sends its loadware lineup to Device Adapter. Device Adapter may trigger a loadware upgrade at the MGC, to ensure that all devices are running current versions.

MGC then triggers configuration data upload. Device Adapter sends configuration files over SFTP and sends various parameters by using the PBX Link messages.

Later, if an administrator changes the configuration; for example, Attributes, Device Adapter sends the updated files to the registered MGCs and informs the MGCs about the update.

Unlike the UNIStim endpoints, MGC registers all its VGW (Voice Gateway DSP) channels with Device Adapter. As opposed to CS 1000, Device Adapter doesn't require VGWs to be pre-configured.

After this, the Status and Signaling Device (SSD) module is initialized. This permits signaling between Device Adapter and the physical endpoints to be complete. By using the SSD signaling, the CardLAN module starts detecting digital line cards (DLC) and analog line cards (ALC).

Device Adapter adopts the CS 1000 call server CardLan functionality:

Device Adapter provides a way to enable or disable individual cards and units through Device Adapter Element Manager. The enabled status is stored on the MGC. Hence, it survives re-registration to another cluster.

If any card type other than ALC or DLC is detected, it will be ignored and an alarm is generated.