APPENDIX D: Document Change History

• 
  Remove endptSSO as it was not implemented for 6.3.
  

Make the following change for R6.3+:

• 
  Add the following parameter to requirement 96x1H-IPI.2.1.1150: Persistent Parameter Name and (default value): LOCALZIPTONEATT ("35"), Valid Values: ASCII numeric digit, "0" to "95", Usage and references: 96x1Tel.3.2.3160 in CID 143549 (MR 82245)
  

Make the following change for R6.3+:

• 
  Add the following parameter to requirement 96x1H-IPI.2.1.1150: Persistent Parameter Name and (default value): LEDMODE ("0"), Valid Values: ASCII numeric digit, "0" or "1", Usage and references: 96x1Tel.3.2.2800, 96x1Tel.3.2.2650, 96x1Tel.3.2.2700, 96x1Tel.3.2.2800 in CID 143549 (MR 82181)
  

Make the following change for R6.3+:

• 
  96x1H-IPI.5.1.240: Change to specify that the password prompt will only be displayed if the EAP method in use requires a password.
  

• 
  96x1H-IPI.3.1.100: Based on input from development, the time that the telephone will wait for input after the #console# prompt is displayed during startup was increased from 2 seconds to 5 seconds, and the time that the telephone will wait for the password to be entered was increased from 10 seconds to 30 seconds.
  

Make the following changes for R6.3+:

• 
  96x1H-IPI.5.1.1150: Specify a new persistent parameter, PHY2_AUTOMDIX_ENABLED, with valid values of "0" and "1" (the default), to specify whether auto-MDIX is enabled on PHY2.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3a-1b and 3b-1b: Specify that if PHY2_AUTOMDIX_ENABLED is set to a new value by the settings file, PHY2 will be reconfigured as specified in 96x1H-IPI.5.1.100.
  
• 
  96x1H-IPI.5.1.100: Specify that Automatic MDI/MDI-X Configuration will be enabled on the secondary Ethernet interface if and only if the value of PHY2_AUTOMDIX_ENABLED is "1". Also add a Note that if Auto-MDIX is disabled on PHY2 while a link is active to a device on which Auto-MDIX is also disabled, PHY2 will be configured to operate as a DCE (MDI-X) only, and the link will be dropped if the interface on the other device is also configured as a DCE (MDI-X) and they are connected by a “straight-through” cord, or the interface on the other device is configured as a DTE (MDI) and they are connected by a “cross-over” cord; and that if Auto-MDIX is enabled on PHY2 while no link is active due to an incompatible combination of interface configuration and cord type to a device on which Auto-MDIX is disabled, a link will be established if the speed and duplex configurations are also compatible.
  
• 
  96x1H-IPI.5.1.100: Add explicit requirements for the following, which were previously in the scope of the hardware requirements, but are actually determined by registers under software control: 1) that the Ethernet line interface will operate as a DTE (an MDI without crossover function), 2) that automatic MDI/MDI-X Configuration will be enabled on the Ethernet line interface, 3) that the secondary line interface will operate as a DCE (an MDI with crossover function), and 4) that automatic MDI/MDI-X Configuration will also be supported on the secondary Ethernet interface.
  
• 
  96x1H-IPI.5.1.1100: Specify a new Integer object, endptPHY2AUTOMDIXENABLED, in Group 1 of the MIB, that contains the current value of PHY2_AUTOMDIX_ENABLED converted to integer format.
  

• 
  96x1H-IPI.5.1.320: Specify that if the value of NVVPNENCAPS is "0", "2" or "4", when the telephone initiates IKE phase 1 for a VPN connection to establish an ISAKMP SA, Vendor ID payloads (payload type 13) with Vendor ID payload values for all of the variations corresponding to RFC 3947, draft-ietf-ipsec-nat-t-ike-02 and draft-ietf-ipsec-nat-t-ike-00 will be included in the initial message, with a Rationale that explains that some VPN gateways still use values from the earlier drafts.
  
• 
  96x1H-IPI.5.1.320: Specify that if the telephone is the responder to an ISAKMP SA rekey exchange that includes any of the above Vendor ID payloads, the telephone will respond with the one or two Vendor ID payload(s) that correspond to the latest version of NAT-Traversal that is indicated as supported by the gateway.
  
• 
  96x1H-IPI.5.1.320: Specify that if the value of NVVPNENCAPS is "0", "2" or "4", received payloads with payload types of 15, 20 or 130 will be processed as NAT-D payloads, but NAT-D payloads will only be transmitted with the NAT-D payload type corresponding to the negotiated NAT-Traversal version.
  
• 
  96x1H-IPI.5.1.320: Specify that if the value of NVVPNENCAPS is "1", only IPsec Security Associations with an Encapsulation Mode attribute value of 1 will be proposed, or accepted if received, and if the value of NVVPNENCAPS is "0", "2" or "4", IPsec Security Associations with an Encapsulation Mode attribute value of 3 or 61443 will be accepted if received, but only IPsec Security Associations with an Encapsulation Mode attribute value corresponding to the negotiated NAT-Traversal version will be proposed.
  
• 
  96x1H-IPI.5.1.320: Specify that NAT-OA payloads will not be sent, and payload types 16, 21 and 131 will be ignored if received.
  

• 
  Sections 1.0 and 7.1: Added a reference to the R6.3 PRD.
  
• 
  96x1H-IPI.3.1.100: Changed to allow for the possibility of parameters besides SIG retaining their values through a “cross-grade” to software that supports a different signaling protocol, since there is such a SIP requirement.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3a-1, 3a-1b, 3a-2, 3a-3, 3a-4, 3b-1, 3b-1b, 3b-2, 3b-3, 3b-4 and 3b-5: replace HTTPS_FilePathURL and HTTP_FilePathURL with just FilePathURL.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3a-1b and 3b-1b: Clarified to indicate that additional configuration files are obtained by using a URL formed by concatenating HTTPS_FilePathURL or HTTP_FilePathURL and the filename string from the GET command.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3a-1, 3a-2, 3b-1, 3b-2: Removed “etag” from the HTTP response display since it was never implemented.
  
