H. 323 Software ip interface Requirements / Feature Specifications compas id 143543 Issue 4 June 02, 2014 John W. Soltes (retired)

Since the R6.0 and R6.1 projects have such a large overlap of development intervals, I thought that it would be useful to maintain the gray background to distinguish changes between 96x1 R6.0 and 96xx R3.1.1, so I am using this blue background to distinguish changes for R6.1.

• 
  96x1H-IPI.3.1.200: Specified that no text will be displayed on the Status Line on Loss of Ethernet interrupt screens.
  
• 
  96x1H-IPI.4.1.100: Specified that “Enter backup/restore credentials” will be displayed on the Status Line of HTTP authentication interrupt screens used for backup/restore.
  
• 
  96x1H-IPI.5.1.240: Specified that “802.1X Failed, try again” will be displayed on the Status Line of 802.1X Authentication interrupt screens, and that “802.1X” will be displayed on the Status Line of 802.1X Waiting interrupt screens.
  
• 
  96x1H-IPI.5.1.1400: Specified that “Enter authentication credentials” will be displayed on the Status Line of HTTP Authentication interrupt screens unless alternate text is specified by the application, and that “Authentication failed. Try again.” will be displayed on the Status Line of HTTP Authentication Failure interrupt screens unless alternate text is specified by the application.
  
• 
  Section 7.1: Added references to Christian Tenberg’s new UI Description R/FS documents for R6.1+.
  

To support the use of DNS as a way to control load balancing or use of redundant backup/restore servers, the DNS name of the server should be re-resolved if a connection cannot be establish to the IP address that was previously used.

• 
  96x1H-IPI.4.1.100: For R6.1+, specify that if the authority component of BRURI contains a DNS name, and if a TCP connection cannot be established to the IP address that was previously used to attempt to establish a connection with the server, the telephone will attempt to re-resolve the DNS name. If a new IP address is received, the telephone will attempt to establish a connection to that address. If the telephone receives the same IP address from the DNS server that was used previously, or if a TCP connection cannot be established to the new IP address, a failure indication will be returned to the initiating process.
  

To support the deletion of Agent Greeting files that are managed via the backup/restore mechanism, backup/restore must be enhanced to support the HTTP DELETE method.

• 
  96x1H-IPI.4.1.100: For R6.1+, specify that for deletion, the initiating process must only supply the file name, and the deletion of the file will be requested from the server via an HTTP DELETE message. A success indication will be returned to the initiating process if a 2xx HTTP status code is received, otherwise a failure indication will be returned.
  

• 
  96x1H-IPI.2.1.1150: For R6.1+, increase the maximum valid length for NVVPNPSWD and NVVPNUSER from 30 to 50 characters.
  

• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTCALLINFOSTAT, with valid values of "0" or "1" (the default). (PRD item AG-13)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTFWDBTNSTAT, with valid values of "0" or "1" (the default). (PRD item CC-AM-1)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTGREETINGSTAT, with valid values of "0" or "1" (the default). (PRD items AG-1-13, AI-6, CC-AM-1)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTLOGINFAC, with valid values of 1 to 4 ASCII dialable characters ("0" through "9" plus "*" and "#"), and a default value of "#94". (PRD items AG-1-13, AI-6-7, CC-AM-1)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTLOGOUTFAC, with valid values of 1 to 4 ASCII dialable characters ("0" through "9" plus "*" and "#"), and a default value of "#95". (PRD item AI-7)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTSPKRSTAT, with valid values of "0" or "1" (the default). (PRD item CC-AM-1)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTTIMESTAT, with valid values of "0" or "1" (the default). (PRD item CC-AM-2)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTTRANSLTO, with valid values of 1 to 6 UTF-8 characters, and a default value of "to". (PRD item AG-7)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTTRANSLCLBK, with valid values of 1 to 6 UTF-8 characters, and a default value of "callback". (PRD item AG-7)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTTRANSLPRI, with valid values of 1 to 8 UTF-8 characters, and a default value of "priority". (PRD item AG-7)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTTRANSLPK, with valid values of 1 to 6 UTF-8 characters, and a default value of "park". (PRD item AG-7)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter AGTTRANSLICOM, with valid values of 1 to 6 UTF-8 characters, and a default value of "ICOM". (PRD item AG-7)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter CALLCTRSTAT, with valid values of "0" (the default) or "1". (PRD items AG-1-13, AI-6, CC-AM-1)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter OPSTATCC, with valid values of "0" (the default) or "1".
  (PRD item AG-1,3,6,8,13, CC-AM-1)
  

• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter CLBACKUPTIME with valid values of "0" or "10" through "60", and a default value of "15". (GRIP 2183)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter EOEDITDIAL with valid values of "0" (the default) and "1". (GRIP 2184)
  
• 
  96x1H-IPI.2.1.1200: For R6.1+, add new parameter CAIDSEQU with valid values of "0" (the default) and "1". (GRIP 2493)
  

• 
  96x1H-IPI.2.1.1150: For R6.1+, add new parameter VUMCIPADD with valid values of 0 to 255 ASCII characters: zero or more IP addresses in dotted-decimal, colon-hex, or DNS name format, separated by commas without any intervening spaces, and a default value of null.
  

• 
  96x1H-IPI.3.1.300: Corrected the flowchart to display the VPN Settings Screen if the value of VPNPROC is 1.
  
