96x1H-IPI.4.3.100: Synchronized State Operation (SSO, also known as “Single Sign-On”)
Approved
for R6.3+
After startup/reset procedures have completed, i.e., starting at the point marked 4d-1 on flowchart 4d in 96x1H-IPI.3.1.100:
if the value of SSO_ENABLED is not 0, and
if the telephone has an IPv4 address, and
if the value of NVVPNMODE is 0, and
if an identity certificate is stored in the telephone, and
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 (see 96x1H-IPI.5.1.100) the TCP port specified for the reception of SSO commands (see 96x1H-IPI.5.1.500) 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.
Note:
SSO applications discover the IP address of the telephone via LLDP (see 96x1H-IPI.5.1.260). They should verify that the value in the LLDP MED Inventory – Manufacturer Name TLV is “Avaya”, that bit 2 (Bridge) and bit 5 (Telephone) are set in the System Capabilities octets of the System Capabilities TLV, and that the Chassis ID TLV contains a subtype 5 (Network address) value, which is the IP address of the telephone.
Rationale:
LLDP is currently disabled when VPN is active because it could confuse some home Internet access devices, and LLDP does not currently support IPv6.
The LLDP MED Inventory – Manufacturer Name TLV identifies the telephone as an Avaya device, and the System Capabilities TLV identifies it as a telephone, so that an SSO application doesn’t try to establish an SSO TCP connection to non-Avaya devices or to an Avaya Networking switch. The System Capabilities octets of the System Capabilities TLV should be used instead of the Enabled Capabilities octets of the System Capabilities TLV because the Enabled Capabilities will not identify the device as a telephone unless it is already registered for service, which it may not be for this application.
Approved
for R6.3+
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.
Note:
The completion of the processing of all commands except the FAC command is indicated when the telephone sends an associated response, except the Busy response, which indicates that the processing of the command is still pending.
Approved
for R6.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.
Note:
Doing the math, the telephone will terminate the connection if no TCP message is received for 80 seconds.
Rationale:
Terminating the connection if a Register command is not received, or if the Register command does not contain the correct random string, or if the SSO application does not respond to TCP keep-alives is to prevent an improper or an inactive connection from resulting in a denial of service.
Approved
for R6.3+
The telephone will support the following received SSO commands:
Register command:
Unregister command:
Lock command:
Unlock command:
FAC command:
The telephone will support sending the following SSO responses / status indications:
Registration Successful response:
Registration Failure response:
Busy response:
Unregistration Successful response:
Lock Successful response:
Lock Failure response:
Unlock Successful response:
Unlock Failure response:
Error response:
The following Error Codes will be supported:
ErrorCode
Meaning
1
Message not supported.
2
Registration is required before a command other than Register will be processed.
The protocol stacks supported on the Ethernet line interface are illustrated below.
SCEP, WML, Push,
File Xfer, etc.
Audio coding (G.711, G.722, G.726A, G.729A/B)
Hypertext Transfer Protocol (HTTP)
H.323 signaling
Secure RTP
(SRTP)
or AES media encryption (optional)
Secure RTCP (SRTCP) (optional)
Transport Layer Security (TLS) (optional)
Annex H signaling encryption (optional)
Real-Time Protocol
(RTP)
Real-Time Control Protocol (RTCP)
Dynamic Host Config. Protocol (DHCP)
Domain Name Service (DNS)
Simple Network Management Protocol (SNMP)
Syslog
Transmission Control Protocol
(TCP)
User Datagram Protocol
(UDP)
Resource Reservation Protocol (RSVP)
Internet Protocol (IPv4 or IPv6, but only IPv4 is supported as the “Inner” IP for VPN operation)
(including Internet Control Message Protocol (ICMP) and Internet Group Management Protocol (IGMP))
IPsec (only supported for VPN operation)
(Authentication Header (AH) and/or Encapsulating Security Payload (ESP))
Note: IPsec AH is incompatible with NAT, see Section 1 of IETF RFC 3948 [7.3-41c]
IKE / ISAKMP
EAP Method
(MD5, TLS)
UDP encapsulation layer (optional, only supported for VPN operation)
Note: UDP encapsulation is used for traversing Network Address Translation (NAT) devices, see IETF RFC 3948 [7.3-41c].
UDP or TCP
EAP
“Outer” Internet Protocol (IPv4 only, supported for VPN operation)
(including Internet Control Message Protocol (ICMP))
802.1X
Link Layer Discovery Protocol (LLDP)
Address Resolution Protocol (ARP)
Ethernet frame format, optional IEEE 802.1Q frame tagging