• 
  96x1H-IPI.3.1.130: Created this new requirement to contain the existing configuration file parameter value setting exceptions that were previously in 96x1H-IPI.3.1.100, flowcharts 3a-1b and 3b-1b, and added rationales.
  
• 
  96x1H-IPI.3.1.300: Clarified that startup procedures will be terminated when the Access Code Entry procedure is invoked.
  
• 
  96x1H-IPI.3.2.90: Added a Note that it is left up to the discretion of software development as to whether it is safe to interrupt the startup procedures, because certain operations, such as writing a file to flash, could cause corruption if they are interrupted.
  
• 
  96x1H-IPI.5.1.306: Removed the requirement that the value of IPADDV6LL be used as the Source Address if IPADDV6 is null, because according to 96x1H-IPI.5.1.300, if IPADDV6 is null, IPv4-only operation will be enabled.
  
• 
  96x1H-IPI.5.1.600: Removed the sentence “If this results in a new value being assigned to IPV6STAT or DHCPSTAT that is different than the previous value, any IP addresses that were obtained via DHCP or DHCPv6 will be released, and a reset will be initiated.” and the Rationale that follows, because IPV6STAT and DHCPSTAT cannot be set via DHCP, so that case cannot happen.
  
• 
  96x1H-IPI.5.1.900: Clarified the support of AES media encryption, SRTP/SRTCP and the non-support of FEC. Also corrected the Note about payload types used by encrypted media.
  
• 
  96x1H-IPI.5.1.1000: Clarified that G.729B used with G.729A is sometimes called G.729AB.
  
• 
  96x1H-IPI.5.1.1100: Added a Note that B189 H.323 speakerphone MIBs begin with 1.3.6.1.4.1.6889.2.69.8.
  
• 
  96x1H-IPI.5.1.1100 and 96x1H-IPI.5.1.1300: Changed most occurrences of “syslog messages” to “log event records”.
  
• 
  96x1H-IPI.5.1.1400: Moved the requirement for the User-Agent header here from 96x1WML.1 in [7.1-8] because all HTTP requests, not just those from the browser, should include the same User-Agent header.
  
• 
  96x1H-IPI.5.1.1550: Clarified that the flowchart is to be used to authenticate other devices’ identity certificates.
  
• 
  96x1H-IPI.5.1.1700: Clarified that the RSA host key has a length of 1024 bits and replaced the list of example private data with a reference to new requirement 96x1H-IPI.5.2.400 (see below).
  
• 
  96x1H-IPI.5.2.300: Changed to require compliance with FIPS PUB 186-2. This is an editorial change because the X9.17 Key Generation technique specified in Section 7.2 of IETF RFC 1750, which was previously required by this requirement, is one of the FIPS approved pseudorandom number generators.
  
• 
  96x1H-IPI.5.2.400: Created a new requirement that contains the list of example private data that was formerly in 96x1H-IPI.5.1.1700.
  

Make the following changes for R6.3+, per PRD item 6.4.4:

• 
  96x1H-IPI.2.1.500: Mark NVVOXFILE as “Approved only for releases prior to R6.3”.
  
• 
  96x1H-IPI.2.1.1200: Mark VOXFILES as “Approved only for releases prior to R6.3”.
  
• 
  96x1H-IPI.2.2.800: Mark this requirement as “Approved only for releases prior to R6.3”.
  
• 
  96x1H-IPI.3.1.100, flowchart 3b-4: For R6.3+, change to skip downloading of VOX files.
  
• 
  96x1H-IPI.5.1.1100: Mark endptVOXFILES (in Group 1) and endptNVVOXFILE (in Group 2) as “Obsolete for R6.3+”.
  

• 
  96x1H-IPI.2.1.1200: For R6.3+, add a new parameter, CCLOGOUTIDLESTAT, with valid values of "0" (the default), "1" or "2", to specify whether logging out of a call center will set the Headset LED and audio path to Off, or will leave it On, see 96x1Tel.3.2.9300 in [7.1-6].
  

• 
  96x1H-IPI.2.1.1200: For R6.3+, add a new parameter, SYSAUDIOPATH, with valid values of "0" (the default) or "1", to specify whether the user can select an Option for Audio Path, or whether the setting is set by the administrator, see 96x1Tel.3.2.900 in [7.1-5].
  

• 
  96x1H-IPI.2.1.1200: For R6.3+, change the valid values of AGTSPKRSTAT to "0" through "4".
  

• 
  96x1H-IPI.2.1.1200: For R6.3+, change the valid values of HEADSETBIDIR to "0", "1" or "2".
  

• 
  96x1H-IPI.5.1.1100: For R6.3+, in Group 1 of the MIB, mark endptPWBCC and endptPWBSN as Obsolete. Since they are DisplayString objects, they should return a value of null when obsolete.
  

• 
  96x1H-IPI.3.1.100: For R6.3+, remove "one-X" from the Avaya name/logo.
  

• 
  96x1H-IPI.3.1.100: Remove the following: "during which factory test procedures may be activated. If and only if the "*" button on the dial pad is pressed while the Beacon LED is illuminated, any persistent parameters that were set via factory test procedures before the last reset will continue to retain their values, otherwise such parameters will be reset to their default values."
  and for R6.3+, add the following: "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 2 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, 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. If a "c" was entered, a command-line interface to the operating system will be supported on the serial interface, independent of the value of NVDEBUG; if a "m" was entered, settings appropriate to the selected board type will be used, and startup will continue; if a " " (space) was entered, the serial software download procedure will be invoked. If they do not match, or if 6 characters are not entered within the 10 seconds, startup will continue as specified below."
  