• 
  96x1H-IPI.3.2.100: Added late changes from 96xx S3.1.1 COMPAS MR 73315: Specified that if the cursor is in the rightmost position on the display and another character is entered, the cursor remains in the same position and the input string is scrolled one character to the left. The prompt on the left side of the display line, if any, remains fully displayed, so if the input string scrolls to the left, the leftmost displayed character of the input string is removed from the display, but not from the input buffer. Also specified that if a backspace is done when the entire input string is not currently shown on the display, the cursor will remain in the rightmost position, the next character on the left side of the input string will be redisplayed, and the displayed portion of the input string will shift one position to the right.
  
• 
  96x1H-IPI.5.1.220: Fixed the VLAN separation flowchart to show that frames with a reserved multicast destination address are always forwarded to the telephone with an indication of the port on which the frame was received.
  
• 
  96x1H-IPI.5.1.1100: In MIB Group 2, moved endptNVBM1BRIGHTNESS, endptNVBM2BRIGHTNESS and endptNVBM3BRIGHTNESS up to maintain alphabetical order; in MIB Group 5, added a missing ‘t’ in the object name endptBM2HWVER, and moved endptBMODS down to maintain alphabetical order.
  
• 
  Removed all occurrences of the word “reprogrammable” from the document.
  

The following change was made in addition to the previous changes made in Issue 6.0 (Revision 1) based on this MR:

• 
  96x1H-IPI.3.1.100, flowcharts 3f/g and 4d: Add a test to skip waiting for LLDP if IPv6-only operation is enabled.
  

The TEAMBTNDISPLAY parameter was only used by the 9650 and should not have been carried forward to the 96x1 telephones.

• 
  96x1H-IPI.2.1.1200: Delete the parameter TEAMBTNDISPLAY.
  

• 
  96x1H-IPI.5.1.300: In the second Note, remove the second sentence that mentions the use of multiple IP addresses returned by the DNS resolver.
  
• 
  96x1H-IPI.5.1.750: Change to specify that if multiple records are returned by the DNS server, only one IP address will be returned to the requesting application, based on the value of the parameter IPPREF. If the value of IPPREF is "4", only the first IPv4 address will be returned. If the value of IPPREF is "6", only the first IPv6 address will be returned.
  

• 
  96x1H-IPI.5.1.600, flowchart 2: Add a test to ignore REUSETIME if IPv4-only mode is not enabled.
  
• 
  96x1H-IPI.5.1.600, flowchart 2b: Remove all text related to IPv6.
  
• 
  96x1H-IPI.5.1.604: Specify that if a DHCPNAK is received in the RENEWING, REBINDING or "extended" REBINDING state, or if the value of DHCPSTD is "1" and the phone does not receive either a DHCPACK or a DHCPNAK by the time the IPv4 address lease expires, in addition to ceasing use of the IPv4 address and setting IPADD to null, if dual-stack operation is enabled the phone will also cease use of its IPv6 address and IPADDV6 will be set to null.
  
• 
  96x1H-IPI.5.1.606: Remove the penultimate paragraph and the Rationale that specify support for DHCPSTD and the "extended" REBINDING state, and change the last two remaining paragraphs to specify that if the IPv6 address becomes unusable while dual-stack operation is enabled, that the phone will also cease use of its IPv4 address and IPADD will be set to null.
  

The intent of these changes is to ensure that only mutually compatible software packages are installed, and that compatibility checking is done before a software package is saved in non-volatile memory.

• 
  96x1H-IPI.2.2.100: Change the maximum length of a file name from 32 to 50 characters.
  
• 
  Section 3.1: Revise the text to reflect the changes described below.
  
• 
  96x1H-IPI.3.1.100: In the text prior to the flowcharts, change to specify that after a new Signed Application/Library Software Package is installed, the Hardware Version File included in the Signed Application/Library Software Package will be retained for future compatibility checking. Also specify that if the application stops running, the Backup Package will be installed and executed or, alternatively, that after it has been determined that the application runs compatibly with the Kernel/RFS, if a Signed Application/Library Software Package is stored in temporary non-volatile memory, and if the Backup Flag is set in the Hardware Version File that is stored with it, 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. Also specify that 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. The value of SIG will not be changed due to the installation of any software.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3c-1 and 3c-1a: Change to add compatibility checks between the new downloaded Signed Application/Library Software Package and the existing or new Kernel/Root File System Software Package, to set endptAPPstat based on the downloading and compatibility results, and to remove the requirement to save the Signed Application/Library Software Package as the Backup Package if the Backup Flag is set.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3c-2 and 3c-2a: Change to specify that if a Signed Kernel/RFS Software Package should be downloaded (according to the upgrade file) but cannot be, and if a Signed Application/Library Software Package was successfully downloaded, the downloaded Signed Application/Library Software Package will be deleted from temporary non-volatile memory. Also add compatibility checks between the new downloaded Signed Kernel/Root File System Software Package and the existing or new Application/Library Software Package, set endptRFSstat based on the downloading and compatibility results, and add a requirement to retain the Hardware Version File for future compatibility checking.
  
• 
  96x1H-IPI.3.1.110: Specify that endptAPPstat and endptRFSstat be set to the appropriate value for each of the invalid file conditions.
  
