Defining default CESIDs - Always define the default CESID for each 3300 ICP in the network. This will act as a last resort if no CESID is available for a particular DN when an emergency call is placed.
911 and CESID - For a 911 call to be compliant with FCC guidelines, the call must report a CESID to the PSAP. At a minimum, you must define a CESID for each DN in the CESID Assignment form. In order to ensure that CESIDs are updated when a device is moved and can be correctly reported to the PSAP, promptly investigate and address all CESID-related alarms. You may have to return a phone to its original location if the move was not authorized or update the CESID Assignment and/or L2 to CESID Mapping forms. See also CESID Maintenance. Alternatively, you can populate the L2 to CESID Mapping form in advance of a device move.
Defining the primary protocol - Carefully consider the difference between the two protocols (STP and CDP), and designate one as your primary protocol. Remember that the L2 STP Port Identifier may not correspond to the physical port number on the L2 switch (with VLANs, the L2 port number may be virtual). See Device Connectivity - Moved. You designate a primary protocol for Detecting IP Device Moves in the CESID Assignment form.
Switching between CDP and STP in the network - The system may detect a false device move if the primary protocol is changed while a device is connected to an L2 switch.
Enabling Layer 2 (L2) protocol - Ensure that all L2 switches in the network have the primary protocol enabled. If there is an L2 switch that does not have the protocol enabled, devices may move from one port to another on that switch and the system will be unable to detect the device move since no L2 data will be reported.
New installations - In a new 3300 ICP installation scenario where no database is being restored, it is recommended that you allow the system to auto-discover the L2 Port MAC and L2 Port, as devices are registered, rather than manually entering the information. Auto-discovery ensures that the values are correct (particularly for VLANs), while manual entry can be prone to error. Once the information has been auto-discovered, you can go into the CESID Assignment form or the L2 to CESID Mapping form and enter the CESID for each entry. You may also want to go to other network drops where a phone might be moved to and allow the device to register there as well so that the ports can be auto-discovered. Note that any network drops that do not have a Mitel IP device connected to them will remain undiscovered by the 3300 ICP. You can either wait for a CESID alarm to be generated when a device connects to an unknown L2 port, or you can proactively auto-discover L2 data by plugging devices into L2 ports.
Upgrades - When you restore a database that contains accurate and complete CESID assignments, the L2 to CESID mapping for known devices will be fully and automatically discovered upon device registration. For this to happen, the CESID Assignment data must be accurate prior to the backup and upgrade. For upgrades from Release 4.x to 5.x, ensure that no devices are moved during the upgrade; otherwise, the CESID Assignment form will contain inaccurate data. If devices are moved during the upgrade, you must verify the information in the L2 to CESID Mapping form and the CESID Assignment form.
Backup and restore - Device move detection, automatic CESID updating, and alarming do not function during a database backup or restore. This is because all database files needed to detect device moves and update CESIDs are locked during a backup and restore. For this reason, you should perform backups and restores during times when devices are least likely to be moved. To ensure that no devices are moved, it may be helpful to notify users of backups and restores and instruct them not to move devices, if possible, during these times.
Maintaining CESID Logs - The CESID Logs form will begin overwriting data, from the oldest to newest entries, when 5000 CESID logs have been posted. If you wish to have traceability of the logs, you should perform regular database backups, or print/export this information.
Replacing L2 switches
- If an L2 switch is replaced in the network (for example, a non-functional
switch is replaced with a new one), the 3300 ICP will recognize the event
as a device move once the sets re-register through the new L2 switch (since
the sets are reporting a new L2 connectivity point). Assuming
that no new L2 to CESID mappings were manually created for the new switch,
the system will clear the CESID values in the CESID Assignment form (only
for the devices registered to the new L2 switch) and raise a CESID alarm.
Therefore, when a switch is replaced (old with new), you must reprogram
the CESID assignments for the sets that were connected, to the replaced
switch. Also, you should delete the old L2 to CESID mappings for the replaced
switch, since they are no longer relevant. Alternately, you may wish to
set the DNs connected to the retiring L2 switch to Manual CESID updating
(as opposed to Automatic - see CESID Assignment), so that the CESIDs don't
get cleared.
Another replacement scenario is that two L2 switches are swapped in the
network. Again, the 3300 ICP and IP devices will register this swap as
device moves, even though it was the switches that were moved and not
the devices. In this case, the system will automatically update the CESID
Assignment for each "moved" device (assuming that CESID Assignment
was complete prior to the swap). The problem here is that the automatic
CESID updating will likely be inaccurate because the L2 swapping will
cause the L2 to CESID mapping to become incorrect. For this reason, it
is recommended that you delete the CESID assignments before the L2 switches
are swapped, update the L2 to CESID mapping, and then the correct CESID
assignments to be auto-discovered.
Retiring an L2 switch - When an L2 switch is retired, you should delete the relevant entries from the L2 to CESID mapping form, since these are no longer being used.
Physically moving a network drop - For automatic CESID updating, the system will not be able to detect when a network drop is physically moved from one location to another (assuming the L2 port connection point remains the same). You should be wary of any physical port location changes (for example, those done during a re-wiring project). It may happen that if a network drop is physically moved, it will move into a location serviced by a different CESID. It is the system administrator's responsibility to ensure that network drops aren't moved without permission, and to update CESIDs when they are.
Connecting IP devices to a hub - It is recommended that devices be connected directly to an L2 switch. Avoid connecting IP devices to a hub that is, in turn, connected to an L2 switch. Apart from Quality of Service reasons, IP devices connected directly to a hub will all report the same L2 Port MAC/Port, and the system will not be able to automatically update the CESID for any devices registering to that hub.
Swapping Ethernet cables on an L2 switch - It is recommended that you do not swap Ethernet cables on L2 switches (for example, when troubleshooting a malfunctioning port). The system will see this switch as a device move. The device will report a new L2 connectivity point, even though it was not physically moved. Depending on the configuration, this could result in an automatic CESID update (likely with the wrong CESID), a CESID alarm, or the deletion of the device's CESID. If you must swap Ethernet cables on an L2 switch, be aware of the effect this will have on device detection and CESID assignment.
Addressing CESID alarms and logs - If a device is moved, and the system is unable to assign a CESID to the device at its new location, the system will raise an alarm, and log the problem. The user should monitor the system alarms for such an event, and when it occurs, use the logs, the CESID Assignment form, the L2 to CESID Mapping, and/or the Device Connectivity forms to determine the nature of the problem. Once the problem is understood, you should update the CESID Assignment or L2 to CESID Mapping form. This will ensure that the device has the correct CESID and will clear the alarm once all CESIDs have been assigned (for DNs in Automatic CESID Handling mode.)
Resilient-environment considerations - When a CESID alarm or log indicates a CESID assignment problem has occurred due to a device move in a resilient environment, you must at the very least update the L2 to CESID Mapping form on the primary controller. You should also add/update the same entry on the secondary controller; otherwise, a CESID alarm will be raised again if the device fails to the secondary.
Resilient Clustered Hot Desking environment considerations - When you change a virtual CESID Assignment for a Registration DN in a Hot Desking environment, based on a device move detection or CESID-related alarm, the Mobile DN (Hot Desk) user must log out and log back in to the Hot Desk enabled set. This is because the cookie containing the CESID on the Hot Desk set is not updated automatically when the CESID field is changed on the 3300 ICP. Only after logging out/in again will the cookie be updated.
Resilient environment, mixed cluster - In a case where the primary is an Release 5.2 controller, and the secondary is a 4.x controller, automatic CESID updating/alarming and device move detection will not occur for a device that has been moved while it is in service on its secondary controller. When the device fails back to the Release 5.2 primary controller, the move will be detected and CESID assignment and alarms will be updated (assuming that the device has previously registered with that primary controller once before).
Set firmware considerations - Automatic CESID updating/alarming and device move detection will not work unless the sets have the appropriate firmware load. This may be done through a 'LOAD IP DEVICE 1 to 700' command, by powering down the sets, or by a loss of connectivity with the 3300 ICP for 10 minutes or more.
Teleworkers - Mitel IP devices that are running in Teleworker mode and are connected outside the corporate network through the Mitel Standard Linux (MSL) gateway will not be blocked from making 911 calls, however an incorrect CESID may be reported. See Emergency Services - CESID Conditions for more information.
CDE and automatic CESID updating - It is recommended that you do not use the CDE interface to open and work in the CESID Assignment form. If the CDE interface is open to the CESID Assignment form while the system is attempting to automatically update a CESID based on a device move, the automatic update will fail.