Make the following changes for R6.3+:

• 
  96x1H-IPI.2.1.1150: Add a new parameter, LLDP_XMIT_SECS, with valid values of 1 to 4 ASCII numeric digits, "1" through "3600", and a default value of "30" to specify the rate in seconds at which LLDP messages will be transmitted.
  
• 
  96x1H-IPI.2.1.1200: Add the following new parameters:
  SSO_CLIENT_CERT, with valid values of "0" (the default) or "1", to specify whether the telephone will request and authenticate an identity certificate from the PC during the TLS handshake for SSO;
  SSO_DISCONNECT_ACTION, with valid values of "1" (the default), "2" or "3", to specify what the telephone does if the link is lost on the secondary Ethernet interface while an SSO connection is active;
  SSO_DISCONNECT_FACS, with valid values of 0 to 255 ASCII characters: a list of sequences of dialable ASCII characters (0-9, * and #), separated by commas without any intervening spaces, to specify a list of Feature Access Codes (FACs) to be activated before the telephone unregisters due to loss of the SSO link;
  SSO_ENABLED, with valid values of "0" (the default) or "1", to specify whether the SSO capability will be enabled;
  SSO_LOCK_SYNC, with valid values of "0" or "1" (the default), to specify what the telephone does if it receives a Lock or an Unlock SSO command;
  SSO_REGISTERED_MODE, with valid values of "1" (the default) or "2", to specify what the telephone does if it receives credentials from an SSO application when it already registered but not with a Guest registration.
  
• 
  96x1H-IPI.2.1.1400: Add a new parameter, SSO_TLV_VALUE, with valid values of 12 printable ASCII characters (i.e., 21 through 7E hex: "!!!!!!!!!!!!" through "~~~~~~~~~~~~", and a default value of "000000000000" to specify the value to be included in the LLDP SSO Random String TLV.
  
• 
  96x1H-IPI.3.1.100, flowchart 4d: Add entry point 4d-1 before the display of "Contacting call server…".
  
• 
  96x1H-IPI.4.3.100: Add a new requirement to specify the enablement, discovery and protocol mechanisms for SSO, including the following:

  After startup/reset procedures have completed, if the value of SSO_ENABLED is not 0, and if the value of NVVPNMODE is 0, and if IPv4-only or dual-stack operation is enabled, and if an identity certificate is stored in the telephone, and if the telephone is not registered with credentials from a USB Login profile, any time a link is established on the telephone’s secondary (PC) Ethernet interface, the TCP port specified for the reception of SSO commands will be opened and it will remain open as long as that link remains established.

  Any time a link is established on the telephone’s secondary (PC) Ethernet interface, or when a TCP connection on the SSO port is terminated, the value of SSO_TLV_VALUE will be set to a new randomly generated 12-character string that is not all zeroes. When the SSO TCP port is closed, or when a TCP connection is established, the value of SSO_TLV_VALUE will be set to all zeroes.

  Only IPv4 TCP connections will be supported on the SSO port.

  If a TCP connection is established on the SSO port, if anything other than a TLS handshake is initiated on that connection, the telephone will terminate the TCP connection.

  If the value of SSO_CLIENT_CERT is 1, the telephone will request a certificate from the client during the TLS handshake, and it will attempt to validate the received certificate. If a certificate is not received or if it cannot be validated, the telephone will terminate the TCP connection.

  SSO commands and responses will be based on XML. The SSO application sends commands to the telephone, and the telephone sends responses or unsolicited status indications to the SSO application.

  If the telephone receives a message that cannot be parsed, it will terminate the TCP connection.

  If the telephone receives a message that is not supported, it will discard the message and send an Error response with an error code of 1.

  When a connection is first established, or after an Unregistration Successful response has been sent, only a Register command will be processed until the telephone sends a Registration Successful response. If any other command is received before that, the telephone will send an Error response with an error code of 2.

  If the telephone receives a new command before it has completed the processing of a previous command, it will discard the new command and send an Error response with an error code of 3.

  If a Register command is not received within 2 seconds after a TCP connection is established on the SSO port, the telephone will terminate the TCP connection.

  If a Register command is received that does not contain a element, or that contains a element with a value that does not match the previous value of SSO_TLV_VALUE, the telephone will terminate the TCP connection.

  If no TCP message is received on the SSO connection for 30 seconds, the telephone will transmit a TCP keep-alive message. If a response is not received within 10 seconds, up to 4 additional keep-alive messages will be transmitted at 10-second intervals. If a response is not received within 10 seconds after the last keep-alive is transmitted, the telephone will terminate the SSO TCP connection.

  The telephone will support the following received SSO commands: Register, Unregister, Lock, Unlock, FAC.

  The telephone will support sending the following SSO responses / status indications: Registration Successful, Registration Failure, Busy, Unregistration Successful, Lock Successful, Lock Failure, Unlock Successful, Unlock Failure, Error.

  
  
• 
  96x1H-IPI.5.1.260: Specify that if the value of SSO_ENABLED is not 0, and if transmission of LLDP frames has not begun by the time the TCP port specified for the reception of SSO commands is opened, transmission of LLDP frames will begin at that time, that the same set of TLVs (Type-Length-Value elements) will be transmitted on both the Ethernet line interface and on the secondary Ethernet interface, that once transmission begins, an LLDPDU will be transmitted at an interval in seconds equal to the value of LLDP_XMIT_SECS, and specify a new Avaya Proprietary SSO Random String TLV that will contain the value of SSO_TLV_VALUE.
  
• 
  96x1H-IPI.5.1.500: Specify that TCP port 18414 be used for SSO connections.
  
• 
  96x1H-IPI.5.1.1100: Add a new object, endptSSO, to Group 1 of the SNMP MIB, with a value of 1 if the telephone is registered with credentials that were provided by, or that are the same as those provided by, an SSO Register command, else 0.
  

Make the following changes for R6.3+:

• 
  96x1H-IPI.2.1.1100: Add a new parameter, DOT1XWAIT, with valid values of "0" (the default) or "1", to specify whether the telephone will wait for 802.1X authentication to complete before initiating DHCP.
  
• 
  96x1H-IPI.3.1.100 flowchart 1: Add a test such that if the value of DOT1XWAIT is "0" when the 802.1X Supplicant is started, startup will continue without waiting for 802.1X authentication to complete, and add a Rationale that not waiting for 802.1X to complete is necessary for interworking with some Authenticators that do not respond to EAPOL-Start messages and that require receiving other traffic from an endpoint before initiating 802.1X, and a Note that if such an Authenticator does not allow DHCP messages through the unauthenticated port, the DHCP VLANTEST could fail if the Authentication Server is slow to respond.
  
• 
  96x1H-IPI.3.1.100 flowchart 1c: Add steps such that if the 802.1X Supplicant is enabled, duplicate address detection will be reinitiated after 802.1X authentication has completed.
  
• 
  96x1H-IPI.5.1.240: Specify that the parameter portValid will have a value of TRUE, add a Rationale that 802.1X-2004 introduces the portValid parameter, and in spite of its definition in Section 8.2.2.2 of that standard, it must be set to TRUE for the Supplicant PAE state machine (Figure 8-17) to operate as indicated by Figure 8-7, i.e., for the Supplicant to assume that the port is authorized if it does not receive a response after the startPeriod timer expires after sending a third EAPOL-Start message and receiving no response, which allows operation if the Supplicant is enabled but the Authenticator is not, and remove the Note that states "802.1X failure will be displayed if the Supplicant is enabled in the telephone but if 802.1X is not enabled on the port. This is a difference from 802.1X-2001 operation in 96xx telephones."
  
• 
  96x1H-IPI.5.1.604: Specify that if the value of DOT1XSTAT is not "0", Duplicate Address Detection will not be initiated until after 802.1X authentication has completed.
  
• 
  96x1H-IPI.5.1.606: Specify that if the value of DOT1XSTAT is not "0", Duplicate Address Detection will not be initiated until after 802.1X authentication has completed.
  

• 
  96x1H-IPI.2.1.1100: For R6.2.4+, change the valid values of PROCPSWD to 4 to 7 numeric digits, "0000" through "9999999".
  
• 
  96x1H-IPI.5.1.1100: For R6.2.4+, in Group 1 of the MIB, mark endptPROCPSWD as Obsolete. Since it is an Integer object, it should return a value of 0 when obsolete.
  

Make the following changes for R6.2.3+:

• 
  96x1H-IPI.2.1.1150: Add a new parameter, LOGTOFILE, with valid values of "0" (the default) and "1" to specify whether optional debug printf strings will be logged to an internal file.
  
• 
  96x1H-IPI.5.1.1100: Add a new integer object to Group 1 of the MIB, endptLOGTOFILE, with a value equal to the current value of LOGTOFILE converted to integer format.
  
• 
  96x1H-IPI.5.1.1350: Add a new requirement that specifies that if and only if the value of the parameter LOGTOFILE is "1", optional debug printf strings will be saved in an internal file. Also add a Note that some special (critical) debug printf strings may be saved in an internal file even if the value of LOGTOFILE is "0", and a Rationale that these printf strings are not the same as, and need not have the same format as, the log event messages specified in 96x1H-IPI.5.1.1300.
  

Make the following change for R6.2.3+:

• 
  96x1H-IPI.3.1.100, flowchart 4c: Change so that even if an identity certificate is stored in the telephone that was obtained from the URL that is the value of MYCERTURL, if the length of the certificate’s public/private key pair does not match the current value of MYCERTKEYLEN, the certificate will be deleted and SCEP will be used to obtain a new one.
  

• 
  96x1H-IPI.5.1.1600: Clarify that if the SCEP HTTP request fails or is abandoned, the telephone will continue with start-up, and it will not try to contact the SCEP server again unless it is reset or power-cycled. Also specify that the telephone will attempt to contact the SCEP server every 5 minutes if the initial certificate renewal attempt is not successful.
  

Make the following changes for R6.2.3+, per PRD item 6.7.36:

• 
  96x1H-IPI.5.1.1400: Specify that if the authority portion of the URL (see Section 3 of RFC 3986) provided by the application contains a DNS name, that DNS name will be used in the Request-URI (see Section 5.1.2 of RFC 2616) or in the Host: header, as appropriate, it will not be replaced by an IP address resolved via DNS, with a Note that if the authority portion of the URL was created by concatenating the value of DOMAIN with a value of HTTPSRVR or TLSSRVR, the complete authority portion must be used in the appropriate HTTP field, and with a Rationale that some customers use distributed content delivery systems that only recognize the intended resource if the fully-qualified DNS name is included. Also specify that if the HTTP client receives a response code of 301 (Moved Permanently), 302 (Found), 303 (See Other), or 307 (Moved Temporarily), the HTTP request will be resent using the URL provided in the received Location: header. A URL received in a Location: header in a 301 response will be stored in volatile memory for automatic reuse if the same Request-URI is requested. A maximum of 5 redirections will be attempted per request before the request is abandoned.
  

• 
  96x1H-IPI.5.1.200: For R6.2.2+, specify that all telephones that have an internal Ethernet switch will support a port mirroring mode that is disabled by default, but when it is enabled, all frames that are forwarded from the Ethernet line interface to the telephone, and all frames that are forwarded from the telephone to the Ethernet line interface, will also be forwarded to the secondary Ethernet interface. If port mirroring is enabled, it will remain enabled through a reset, but if the telephone loses power, port mirroring will be disabled. Also add a Note that port mirroring can be enabled and disabled from the Debug procedure on the craft menu, as specified by 96x1LA.6.2.800 in [7.1-5].
  

Make the following changes for R6.2.2+, per PRD item 6.8.6:

• 
  96x1H-IPI.2.1.1200: Add two new parameters, AUTOANSSTAT, with valid values of “0” (the default) through “4”, to specify whether the telephone will auto-answer incoming calls per 96x1Tel.3.2.3160, and AUTOANSSTRING, with a valid value of a string of 0 (the default) to 15 ASCII characters, to specify the VDN to be matched for auto-answering incoming calls, per 96x1Tel.3.2.3100.
  
• 
  96x1H-IPI.5.1.1100: Add two new objects to Group 1 of the SNMP MIB, endptAUTOANSSTAT with a value equal to the current value of AUTOANSSTAT converted to integer format, and endptAUTOANSSTRING with a value equal to the current value of AUTOANSSTRING.
  

Make the following changes for R6.2.2+, per PRD item 6.8.6:

• 
  96x1H-IPI.2.1.1200: Add a new parameter, AUTOANSALERT, with valid values of “0” (the default) and “1”, to specify whether the telephone will audibly alert for auto-answered calls.
  

• 
  96x1H-IPI.2.1.1200: For R6.2.1+, add a new parameter AGTACTIVESK with valid values of “0” (the default) through “2” to specify a Call Center Agent’s active softkey labels.
  

• 
  96x1H-IPI.2.1.1200: For R6.2.1+, add a new parameter AGTGREETLOGOUTDEL with valid values of “0” or “1” (the default), to specify whether agent greetings will be deleted when the agent logs out.
  

• 
  96x1H-IPI.2.1.1200: Change AGTIDVUSTAT to AGTVUSTATID.
  

• 
  96x1H-IPI.4.1.100: Add a requirement for R3.1.5+ that if TLS is used, the IP address of the call server with which the telephone is registered and the telephone’s registration password will be included as the credentials in an Authorization request-header in each transmitted GET and PUT method only if the value of BRURI does not begin with "https://string1:string2@..." (see 96x1H-IPI.5.1.1400).
  
• 
  96x1H-IPI.5.1.1400: Add the following: If a URI begins with either "http://string1:string2@..." or "https://string1:string2@...", the "string1:string2@" portion will be removed from the URI before it is used in an HTTP request, and "string1:string2" will be encoded in base64 and included in an Authorization: header in the HTTP request as specified for HTTP Basic Authentication in Section 2 of RFC 2617. The strings will not be treated as user-specific data. Add a Note that HTTP Basic Authentication is not secure, because decoding base64 is only slightly harder than decoding Pig Latin, and the inclusion of authentication credentials in a URI that is the value of a parameter in a configuration file is also not secure, because even though they will be removed from the URI before the HTTP request is sent, the downloading of configuration files is not secure, even if HTTPS is used, because the files are sent to any client that requests them. Therefore, this mechanism should only be used as a work-around for compatibility with file servers that require authentication, by customers that would not otherwise use authentication. Add a Rationale that Microsoft IIS version 7 and later file servers require authentication for PUT requests.
  

• 
  96x1H-IPI.5.1.1550 flowchart: Clarified that if even one certificate is downloaded via TRUSTCERTS, it/they will be used instead of the built-in Avaya CA certificates.
  

While SCEP was first implemented to provide an identity certificate for use with certificate-based VPN authentication methods, a customer has requested that such a certificate also be usable to authenticate the telephone when using TLS, specifically with HTTPS used for backup/restore.

• 
  96x1H-IPI.5.1.1500: Add the following for R6.2.1+: "If an identity certificate is stored in the telephone, it will be used during the TLS handshake as required when the telephone is acting as a server, and will be transmitted on request when the telephone is acting as a client." Also add a Note that an identity certificate can be stored in the telephone using SCEP as specified in 96x1H-IPI.5.1.1600.
  

Note: This MR was initially approved for R6.2, but was subsequently removed from that release, so the proposed changes have been returned to the READY state. It is anticipated that this will be reapproved for R6.2.1.

• 
  96x1H-IPI.2.1.1100: Add a new parameter DOT1XEAPS, with valid values of "MD5" or "TLS" and a default value of "MD5".
  
• 
  Section 5.0: Add TLS as a supported EAP method in the protocol stack diagram.
  
• 
  96x1H-IPI.5.1.240: Specify that EAP-MD5 will only be supported if the value of DOT1XEAPS is "MD5", that EAP-TLS will be supported as specified in RFC 2716 if the value of DOT1XEAPS is "TLS" (other TLS requirements specified in 96x1H-IPI.5.1.1500 also apply), that if an EAP method requires the authentication of a digital certificate, the requirements specified in 96x1H-IPI.5.1.1550 also apply, and that if the Supplicant is enabled and the value of DOT1XEAPS changes, the Supplicant will transmit an EAPOL-Logoff message and return to the CONNECTING state.
  
• 
  Section 7.3: Add an asterisk to [7.3-19f] (RFC 2716) to indicate that it is referenced in the body of a requirement.
  

• 
  96x1H-IPI.2.1.1200: Change to specify that the default value of HEADSYS prior to R6.2.1 is “1”, and that the default value of HEADSYS for R6.2.1+ is “0”.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3a-1b and 3b-1b: For R6.2.1+, change to specify that if HEADSYS was not set in a configuration file, and if the value of CALLCTRSTAT was set to 1, the value of HEADSYS will be set to 1.
  

• 
  96x1H-IPI.2.1.1150: Changed the valid value range for MYCERTCN from “ 0 to 255 characters” to “8 to 255 characters (because valid values must contain “$SERIALNO” or “$MACADDR”, and the minimum length value is “$MACADDR” without any additional characters), and changed the valid value range for MYCERTKEYLEN from “1024 through 2048” to “1024 or 2048”.
  
• 
  96x1H-IPI.2.1.1200: Removed SSH parameters for which the procedures were not implemented (SSH_LOCKOUT_ATTEMPTS, SSH_LOGIN_DELAY and SSH_USERNAME).
  
• 
  96x1H-IPI.2.2.700: The content of this requirement was moved to flowcharts 3a-3 and 3b-3 in 96x1H-IPI.3.1.100.
  
• 
  96x1H-IPI.3.1.110: Removed the requirement that the digital signature contained in a Signature File will be verified as specified in Section 5.2.2 of RFC 3447 using the sha1WithRSAEncryption algorithm (even though it will be) because the encryption algorithm used to generate the signature is determined by the certificate itself (an RSA certificate uses RSA encryption), and the message digest algorithm is specified in the object that also contains the message digest. A Note states that signature verification is specified in 96x1H-IPI.5.1.1550.
  
• 
  96x1H-IPI.4.1.100: Clarified that the “basic” authentication scheme will be used when the call server IP address and the telephone’s registration password are included as the credentials in an Authorization request-header.
  
• 
  96x1H-IPI.5.1.240: Removed the requirement to change state if the value of DOT1XEAPS changes, and changed the requirement that an identity certificate be stored in the phone for EAP-TLS to be supported to a Note that an identity certificate is required for successful use of EAP-TLS.
  
• 
  96x1H-IPI.5.1.260: Clarified that the 2005 version of LLDP is required.
  
• 
  96x1H-IPI.5.1.600: Changed the fourth paragraph following flowchart DHCP 2b/2c to specify that if the value of ReuseCheck is 1 and the list of potential value changes contains a value for L2QVLAN that is also a value of NVVLANLIST, all IP addresses that were obtained via DHCP or DHCPv6 will be released when the list of values is discarded, before processing continues at flowchart entry point DHCP 2c.
  
• 
  96x1H-IPI.5.1.1550: Removed the exception that allowed application-specific or protocol-specific certificate authentication procedures, and added wording to specify the certificates and algorithms currently supported.
  
• 
  96x1H-IPI.5.1.1700: Removed SSH requirements for procedures that were not implemented and added a requirement that SCP is supported.
  
• 
  Updated references from UCR 2008 Change 1 [7.8-1b] to UCR 2008 Change 3 [7.8-1d].
  
• 
  96x1H-IPI.5.1.1700: Removed SSH capabilities that were not implemented.
  

• 
  96x1H-IPI.2.1.1200: Mark CNAPORT and CNASRVR as applicable only to releases prior to R6.2.
  
• 
  96x1H-IPI.5.1.260: Mark the LLDP Avaya/Extreme Proprietary CNA Server IP Address TLV as applicable only to releases prior to R6.2.
  
• 
  96x1H-IPI.5.1.400: Mark CNA port usage as applicable only to releases prior to R6.2.
  
• 
  96x1H-IPI.5.1.500: Mark CNA port usage as applicable only to releases prior to R6.2.
  
• 
  96x1H-IPI.5.1.920: Mark this requirement as applicable only to releases prior to R6.2.
  
• 
  96x1H-IPI.5.1.1100: mark endptCNAPORT and endptCNASRVR as obsolete for release R6.2+.
  

• 
  96x1H-IPI.2.1.1200: Add a new parameter ADMIN_HSEQUAL with a default value of "1" and valid values of "1" or "2".
  

• 
  96x1H-IPI.2.1.1200: Add new parameters RECORDINGTONE_INTERVAL with a default value of "15" and valid values of "1" through "60", and RECORDINGTONE_VOLUME with a default value of "0" and valid values of "0" through "10".
  

• 
  96x1H-IPI.3.1.100: For releases R6.0.4+ (except R6.1.x), specify that the secondary Ethernet interface will be activated shortly after the activation of the line interface instead of as soon as possible, and specify that if the value of PHY2STAT is "1" (auto-negotiate), and if the line interface has been successfully established, the auto-negotiation procedure on secondary interface will only indicate support for speeds that are less than or equal to the operating speed of the line interface. Also, add the following to the Rationale: 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.
  

• 
  96x1H-IPI.2.1.1200: Add a new parameter, DEFAULTRING, with valid values of 1 or 2 ASCII numeric digits “1” through “14” and a default value of “9”.
  

• 
  96x1H-IPI.2.1.1200: For R6.2+, add a new parameter HEADSETBIDIR with valid values of “0” (the default) or “1” to specify whether bidirectional signaling will be supported on the headset interface, and reference 96x1COPS.6.1.100 in COMPAS ID 143547.
  

This MR is intended to document existing software operation.

• 
  Move the specification of VUMCIPADD from 96x1H-IPI.2.1.1150 to 96x1H-IPI.2.1.1100. This change will require that VUMCIPADD be settable via the DHCP site-specific option as well as via a configuration file.
  

This MR is intended to document existing software operation.

• 
  96x1H-IPI.5.1.604: Change to specify that if the DHCP lease expires when the value of DHCPSTD is 1, the name/logo screen will be displayed as specified in 96x1H-IPI.3.1.100 with "DHCP Lease Expired" on the top reserved text line for approximately 5 seconds. If a reset is required to enter the DHCP INIT state, "Resetting" will also be displayed on the bottom reserved text line and a reset will be executed as specified in 96x1H-IPI.3.1.100, otherwise, operation will proceed as specified in 96x1H-IPI.5.1.600.
  
• 
  Appendix A: Add the strings "DHCP Lease Expired" and "Resetting".
  

• 
  Sections 1.0 and 7.1: Updated PRD references.
  
• 
  96x1H-IPI.3.1.100, flowcharts 3a-1, 3a-2, 3a-3, 3b-1, 3b-2, 3b-3, 3b-4, 3c-1, 3c-2: Combined the steps that specified the processing of 200 and 503 response codes into a single step that tests whether the file was successfully received, since the processing of a 503 response code is already specified for HTTP operation in 96x1H-IPI.5.1.1400.
  
• 
  96x1H-IPI.4.2.220, 96x1H-IPI.5.1.1100 (Group 8), and 96x1H-IPI.5.1.1600: Changed terminology from “device” certificate to “identity” certificate to reflect common industry usage.
  

• 
  96x1H-IPI.2.1.1200: Add a new parameter AGTIDVUSTAT with valid values of "0" through "50" and a default value of "0".
  

• 
  96x1H-IPI.2.1.1200: Add a new parameter RECORDINGTONE with valid values of "0" or "1" and a default value of "0".
  

• 
  96x1H-IPI.2.1.1200: Add a new parameter BLUETOOTHSTAT with valid values of "0" or "1" and a default value of "1".
  

• 
  96x1H-IPI.2.1.1200: For R6.2+, add the following parameters:
  SSH_ALLOWED, with valid values of "0" or "1" (default "0");
  SSH_BANNER_FILE, with valid values of 0 to 255 ASCII characters (default null);
  SSH_IDLE_TIMEOUT, with valid values of "0" through "32767" (default "10").
  
• 
  96x1H-IPI.3.1.100: For 6.2+, add flowchart 3b-5 to specify downloading a warning banner text file if the value of SSH_ALLOWED is not "0" and if the value of SSH_BANNER_FILE is not null.
  
• 
  96x1H-IPI.5.1.500: For R6.2+, specify that TCP port 22 will be used by SSH.
  
• 
  96x1H-IPI.5.1.1700: For R6.2+, add a new requirement that specifies the following:
  

SSHv1 will not be supported.

An SSH client will not be supported via any interface.

TCP/IP port forwarding will not be supported (see Section 7 of RFC 4254).

A common (non-unique) RSA host key (and the corresponding private key) will be included in the software. The private key will be encrypted in the software distribution package and the decryption key will be obscured as much as possible.

Only the aes128-cbc and 3des-cbc cipher suites will be supported, with aes128-cbc listed as the most preferred.

Only the hmac-sha1 and hmac-sha1-96 Message Authentication Codes (MACs) will be supported, with hmac-sha1 listed as the most preferred.

When SSH is enabled, the TCP port specified for SSH will be opened to listen for connection requests. When SSH is disabled, the TCP port will be closed.

SSH will only be enabled if the value of SSH_ALLOWED is not "0".

Only one SSH connection and one session will be supported at a time.

If the value of SSH_ALLOWED is "1", SSH will be enabled with challenge/response authentication supported using the generic interactive authentication messages specified in RFC 4256. The challenge message will be as specified below:

byte SSH_MSG_USERAUTH_INFO_REQUEST

• 
  96x1H-IPI.2.1.1150: Add a new parameter APPLICATIONWD, with valid values of "0" or "1" and a default value of "1", to control whether the application watchdog is enabled or disabled, and include the following Note: "The application watchdog is a software process that monitors other software processes to determine whether they have become unresponsive, at which point it generates a log event and either kills the process or resets the telephone. No further requirements are specified for this operation. However, even though it may be preferable to stop a “non-critical” process, or even to reset the telephone to restore the operation of a critical process, the failure of such a process is still a bug that should be fixed."
  

• 
  96x1H-IPI.4.2.210: Clarified that the on-screen keyboard is displayed for input of VPN credentials on touchscreen telephones.
  
• 
  96x1H-IPI.4.2.200: The flowchart was clarified to indicate that the IPsec SAs use ESP, and at the end of the requirement, a sentence was added to clarify that a received Welcome Banner will not be displayed on the telephone.
  
• 
  96x1H-IPI.5.1.320: Clarified in a Note that, based on the valid values of NVIKIP2LIFESEC, rekeying would not happen more often than every 8 minutes, not 2 minutes.
  
• 
  96x1H-IPI.5.1.1100: Corrected the spelling and capitalization of some of the node names at the top of the MIB.
  
• 
  96x1H-IPI.5.1.1100: Changed 3 occurrences of “NVLOGLOCAL” to “LOGLOCAL” in Group 3 of the MIB to align with 96x1H-IPI.2.1.1100.
  
• 
  96x1H-IPI.5.1.1600: Clarified that only a certificate is downloaded via SCEP, not the associated private key (the private key is generated by the telephone and stays in the telephone).
  
• 
  Section 5.2: Removed the table that summarized support of the Avaya Security Standard, because the Avaya Security Standard has been broken into five security blueprints with revised requirements and different requirement identifiers.
  
• 
  Section 7.1: Added references to internal Avaya requirement “Blueprints”.
  

The 9621 and 9641 do not have enough space to display the HTTP Authentication screen with the on-screen keyboard as currently specified, so an alternate screen needs to be specified.

• 
  96x1H-IPI.5.1.1400: Specify that touchscreen phones display the same text on the Status line and on the first application line as button-oriented phones. Touchscreen phones will display “User ID...”, left-justified on the second application line, and if there is a non-null userid for the indicated realm, it will be displayed, right-justified on the same line. “Password...” will be displayed, left-justified on the third application line. If there is a non-null password for the indicated realm, eight asterisks will be displayed, right-justified on the same line. Both of these lines will be selectable. If the “User ID...” line is selected, the on-screen keyboard will be displayed and normal text entry procedures will be used as specified by 96x1COPS.4.1.250 and 96x1COPS.4.1.450. “User ID:” will be displayed to the left of the input field, and if there is a non-null userid for that realm, it will be displayed in the input field. If the “Password...” line is selected, the on-screen keyboard will be displayed and Password text entry procedures will be used as specified by 96x1COPS.4.1.250, 96x1COPS.4.1.450 and 96x1COPS.4.1.550. “Password:” will be displayed to the left of the input field, which will initially be empty. A Cancel softkey will always be provided, and an Enter softkey will be provided when both values are not null.
  

• 
  96x1H-IPI.5.1.700: For R6.0.4+, specify that an entry will be removed from the ARP cache if and only if 20 minutes have elapsed since a message was received with a source MAC address and IP address that correspond to that entry, and add the following Rationale: It is important to remove stale ARP cache entries because, for example, if a telephone is removed from the subnet and its IP address is given to a new telephone by DHCP, other telephones sending RTP packets to that IP address would send them to the old MAC address (which would be perceived as a one-way audio path) until they happen to reset and clear their ARP cache. Section 2.3.2.1 of RFC 1122 specifies that ARP implementations MUST provide a mechanism to flush out-of-date cache entries, but that if the mechanism involves a timeout, that it SHOULD be possible to configure the timeout value. It also recommends that if a timeout is used, that it be on the order of a minute or less. However, it also states that in the absence of proxy ARP (which is now obsolete), that a timeout this short could create noticeable overhead traffic on a very large Ethernet and that, therefore, it may be necessary to configure a host to lengthen the ARP cache timeout. A short ARP cache timeout could also make a device more susceptible to ARP cache “poisoning”. Linux seems to have a default ARP cache timeout of 40 seconds, where VxWorks (used by the 96xx telephones) had a default value of 20 minutes.
  

• 
  96x1H-IPI.2.1.1400: Add a new internal parameter named ALLOW_MEDIA_ENCRYPTION that has a value of "1" in software that allows media encryption and a value of "0" in software that does not allow media encryption.
  
• 
  96x1H-IPI.3.1.100 flowchart 1: Add a step such that if the value of ALLOW_MEDIA_ENCRYPTION is "0", the step that tests whether VPN mode is enabled will be skipped.
  
• 
  96x1H-IPI.3.1.300 flowchart: Add a step such that if the value of ALLOW_MEDIA_ENCRYPTION is "0", it will not be possible to invoke the VPN Settings local procedure.
  

The algorithm specified for signing software packages (the FIPS Digital Signature Algorithm (DSA)) has been wrong since this capability was initially supported It should be corrected as indicated below.

• 
  96x1H-IPI.3.1.110: Specify that the digital signature contained in a Signature File will be verified as specified in Section 5.2.2 of RFC 3447 using the sha1WithRSAEncryption algorithm, where SHA-1 is the message digest algorithm and RSA is the encryption algorithm.
  
• 
  Section 7.3: Add a reference to RFC 3447 (PKCS #1).
  

• 
  96x1H-IPI.3.1.100, flowchart 2b: Changed “Does the prefix of IPADDV6 match the router prefix?” to “Does the prefix of IPADDV6 match a prefix provided by the router?”.
  
• 
  96x1H-IPI.3.1.100, flowchart 3c-1a: In the first test step, changed “RFSNAME_IN_USE”, which is only used by SIP software, to “RFSINUSE”, which is specified in 96x1H-IPI.2.1.500.
  

• 
  96x1H-IPI.2.1.1150: The maximum valid length for NVVPNPSWD and NVVPNUSER of 50 characters for R6.1+ was removed.
  
• 
  96x1H-IPI.2.1.1200: Parameters CAIDSEQU, CLBACKUPTIME and EOEDITDIAL for R6.1+ were removed.
  

Current Requirements specify AGTSPKRSTAT to have 2 values:

0 - Standard operation of the Speaker button, subject to standard CM administration

1- Complete disabling of the Speaker button, as currently specified. {This is the default value, so that a Call Center agent has the Speaker button disabled).

However, the 96x1 Release 6.1 PRD (COMPAS ID 145550) includes Requirement CC-HW-1, which says in part that with the Call Center faceplate, "The speaker button on the non call center 96x1 models will be relabeled with Release for the call center phone. The speaker icon on the button will remain but the operation will be release.".

Current Requirements do not support this, so a proposal has been made to extend the definition of AGTSPKRSTAT to a third value, 2, for use as specified in COMPAS MRs 76482 and 76484.

To support this proposal, Requirement 96x1H-IPI.2.1.1200 would have to be modified to specify the "Valid Values" for AGTSPKRSTAT are '1 ASCII numeric digit; "0", "1", or "2" '.

In addition, the Notes for AGTSPKRSTAT could be expanded to say, ' Disabling of speakerphone permission flag, see 96x1COPS.6.3.100 in [7.1-4]. and 96x1Tel.3.2.9300 in [7.1-6] '

Note the default value is not changed by this proposal.

• 
  96x1H-IPI.3.1.100, flowchart 3c-2a: Clarified that “Updating Kernel/RFS” should be displayed during file extraction as well as during erasing flash and package installation.
  
• 
  96x1H-IPI.5.1.260: Clarified that LLDP will be supported if IPv4-only or dual-stack operation is enabled, but not if IPv6-only operation is enabled.
  
• 
  96x1H-IPI.5.1.1100: Allocated OID 1.3.6.1.4.1.6889.2.69.7 for the Mojo MIB.
  

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.2.1.1200: For R6.1+, add new parameter TIMERSTAT with valid values of 0 (default) and 1.