• 
  96x1H-IPI.3.1.115: Specify how compatibility strings in the Hardware Version File will be used to determine the compatibility of a Signed Software Package with "target" Application and Library or Kernel and Root File System Software Packages.
  
• 
  96x1H-IPI-5.1.1100: In MIB Group 3, replace endptAppStat with a new object named endptAPPstat with the following values:
  0 if the value of APPNAME is null;
  1 if the most recent attempt to download a new Application/Library software package was not successful;
  2 if the most recent attempt to download a new Application/Library software package was successful, but the file was too large;
  3 if the most recent attempt to download a new Application/Library software package was successful, but the file type was incorrect;
  4 if the most recent attempt to download a new Application/Library software package was successful, but files were missing, had the wrong file type, or had invalid signatures;
  5 if the most recent attempt to download a new Application/Library software package was successful, but was not valid for the telephone hardware;
  6 if the most recent attempt to download a new Application/Library software package was successful, but it was not compatible with the new Kernel/RFS software package;
  7 if the most recent attempt to download a new Application/Library software package was successful, but it was not compatible with the existing Kernel/RFS software package;
  8 if the most recent attempt to download a new Application/Library software package was successful, but the existing Kernel/RFS software package was not compatible with it;
  9 if the most recent attempt to download a new compatible Application/Library software package was successful.
  
• 
  96x1H-IPI-5.1.1100: In MIB Group 3, add an endptRFSstat object to support the following values:
  0 if the value of RFSNAME is null;
  1 if the most recent attempt to download a new Kernel/RFS software package was not successful;
  2 if the most recent attempt to download a new Kernel/RFS software package was successful, but the file was too large;
  3 if the most recent attempt to download a new Kernel/RFS software package was successful, but the file type was incorrect;
  4 if the most recent attempt to download a new Kernel/RFS software package was successful, but files were missing, had the wrong file type, or had invalid signatures;
  5 if the most recent attempt to download a new Kernel/RFS software package was successful, but was not valid for the telephone hardware;
  6 if the most recent attempt to download a new Kernel/RFS software package was successful, but it was not compatible with the new Application/Library software package;
  7 if the most recent attempt to download a new Kernel/RFS software package was successful, but it was not compatible with the existing Application/Library software package;
  8 if the most recent attempt to download a new Kernel/RFS software package was successful, but the existing Application/Library software package was not compatible with it;
  9 if the most recent attempt to download a new compatible Kernel/RFS software package was successful.
  
• 
  96x1H-IPI-5.1.1100: In MIB Group 3, change the existing objects endptRecentLog and endptResetLog to contain up to the last 500 syslog event messages instead of up to the last 75 syslog event messages, and add a new object, endptStartupLog, with a syntax of SEQUENCE DisplayString, that contains up to the first 500 syslog event messages with a numeric severity code that is less than the value of NVLOGLOCAL that were generated by the software after the last power-up or reset, in order, starting with the oldest, whether or not the messages were sent to a syslog server.
  

If an administrator sets PROCSTAT to 1 (access to local procedures disabled), VPNPROC to 0 or 1 (VPN procedure disabled or read-only) and NVVPNMODE to 1 (VPN mode enabled), if there was an error in the VPN configuration that prevents a VPN tunnel from being established, or if enabling VPN mode was not intended, it is necessary to use the factory test interface to manually reconfigure each phone. The following enhancements are intended to simplify this potential issue by allowing NVVPNMODE or PROCSTAT to be set to 0 via DHCP. Only the first change below is absolutely required, but if only that enhancement is made, VPN mode cannot be disabled via DHCP and it will have to be manually disabled on each phone. Implementing both changes would allow VPN mode to be disabled via DHCP.

• 
  96x1H-IPI.5.1.604: Specify that the requested site-specific option be processed (if it was received) as specified in 96x1H-IPI.5.1.600, unless the telephone is in the RENEWING, REBINDING or “extended” REBINDING state.
  
• 
  96x1H-IPI.2.1.1150: Move NVVPNMODE to 96x1H-IPI.2.1.1100 so that it can be set via a DHCP site-specific option as well as via a configuration file.
  

• 
  96x1H-IPI.5.1.606: Change to specify that after sending a Decline message for an address received via DHCPv6 for which an address conflict is detected, the telephone will restart sending Solicit messages
  

• 
  96x1H-IPI.5.1.220: Modify the flowchart to allow priority-tagged frames to be forwarded to an attached PC, but retain the preference for the tags to be removed, and add a Rationale that the initial Broadcom BCM111xx ICs used in the 96x1 telephones are not able to be configured to support other requirements and to remove priority tags from frames forwarded to the secondary Ethernet port.
  

• 
  96x1H-IPI.4.2.200: Change the flowchart to ignore a value of NVSGIP if it is 0.0.0.0 or 255.255.255.255.
  
• 
  96x1H-IPI.4.2.220: Change the parenthetical statement for the “Need gateway IP address” error message to “if the value of NVSGIP is null or 255.255.255.255, or if a response is not received using any other IP address”.
  

• 
  March 31, 2010: Updated flowchart 4b in 96x1H-IPI.3.1.100 to turn on tagging if IPV6STAT = 1.
  
• 
  96x1H-IPI.3.1.100 flowchart 1c and Appendix A: Changed “IPv4 address conflict” to “IPv4 Address conflict” and changed “IPv6 address conflict” to “IPv6 Address conflict” so that an existing translation of “Address conflict” (with a capital “A”) could be reused.
  
