Approved
|
All of the display messages specified in this requirement will be displayed with the priority specified for Generic Startup screens by 96x1COPS.7.2.200 in [7.1-4], unless otherwise specified.
All IP addresses that were obtained via DHCP or DHCPv6 will be released before any reset.
|
Note:
|
System-specific requirements should also specify whether the telephone should unregister before performing a reset.
|
Approved
|
The following will be displayed, left-justified on the top line of the display, for at least one second before a reset is initiated:
|
|
|
Restarting...
|
|
|
During a reset, the link on the Ethernet line interface and on the secondary Ethernet interface will not be dropped unless explicitly specified to do so.
|
Rationale:
|
This has become a competitive issue because Windows PCs display a notification to the user when a LAN connection is lost, and Cisco phones do not drop the link during a reset.
|
Approved
|
Operation will proceed as follows after power-up.
The Ethernet line interface will be activated as soon as possible.
The secondary Ethernet interface, if there is one, will be activated
|
Approved
for releases prior to R6.0.4, for R6.1.x and 6.3+
|
as soon as possible
|
Approved
for R6.0.4+ except R6.1.x
|
shortly after the activation of the line interface
|
Approved for 6.3.1+
|
Ethernet activity LEDs, if available, will be enabled.
|
Approved
|
if the value of the persistent parameter PHY2STAT is greater than “0” (see 96x1H-IPI.5.1.100).
|
Approved
for R6.0.4+ except R6.1.x and 6.3+
|
If the value of PHY2STAT is “1” (auto-negotiate), and if the line interface has been successfully established, the auto-negotiation procedure on the secondary interface will only indicate support for speeds that are less than or equal to the operating speed of the line interface.
|
Approved
|
If the value of PHY2STAT is “0”, the secondary Ethernet interface may be active for a short interval (up to several seconds) after a power-up, but it will be deactivated by the time the procedures specified in subsequent flowcharts begin.
|
Rationale:
|
Customers want the secondary Ethernet interface be activated as soon as possible after a power-up. It is acceptable for the secondary Ethernet interface to be activated by default, and it may remain active until the software can check whether the value of PHY2STAT is “0” (off). Even if a customer wants the secondary Ethernet interface to be disabled, a user could always just unplug the phone and plug the other device directly into the network.
|
Rationale:
for R6.0.4+ except R6.1.x and 6.3+
|
Delaying the activation of the secondary Ethernet interface until shortly after the activation of the line interface and then restricting the auto-negotiation procedure on the secondary Ethernet interface to only indicate support for speeds that are less than or equal to the operating speed of the line interface are intended to improve performance by eliminating speed mismatches that could require large amounts of flow control, however, it is recognized that there are still conditions under which such speed mismatches can occur.
|
Approved__The_display_contrast_will_be_set_based_on_the_value_of_the_persistent_parameter_NVCONTRAST_(see_96x1H-IPI.2.1.500'>Approved__The_internal_clock/calendar_(see_96x1COPS.5.1.100'>Approved for 6.3+
|
Flow control will be activated on the PC port only.
|
Rationale:
|
Flow control is activated on PC port only to support cases where PC speed is 1Gbps while network port speed is 10MBps/100Mbps.
|
Approved
|
Operation will continue as follows after power-up or after a reset.
The boot programs will check the Kernel/Root File System that is marked as the one to be activated to ensure that it has not become corrupted, and if it has not, it will transfer control to a process in that file system. If that file system is corrupted, the boot program will check the other Kernel/Root File System. If that file system is not corrupted, it will be marked as the one to be activated, the value of RFSINUSE will be set to the name of the Signed Kernel/Root Software Package that was used to install that file system, and control will be transferred to it. If both Kernel/Root File Systems are corrupted, processing will halt.
The Beacon LED (see 9xxxHW.2.2.600 in [7.1-2]) will be illuminated for several seconds.
|
Approved
for R6.3+
|
During startup, status messages are output on the serial interface that is used for factory test, one of which is "#console# […]", where dots are output sequentially between the brackets while the telephone waits approximately 5 seconds for input. If any character other than "c", "m" or " " (space) is entered during this interval, it will be ignored and startup will continue as specified below. If an "m" is entered, a list of board types will be output, along with the character to be entered to select each type. If one of these characters is entered, or if a "c" or a " " (space) character was initially entered, and if a printed wiring board serial number has been programmed into the telephone (see 9xxxHW.2.6.100 in [7.1-2]), the telephone will output "Enter password, please" as a prompt on that interface, and it will compare the next 6 input characters with the last 6 characters of the printed wiring board serial number. If they match, or if a prompt was not displayed, operation will proceed as follows, based on the first character that was entered:
"c": a command-line interface to the operating system will be supported on the serial interface, independent of the value of NVDEBUG (see 96x1H-IPI.2.1.500);
"m": settings appropriate to the selected board type will be used, and startup will continue;
" " (space): the serial software download procedure will be invoked.
If they do not match, or if 6 characters are not entered within the 30 seconds, startup will continue as specified below.
|
Note:
|
Factory test procedures are accessed via the button module interface on telephones that have one. On telephones that do not have one, a serial interface can be accessed via “bed of nails” probes inserted through holes in the telephone housing.
|
Approved
|
The internal clock/calendar (see 96x1COPS.5.1.100 in [7.1-4]) will be set to 0:00:00 Saturday, January 1, 2000 and started as soon as possible.
|
Rationale:
|
The internal clock is set and started as soon as possible (even if the actual time is not yet known) so that relative timestamps will be available for syslog messages (see 96x1H-IPI.5.1.1300).
|
Approved
|
The display may be blank for up to 5 seconds while the hardware is being initialized, but this interval should be kept as short as possible.
|
Approved
|
The display contrast will be set based on the value of the persistent parameter NVCONTRAST (see 96x1H-IPI.2.1.500), where an NVCONTRAST value of “8” is equivalent to the factory-set nominal display contrast setting (see 9xxxHW.2.6.100 in [7.1-2]).
|
Note:
|
The mapping between other values of NVCONTRAST and the units used for the factory-set nominal display contrast setting is implementation-specific, but should be chosen so as to cover a useful range of contrast settings.
|
Approved
|
The telephone’s backlight will be set to a level based on the value of NVBRIGHTNESS (see 96x1H-IPI.2.1.500), where an NVBRIGHTNESS value of “4” is equivalent to the factory-set default backlight level (see 9xxxHW.2.6.100 in [7.1-2]).
The backlight brightness of the first attached button module, if there is one, will be set to the value of the persistent parameter NVBM1BRIGHTNESS, the backlight brightness of a second attached button module will be set to the value of the persistent parameter NVBM2BRIGHTNESS, and the backlight brightness of a third attached button module will be set to the value of the persistent parameter NVBM3BRIGHTNESS.
The entire display will then be cleared to the lightest supported shade (e.g., white), and a bit-mapped image of the
|
Approved_only_for_releases_prior_to_R6.3'>Approved only for releases prior to R6.3
|
Avaya one-X name/logo will be displayed (in black and red on phones with color displays),
|
Approved
for R6.3+
|
Avaya name/logo will be displayed (in red on phones with color displays),
|
Approved
|
centered horizontally and vertically in the area that remains after reserving space for two text lines at the bottom of the display.
A horizontal black line will be displayed that is approximately 90% as long as the width of the display, centered horizontally, on the pixel row immediately above those reserved for the text lines;
A sequence of 8x8 pixel black squares will be displayed, one at a time with 4 pixels of separation, in a horizontal line centered vertically in the space reserved for the top line of text (for 20-pixel-high text lines with no intervening space, the blocks would use the 27th through the 34th pixels from the bottom of the display). The blocks will be displayed starting at the 43rd horizontal pixel on 320-pixel-wide displays, or at the 5th horizontal pixel on 160-pixel-wide displays. One additional square will be displayed every half second until there are 20 squares on 320-pixel-wide displays, or until there are 13 squares on 160-pixel-wide displays, at which time one square will be removed every half second, from left to right. When the last square is removed, the sequence will repeat until the first time that text is displayed on the top text line. The reserved text lines will be used for the display of all text specified in this requirement (and in 96x1H-IPI.5.1.600).
|
Approved
|
A schematic layout of the display is shown below:
|
Approved only for releases prior to R6.3
|
|
|
|
|
|
|
|
Approved
for R6.3+
|
|
|
|
Top reserved text line
Bottom reserved text line
|
|
|
|
|
|
|
Approved
|
After this point, the display will never go completely blank.
|
Rationale:
|
Customers have complained that blank screens give the impression that the phone has “gone dead” during initialization.
|
Approved
|
The Kernel/Root File System software will check whether a new Signed Application/Library Software Package has been saved in temporary non-volatile memory, and if one is found, the Application Software Package and/or the Library Software Package will be installed if either has a different file name than the currently installed version, replacing the existing corresponding files in the Application File System. The Hardware Version File included in the Signed Application/Library Software Package will be retained for future compatibility checking.
If an Application Software Package is installed that supports a different protocol than the Application Software Package that it replaced, all of the parameters except SIG will have their factory-default values, and any parameter values associated with the previous application will be deleted,
|
|
unless explicitly specified otherwise by software-specific requirements.
|
Note:
|
SIP software has such a requirement, see SparkCO.4.1.100 in COMPAS ID 121779.
|
Approved
|
The value of SIG will not be changed due to the installation of any software.
|
Rationale:
|
If the value of SIG was manually configured to change protocols (i.e., set to a value of "1" or "2"), if it was then set back to its default ("0") after software that supports the new protocol is installed, a value of SIG in the DHCP site-specific option or in a configuration file could then cause the telephone to download software that supports the same protocol that it had previously supported.
|
Approved
|
If a new Signed Application/Library Software Package is not found, the integrity of the application files will be checked, and if they are corrupted, files from the Backup Package will be installed, replacing the corrupted files in the Application File System.
Any time an Application Software Package and/or a Library Software Package is installed, the value of the persistent parameter APPINUSE will be set to the file name of the Signed Application/Library Software Package from which they were installed. If the application files are not corrupted, or after the Backup Package has been installed, the application installed in the Application File System will be executed.
The value of APPINUSE will be displayed on the bottom text line while the application is loaded into volatile memory, and it will remain there until overwritten by a subsequent display.
If the application stops running within the first minute or so (to be determined by development), the Backup Package will be installed and executed.
|
|
If the application stops running after that, the telephone will reset.
After it has been determined that the application runs compatibly with the Kernel/RFS,
if the newly-installed application supports the same protocol as the application that it replaced, and if the Backup Flag is set in the Hardware Version File that is stored in temporary non-volatile memory,
or if the newly-installed application supports a different protocol than the application that it replaced,
the Signed Application/Library Software Package that is stored in temporary non-volatile memory will be made the Backup Package and the value of BACKUPAPP will be set to the original name of that package. Whether it is installed as the Backup Package or not, the Signed Application/Library Software Package that is stored in temporary non-volatile memory will then be deleted.
If the value of the persistent parameter NVLANGFILE (see 96x1H-IPI.2.1.500) is not null, the text strings in the file named by that value will be used (see 96x1H-IPI.2.2.600) whenever text generated by telephone software (“local” text) is to be displayed. If the file does not contain a replacement text string for one of the built-in English text strings, the built-in English string will be displayed instead. The preferred character input method indicated in the language file will also be used if supported by the software; otherwise ASCII character input will be used. If the value of the persistent parameter NVLANGFILE is null, the built-in English text strings and ASCII character input will be used.
|
Rationale:
|
It should not be necessary to require a check as to whether the file exists, because it should have been there before the phone powered down or reset. It should also not be necessary to check whether the language name in the file matches NVLANGNAME.
|
Approved
|
An incomplete, improperly formatted, or otherwise unusable file stored as a language file will never cause the telephone to stop operating, to reset, or to display garbage. At worst, the telephone should continue operating using the built-in English text strings and the ASCII character input method.
|
|
The integrity of the software-readable parameters (see 9xxxHW.2.6.100 in [7.1-2]) will be verified. If the parameters have been corrupted, the following will be displayed and processing will halt.
|
|
|
EEPROM error,
repair required.
|
|
|
If the software-readable parameters are not corrupted, all parameters will be initialized, as specified in Section 2.1.
|
|
Directory: public -> downloadFile.jsp?file= -> resources -> sites -> AVAYA -> content -> live -> SOLUTIONSpublic -> The german unification, 1815-1870public -> Preparation of Papers for ieee transactions on medical imagingpublic -> Harmonised compatibility and sharing conditions for video pmse in the 7 9 ghz frequency band, taking into account radar usepublic -> Adjih, C., Georgiadis, L., Jacquet, P., & Szpankowski, W. (2006). Multicast tree structure and the power lawpublic -> Duarte, G. Pujolle: fits: a flexible Virtual Network Testbed Architecturepublic -> Swiss Federal Institute of Technology (eth) Zurich Computer Engineering and Networks Laboratorypublic -> Tr-41. 4-03-05-024 Telecommunicationspublic -> Chris Young sets 2016 “I’m Comin’ Over” Tour headlining datesSOLUTIONS -> CM: How to enable 'auto answer' feature
Share with your friends: |