• 
  96x1H-IPI.5.1.604: The processing of name=value pairs was moved to 96x1H-IPI.5.1.600, because it also applies to DHCPv6
  
• 
  96x1H-IPI.5.1.1300: Added a Note to clarify the IP address to be used in the syslog HOSTNAME field.
  

As currently specified, if the value of SIG is changed in the settings file such that the phone should download SIP software, that change will not take effect until after the next time the phone is reset. Also, if DHCP sets SIG to 2 but the settings file subsequently sets SIG to 0 or 1, the phone will still download SIP software. The following changes are proposed so that the phone will redownload the upgrade file before downloading software files:

• 
  96x1H-IPI.3.1.100, flowcharts 3a-1b and 3b-1b: After the step in which the configuration files are interpreted, insert decision steps such that if SIG was changed from a value of “0” or “1” to a value of “2” by a configuration file, or if SIG was changed from a value of “2” to a value of “0” or “1” by a configuration file, the upgrade file will be redownloaded.
  

Development has proposed to defer LLDP support for IPv6 to a subsequent release, since it is not required for JITC testing. This would require the following changes:

• 
  96x1H-IPI.5.1.260: Specify that LLDP will only be supported in IPv4-only mode, remove the additions (highlighted in gray) to the Chassis ID and Management Address TLVs, remove the new text (highlighted in gray) before the Avaya/Extreme TLVs, and remove the IPv6-specific additions (highlighted in gray) to the VLAN Name and Network Policy TLV flowcharts.
  

The NVCHADDR value and local procedure were first implemented in 2004 on the 46xx telephones, as part of a Rapid Response for Union Pacific Railroad. However, it probably should have used DHCP option 61 instead of the chaddr field, and it has required maintaining custom modifications to the DHCP client ever since, including regression testing. It was never supported by the Spark software. Note that if this is approved, the CHADDR local procedure must be removed from CID 143548 as well.

• 
  96x1H-IPI.2.1.500: Delete the NVCHADDR parameter.
  
• 
  96x1H-IPI.5.1.604: Delete the requirement for populating the chaddr field from a non-zero value of NVCHADDR.
  
• 
  96x1H-IPI.5.1.1100: In MIB Group 2, delete endptNVCHADDR.
  

The Linux implementation of 802.1X is based on the 2004 version of the standard, so the requirement should be aligned.

• 
  96x1H-IPI.5.1.240:
  
  • 
    change all references to the 802.1X standard from [7.2-7a] (2001) to [7.2-7b] (2004),
    
  • 
    specify that all EAPOL frames generated by the telephone will use the value 0000 0001 in the Protocol Version field, and add a Rationale that even though an 802.1X implementation conforming to the 2004 version of the standard is supposed to use a Protocol Version of 0000 0002, Broadcom has indicated that this resulted in interworking issues with existing implementations, so their implementation uses a Protocol Version of 0000 0001, and
    
  • 
    specify that “802.1X failure” be displayed during startup if the Supplicant times out waiting for an EAPOL frame from the Authenticator, and add a Note that this will happen if the Supplicant is enabled in the telephone but if 802.1X is not enabled on the port.
    
• 
  Section 7.2: Remove the asterisk from [7.2-7a] and add an asterisk to [7.2-7b].
  

The following enhancements are being implemented in 96xx S3.1.1 relative to S3.1:

• 
  96x1H-IPI.2.1.1150: Change the maximum number of valid characters in a NVVPNUSER or NVVPNPSWD value from 16 to 30.
  
• 
  96x1H-IPI.3.2.100: Add the "@" sign to the list of special characters supported on Dialpad Button 1, immediately following the "1" character, and move the period character up to follow the "@" character.
  

As currently specified, if the parameter SIG is set via DHCP or the settings file, if SIG is changed via the local procedure, after the phone resets, the SIG value will again be set via DHCP or the settings file and the value that was manually set will be ignored. This should be corrected as follows:

• 
  96x1H-IPI.3.1.100, flowcharts 3a-1b and 3b-1b: Add a requirement that SIG not be set from a value in a configuration file if it was previously set via the SIG Craft Local procedure. Also add a Note that indications as to whether the values of non-volatile parameters (L2Q, L2QVLAN and SIG) were set via a specific mechanism must also be maintained in non-volatile memory, and should be reset to “no” when the parameter is initialized to its default value by the CLEAR or the Reset Values procedures.
  

• 
  96x1H-IPI.5.1.600: Add a requirement that SIG not be set from a value received in a name=value pair if it was previously set via the SIG Craft Local procedure. Also add a Note that indications as to whether the values of non-volatile parameters (L2Q, L2QVLAN and SIG) were set via a specific mechanism must also be maintained in non-volatile memory, and should be reset to “no” when the parameter is initialized to its default value by the CLEAR or the Reset Values procedures.
  

As currently specified, DHCP (v4) will remain enabled even if DHCPSTAT is set to disable it. This should be corrected as follows:

• 
  96x1H-IPI.3.1.100, flowchart 1bcd: After the “Set DoDHCPv6 = 1” step, add a “Is DHCPSTAT = 2” test. If Yes, set DoDHCPv4 = 0; if No, go to DHCP-1.
  

If the 802.1X Supplicant is enabled, the VLANTEST timer can expire or, if an IP address is manually programmed, duplicate address checking will not detect a conflict, if either is started before authentication succeeds. This should be corrected as follows:

• 
  96x1H-IPI.3.1.100, flowchart 1: In the step that says “Start 802.1X Supplicant per 96x1H-IPI.5.1.240” add the following, “and do not proceed unless authentication succeeds”.
  

In order to minimize the possibility of corruption of the boot files, they should only be overwritten when a different version is available.

• 
  96x1H-IPI.2.1.500: Add BOOT1INUSE and BOOT2INUSE persistent parameters.
  
• 
  96x1H-IPI.3.1.100, flowchart 3c-2: In the step that specifies the extraction and installation of the Root File System Software Package, after “and/or in the boot program area” add the following “(a boot file will only be replaced if the new file name is different than the existing file name; see 96x1PKG.2.3.300 in [7.1-10])”, and in the step that sets RFSINUSE = RFSNAME, add “if the boot files were replaced set BOOT1INUSE and BOOT2INUSE to the new file names,”.
  
• 
  96x1H-IPI.5.1.1100: Add endptBOOT1INUSE and endptBOOT2INUSE to Group 1 of the SNMP MIB.
  

• 
  Replace “big app” and “little app” with the Application File System and the Kernel/Root File System.
  
  • 
    2.1.100: Deleted BOOTNAME.
    
  • 
    2.1.500: Added APPINUSE, BACKUPAPP, and RFSINUSE.
    
  • 
    2.1.1200: Added RFSNAME.
    
  • 
    2.2.400: Deleted the requirement for the upgrade file to prevent downloading a backup code image (“little app”) over VPN, because a “little app” is no longer required, the new Backup Package will not run when it is updated, and it will support VPN when it does run.
    
  • 
    Section 3.1: Added a high-level overview of how the telephone is expected to operate during startup and software upgrades.
    
  • 
    3.1.100, including flowcharts 3c-1, 3c-2, and 3f/g: Replaced requirements for “big app”, “little app” and “boot burner” apps with requirements for processes in the Kernel/Root File System and the Application File System.
    
  • 
    3.1.100: Deleted the requirement that a bit-mapped image of the international NOT symbol (a circle with a diagonal chord through the center, in red on telephones with a color display) be displayed if both Kernel/Root File Systems are corrupted (the equivalent of both “big app” and “little app” being corrupted, because it is doubtful that the Linux boot program could do this. It is not clear that the 96xx software ever implemented this requirement either.
    
  • 
    3.1.110: Added a new requirement to validate downloaded software packages based on Hardware Version Identifiers contained in a signed Hardware Version File in the package.
    
  • 
    5.1.260: Changed BOOTNAME to RFSINUSE as the source of the Firmware Revision in the LLDP MED Inventory – Firmware Revision TLV, and changed APPNAME to APPINUSE as the source of the Software Revision in the LLDP MED Inventory – Software Revision TLV.
    
  • 
    5.1.1100: Deleted the statement that “the secondary (“little app”) software binary code image is not required to support SNMP”.
    
  • 
    5.1.1100, MIB Group 1: Deleted endptBOOTNAME, changed endptAPPINUSE to be based on APPINUSE, and added endptBACKUPAPP based on BACKUPAPP, endptRFSNAME based on RFSNAME, and endptRFSINUSE based on RFSINUSE.
    

• 
  3.1.100: Added a requirement that telephones with a secondary Ethernet interface not disrupt the link on the secondary Ethernet interface or on the line interface during a reset unless explicitly specified to do so.
  

• 
  Specify different upgrade files for H.323 and SIP, specify the use of SIG to select the upgrade file to be downloaded, and add SIG_IN_USE for use in conditionals based on the protocol that the phone is currently running.
  
  • 
    2.1.100: Deleted SIG.
    
  • 
    2.1.200: Added SIG_IN_USE with a value of “H323”.
    
  • 
    2.1.1100: Moved SIG here from 2.1.100, making it settable via DHCP or a configuration file, but not testable.
    
  • 
    3.1.100, flowcharts 3a-1 and 3b-1: Changed to download “96x1Supgrade.txt” if the value of SIG is “2”, otherwise (if the value of SIG is “0” or “1”), download “96x1Hupgrade.txt”.
    
  • 
    5.1.1100, Group 3, endptUpgradeStat: Changed the name of the upgrade file from “96xxupgrade.txt” to “96x1Hupgrade.txt”.
    

• 
  Move all requirements that apply to the naming, content and format of Software Distribution Packages and the files that they contain to a new R/FS that is intended to be used for 96x1 H.323 and SIP software.
  
  • 
    2.2.200: Changed this requirement to a requirement to support a Hardware Version File in every Signed Software Package, and moved it to 96x1PKG.2.3.400 in [7.1-10].
    
  • 
    2.2.300: Moved the requirement that application software include a copy of the Avaya Product Root CA certificate to 96x1PKG.2.3.300 in [7.1-10].
    
  • 
    2.2.400: Added a requirement to process configuration file content as UTF-8-encoded characters and moved this requirement to 96x1PKG.2.4.100 and 96x1PKG.2.4.200 in [7.1-10].
    
  • 
    2.2.500: Moved this requirement to 96x1PKG.2.7.100 in [7.1-10].
    
  • 
    2.2.600: Moved the requirements for Display Text Language File content and naming and for specific languages to be included in distribution packages to 96x1PKG.2.5.100 in [7.1-10].
    
  • 
    2.2.700: Moved the requirement for a copy of the Avaya Product Root Certificate Authority certificate to be included in every Software Distribution Package to 96x1PKG.2.1.300 in [7.1-10].
    
  • 
    2.2.800: Moved requirements for Voice Input Language File naming and for specific languages to be included in distribution packages to 96x1PKG.2.5.300 in [7.1-10].
    

• 
  Support BM12 button modules:
  
  • 
    2.1.500: Changed the brightness parameters to NVBM1BRIGHTNESS, NVBM2BRIGHTNESS, and NVBM3BRIGHTNESS.
    
  • 
    3.1.100: Changed the specification of the initialization of the button module backlight brightness settings to be based on NVBM1BRIGHTNESS, NVBM2BRIGHTNESS, and NVBM3BRIGHTNESS.
    
  • 
    5.1.1100: Changed the button module backlight brightness objects in Group 2 of the MIB to endptNVBM1BRIGHTNESS, endptNVBM2BRIGHTNESS, and endptNVBM3BRIGHTNESS,
    and changed the hardware and software version number objects in Group 5 of the MIB to endptBM1HWVER, endptBM1SWVER, endptBM2HWVER, endptBM2SWVER, endptBM3HWVER, endptBM3SWVER.
    

• 
  Update the MIB
  
  • 
    5.1.260: Changed the sysObjectIDs specified for the Management Address TLV to align with the new values specified in 5.1.1100.
    
  • 
    5.1.1100: Updated references to the latest version for each MIB group:
    
    • 
      Changed reference to RFC 4293 instead of RFC 2011 for IP
      
    • 
      Changed reference to RFC 4022 instead of RFC 2012 for TCP
      
    • 
      Changed reference to RFC 4113 instead of RFC 2013 for UDP
      
  • 
    5.1.1100: Changed the product-line MIB node number from 2 (96xxMIB) to 5 (96x1H-MIB).
    
  • 
    5.1.1100: Added sysObjectIDs for the 96x1 telephone models, based on the new MIB node number.
    

• 
  Add parameters to support new application capabilities
  
  • 
    2.1.1200: Added CALCSTAT with valid values of “0” and “1” and a default value of “1”.
    
  • 
    2.1.1200: Added CLDISPCONTENT with valid values of “0” and “1” and a default value of “1”.
    
  • 
    2.1.1200: Changed the minimum value of HOMEIDLETIME from “5” to “0”.
    
  • 
    2.1.1200: Added PHNSCRALL with valid values of “0” and “1” and a default value of “0”.
    
  • 
    2.1.1200: Added WMLHELPSTAT with valid values of “0” and “1” and a default value of “1”.
    

• 
  3.1.100 flowchart 4d: Changed to test STATIC before checking LLDP so that time will not be wasted waiting for LLDP when a received value would not be used anyway, and to check whether MCIPADD is null when NVVPNMODE is “1”, so that in VPN mode, a reset will also be done if MCIPADD is null, rather than initiating H.323 procedures.
  

• 
  Support IPv6
  
  • 
    2.1.50: Specify that for IPv6 address values, a value of “::” and a value of “” (null) will be treated as equivalent.
    
  • 
    2.1.600, 2.1.650, 2.1.800, 2.1.900, 2.1.1100, 2.1.1170: Specified parameters that can be set in a DHCPv6 Reply Vendor-Specific Information (VSI) option 242
    
  • 
    2.1.600: Added IPADDV6 and extended the valid values of TLSSRVR to include IPv6 addresses in colon-hex format.
    
  • 
    2.1.800: Extended the valid values of HTTPSRVR and MCIPADD to include IPv6 addresses in colon-hex format.
    
  • 
    2.1.900: Extended the valid values of DNSSRVR to include IPv6 addresses in colon-hex format.
    
  • 
    2.1.1100: Added NDREDV6 with valid values of “0” and “1” and a default value of “0” to control whether ICMPv6 Redirect messages will be processed.
    
  • 
    2.1.1100: Extended the valid values of SNMPADD to include IPv6 addresses in colon-hex format.
    
  • 
    2.1.1150: Added DHCPPREF with valid values of “4” and “6” and a default value of “6” to control whether new values received via DHCPv4 orDHCPv6 will be preferred when both are used.
    
  • 
    2.1.1150: Added DHCPSTAT with valid values of “1”, “2” and “3” and a default value of “1”, and IPV6STAT with valid values of “0” and “1” and a default value of “0”.
    
  • 
    2.1.1150: Added IPPREF with valid values of “4” and “6” and a default value of “6” to control whether an IPv4 or an IPv6 address returned by DNS would be tried first during dual-mode operation.
    
  • 
    2.1.1150: Extended the valid values of NVHTTPSRVR, NVMCIPADD, and NVTLSSRVR to include IPv6 addresses in colon-hex format.
    
  • 
    2.1.1150: Added PINGREPLYV6 with valid values of “0”, “1” and “2” and a default value of “1” to control whether ICMPv6 Echo Reply messages will be sent.
    
  • 
    2.1.1200: Added GRATNAV6 with valid values of “0” and “1” and a default value of “0” to control whether IPv6 unsolicited Neighbor Advertisement messages will be processed.
    
  • 
    2.1.1200: Extended the valid values of LOGSRVR, QTESTRESPONDER, and WMLPROXY to include IPv6 addresses in colon-hex format.
    
  • 
    2.1.1400: Added values DoDHCPv4 and DoDHCPv6 to control whether the DHCPv4 and/or DHCPv6 clients, respectively, should be enabled.
    
  • 
    2.1.1400: Extended the valid values of FEIPADD to include an IPv6 address in colon-hex format.
    
  • 
    2.1.1400: Added IPADDV6LL for the telephone’s IPv6 link-local address.
    
  • 
    3.1.100, flowchart 1: Deleted the check that, based on NETMASK, IPADD is on the same subnet as GIPADD (the check was moved to the ADDR procedure in 96x1LA.6.2.200H in [7.1-5]), deleted the “Subnet conflict” screen, and moved the IP address conflict (Duplicate Address Detection) test to flowchart 1c.
    
  • 
    3.1.100, flowchart 1c, Added steps to perform Duplicate Address Detection on a manually programmed IPv4 and IPv6 addresses, changed the “Address conflict” to an “IPv4 address conflict” screen, and added steps to determine which DHCP client(s) should be enabled.
    
  • 
    3.1.100, flowcharts 2, 4a, 4d, and 3.1.300: Changed each place where IPADD is released before a reset if it was obtained via DHCP to include releasing IPADDV6 if it was obtained via DHCPv6. Also deleted setting IPADD to null before the reset, because after a reset, IPADD will always be initialized from NVIPADD anyway.
    
  • 
    3.1.100, flowchart 2b: Added steps to initiate IPv6 Router Discovery.
    
  • 
    3.1.100, flowcharts 3a-1a and 3b-1a: Specified that if the value of either IPV6STAT or DHCPSTAT is changed as the result of processing a configuration file, any IP addresses obtained via DHCP or DHCPv6 will be released and a reset will be initiated.
    
  • 
    3.1.100, flowchart 4b: Added steps to turn on 802.1Q tagging with a VLAV ID of zero if only IPv6 is enabled and if the value of L2Q is “0” (auto), because it is assumed that network equipment that supports IPv6 will also support 802.1Q tagging.
    
  • 
    5.1.260: Specified that IPADDV6 will be used in the Chassis ID TLV and in the Management Address TLV if the phone is IPv6-only or if dual-stack and the value of IPPREF is “6”, that Avaya/Extreme Proprietary TLVs will not be transmitted if the included IPv4 address values would be null, and modified the flowcharts for the processing of the VLAN Name and Network Policy TLVs for DHCPv6 operation.
    
  • 
    5.1.300: Added a new requirement to specify when IPv4-only, IPv6-only, and IP dual-stack operation will be enabled.
    
  • 
    5.1.304: New identifier for the IPv4 requirement (previously was 5.1.300).
    
  • 
    5.1.306: Added a new requirement to specify support for IPv6 per U.S. Government (UCR 2008 Change 1 Draft) requirements. In addition, a new parameter, GRATNAV6, is added to enable or disable the processing of received unsolicited Neighbor Discovery messages.
    
  • 
    5.1.310: Specified that IPsec will be supported for IPv4 only.
    
  • 
    5.1.320: Specified that IKEv1 will be supported for IPv4 only.
    
  • 
    5.1.350: Specified that RSVP will be supported for IPv4 audio connections only.
    
  • 
    Added UDP port number 546 as the Destination port on which to receive DHCPv6 messages, and UDP port 547 as the Destination port to which DHCPv6 messages will be transmitted.
    
  • 
    5.1.450: Revised to specify the IPv6 Hop Limit field in addition to the IPv4 TTL field so that this requirement is also applicable to IPv6.
    
  • 
    5.1.600: Add a new requirement to specify the common operations and interactions between DHCP(v4) and DHCPv6.
    
  • 
    5.1.604: Created a new identifier for the DHCP(v4) requirement (it was previously 5.1.300).
    
  • 
    5.1.606: Add a new requirement to specify support for DHCPv6.
    
  • 
    5.1.750: Specified support of both A and AAAA records per Section 2.2 of RFC 4213, support of RFC 3596 for AAAA records, and the use of IPPREF to determine the order in which IP addresses will be returned to the requesting application.
    
  • 
    5.1.900: Specified that RTCP monitoring will only be supported if FEIPADD is an IPv4 address.
    
  • 
    5.1.920: Specified that CNA will be supported for IPv4 only.
    
  • 
    5.1.1100: Changed the object type for the following objects that can now contain IPv6 addresses in addition to IPv4 addresses from IPAddress to DisplayString: endptFEIPADD, , endptGKINUSE, endptHTTPUSED, endptRTCPMON, endptTLSUSED, endptWMLPROXY.
    
  • 
    5.1.1100: Added the following DisplayString objects: endptDHCPINUSEV6, endptDHCPPREF, endptDHCPSTAT, endptDHCPV6LEASEEXP, endptDHCPV6LIFEPREF, endptDHCPV6LIFEVALID, endptDHCPV6T1, endptDHCPV6T1REM, endptDHCPV6T2, endptDHCPV6T2REM, endptGIPINUSEV6, endptGRATNAV6, endptIPADDV6, endptIPADDV6LL, endptIPPREF, endptIPV6STAT, endptNDREDV6, endptPINGREPLYV6, and endptVSICONTENT in Group 1 of the MIB, and endptNVIPADDV6 in Group 2 of the MIB.
    
  • 
    5.1.1400: Specified support of IETF STD 66: RFC 3986 (URI Syntax), which obsoleted RFC 2396.
    
  • 
    5.1.1450: Specified that the HTTP server will be supported for IPv4 only.
    
  • 
    Section 7.3: Added references for IPv6 IETF RFCs.
    
  • 
    Section 7.8: Add reference for U.S. Government UCR document
    
  • 
    Appendix A: Added an “IPv4 address conflict” string and deleted the “Address conflict” and “Subnet conflict” strings.
    
  • 
    Summary of capabilities that will not be supported over IPv6: LLDP, IPsec, IKEv1, RSVP, CNA, VPN, RTCP monitoring, HTTP server (Push requests)
    

• 
  Removed support for NVCALLSRVR and NVFILESRVR. They were only supported in S3.1 to support upgrades from and downgrades to previous releases that supported them, but there are no such previous releases for the 96x1.
  
  • 
    2.1.500: Deleted NVCALLSRVR and NVFILESRVR.
    
  • 
    3.1.100, flowchart 1c: Deleted steps to set NVTLSSRVR and NVHTTPSRVR equal to NVFILESRVR.
    
  • 
    3.1.100, flowchart 4d: Deleted steps to set NVMCIPADD equal to NVCALLSRVR.
    
• 
  3.1.100: Deleted the requirement that link integrity be established on the Ethernet line interface within 5 seconds of receiving power (to avoid being power-cycled by Catalyst switches) because support of PoE now imposes even faster link establishment, and because support of old proprietary Catalyst power is no longer required.
  
• 
  3.1.100 flowchart 3a-1: Removed the restriction to only offer the TLS_RSA_WITH_NULL_SHA cipher suite to align with the H.323 and SIP implementations.
  
• 
  4.2.100: This requirement (96xx telephone support of VPN) was deleted because all 96x1 models will support VPN, and because a “little app” is no longer required, so there is no longer a need to make a distinction that “big app” will support VPN.
  
• 
  5.1.100: Deleted requirements for supporting a Gigabit Ethernet adapter.
  
• 
  5.1.1100: Deleted endptBTADHWVER, endptBTADSTAT, endptBTADSWVER, endptGIGEHWVER, endptGIGESTAT, and endptGIGESWVER from Group 5 of the MIB, since Bluetooth and GigE adapters will not be supported.
  
• 
  5.1.100 Deleted endptSBMSTAT from Group 5 of the MIB because it was redundant with endptBMODS since only button modules will be supported by the button module interface.
  
• 
  5.1.1500: Removed the TLS_DH_RSA_WITH_AES_128_CBC_SHA and TLS_DH_RSA_WITH_AES_256_CBC_SHA cipher suites, since they were not supported by the 96xx.
  

• 
  Section 1.1: Changed the document identifier to 96x1H-IPI.
  
• 
  Deleted all requirements for the 9610, including WMLSMALL.
  
• 
  Deleted all requirements that did not apply to S3.1.
  
• 
  Changed to reference requirements in new 96x1 R/FS documents.
  
• 
  Update references to the 96x1 Hardware R/FS in 2.1.100, 2.1.1400, 3.1.100, 5.1.100, 5.1.260, 5.1.310, 5.1.604.
  
• 
  Changed some occurrences of “0.0.0.0” to “null”.
  
• 
  Increased the font size of Notes and Rationales from 8 to 10 point.
  
• 
  2.1.800: Moved the specification of MCIPADD here from 96xxACP.2.1.100.
  
• 
  2.1.900: Moved the specification of REREGISTER and UNNAMEDSTAT here from 96xxACP.2.1.100.
  
• 
  3.1.100: Removed requirements for character-based displays, since all 96x1 phones will have bit-mapped displays.
  
• 
  3.1.110: Moved requirements for validating downloaded Signed Software Packages into a separate numbered requirement.
  
• 
  5.1.400, 5.1.500 and Section 5.2 (flowcharts): Added H.323 source and destination port numbers.
  
• 
  5.1.500: Moved the requirement to support Path MTU Discovery for IPv4 (RFC 1191) to 5.1.304.
  
• 
  5.1.1500: Removed the duplicate occurrence of “TLS_RSA_WITH_NULL_SHA” from the list of cipher suites.
  
• 
  Section 5.2: Removed the flowcharts since they were redundant to the requirements.
  
• 
  Section 7.1: Added references to other 96x1 documents, and added a reference to the revised Avaya RTCP Requirements (with RTP-MIB Additions).
  

• 
  2.1.650: Change the default value of TLSPORT to 443?
  
• 
  5.1.220: Find out whether the new Broadcom switch can re-mark frames differently based on whether or not the VLAN ID is zero, and either remove the non-preferred leg in the flowchart (and the Rationale), or just update the Rationale to document what the 96x1 phones support.
  
• 
  5.1.220: Can the Ethernet switch hardware support 2 VLANs for VLAN separation?
  It might be desirable to be able to support independent VLANs for IPv4 and IPv6.
  Some customer PCs also use multiple VLANs for data.
  
• 
  5.1.304: Does Linux support IGMPv3?
  
• 
  5.1.600: Remove some of the older MAC address OIDs? Which will be used by the 96x1?