An Avaya Converged Network Analyzer (CNA, formerly known internally as “Chatter”) “test plug” will be supported for IPv4 only as specified in [7.1-22b], in Section 6 of [7.1-14a], and as clarified below.
The test plug will use TLS (see 96x1H-IPI.5.1.1500) over TCP (see 96x1H-IPI.5.1.500) as a transport-layer protocol for registration, and will use UDP (see 96x1H-IPI.5.1.400) as a transport-layer protocol for receiving test requests, for returning test results, and for the RTP/RTCP streams (see 96x1H-IPI.5.1.900) used for some tests. The TCP port used for registration will be closed after registration is complete, the UDP port used to receive test requests will not be opened until or unless CNA registration successfully completes, and the UDP port for RTP/RTCP tests will only be open during such a test.
Initiation of registration of the test plug with the CNA server occurs after the telephone has registered with a call server (see 96x1Tel.2.1.700 in [7.1-6]), and will use the IP address(es) and TCP port number specified by the parameters CNASRVR and CNAPORT (see 96x1H-IPI.2.1.1200). The CNA registration message sent by the telephone will identify the UDP port number on which it will listen for CNA test requests (see 96x1H-IPI.5.1.400), and the UDP port number that it will reserve for CNA RTP tests from the range of UDP port numbers used for audio. Neither FEPORT nor PORTAUD (see 96x1H-IPI.2.1.1400) will be set to a UDP port number used for a CNA RTP test. CNA traceroute tests will comply with 96x1H-IPI.5.1.450.
The test plug will not support more than one test at a time, and need not respond to (even to reject) more than one test request per second. Tests will only be initiated when a call is not active, and tests will be terminated if a call becomes active after the test has started, and may be terminated at any other time that the phone software requires more processing capacity.
Rationale:
The test plug does not register with the CNA server until after it has registered with its call server or proxy so that it does not slow down the availability of telephony to the user.
Neither FEPORT nor PORTAUD is set to a UDP port number used for a CNA RTP test because the telephone’s transducers are not involved in these tests.
96x1H-IPI.5.1.930: Service Level Agreement (SLA) monitor agent support
Approved
for R6.4+
An Agent for the Service Level Agreement (SLA) Monitor application will be supported. UDP and TCP ports used by the Agent will be as specified in 96x1H-IPI.5.1.400 and 96x1H-IPI.5.1.500, respectively.
The Agent will be started as soon as possible after the telephone has an IP address. If and only if the value of SLMSTAT is "1", the Agent will open a UDP port for receiving discovery and test request messages from the SLA Monitor server, and for sending test result messages to the server.
Neither FEPORT nor PORTAUD will be set to a UDP port number used for an SLA RTP test.
The local parameter SLMCTRLSTAT is indicating the current state of SLM Control Agent, and have the values “0”, “1” and “2” indicating ” disabled, enabled and active state, respectively (active means the agent took control of the phone). SLMCTRLSTAT should be initialized as follows:
- If SLMCTRL = “0”, SLA Monitor could never take control of the phone. In this case SLMCTRLSTAT should be initialized to “0”.
- If SLMCTRL = “1” SLA Monitor could take control over the phone. In this case SLMCTRLSTAT should be initialized to “1”.
- If SLMCTRL = “2”, SLA monitor control is controlled by craft menu. SLMCTRLSTAT is initialized to “0”.
Application should interact with SLA Mon agent (either by some callback or polling) and when SLA Mon agent is in control of the phone, SLMCTRLSTAT should be set to “2”
When the control of the phone has terminated and if SLMCTRLSTAT is “2”, it should be set to “1”.
The local parameter SLMCAPSTAT is indicating the current state of SLM Capturing of data (with RTP), and have the values “0”, “1” and “2” indicating ” disabled, enabled and active state, respectively (active means the agent is currently capturing network data including RTP payloads). SLMCAPSTAT should be initialized as follows:
- If SLMCAP = “0”, SLA Monitor could never capture packets on the phone. In this case SLMCAPSTAT should be initialized to “0”.
- If SLMCAP = “1” SLA Monitor could capture packets without RTP payloads. In this case SLMCAPSTAT should be initialized to “0”.
- If SLMCAP = “2”, SLA Monitor could capture packets with RTP payloads. In this case SLMCAPSTAT should be initialized to “1”.
- If SLMCAP = “3”, control for capturing packets with RTP payloads is from craft menu. SLMCAPSTAT is initialized to “0”.
Application should interact with SLA Mon agent (either by some callback or polling) and when SLA Mon agent is in currently capturing packets (with payloads) SLMCAPSTAT should be set to “2”
When packet capturing has terminated and if SLMCAPSTAT is “2”, it should be set to “1”.
Note:
It is the responsibility of the application to make sure that the configuration parameters are available to the agent (i.e., permission to the persistent file), also when they were not available in the configuration file (i.e., initiate the relevant default values). Furthermore, modification to the persistent data file should be performed in agreement with the Avaya Client Services group.
Note:
When in active control mode The SLA Server—Agent interaction might be intrusive to the phone in a similar way to PTI. That is, the server may simulate key presses on the phone, which might interfere with manual/automated test plans.
Rationale:
The agent application that runs on 96x1 is written by Avaya Client Services and is specific to the 96x1 system-on-chip (i.e., cross compiled for the armv6). The agent also indirectly interacts with the 96x1 phone application. It reads the configuration that was downloaded by the 96x1 and uses it for its own purposes. For example, it uses the TRUSTCERTS parameter to obtain the certificates. In addition, the 96x1 software should support a new set of configuration persistent parameters that are dedicated to the functionality the SLA monitor agent, namely SLMSRVR, SLMPORT, SLMTEST, SLMSTAT, SLMPERF, SLMCTRL, and SLMCAP which are specified in 96x1H-IPI.2.1.1150.
Once startup/reset procedures have completed, the SLA Monitor Agent v2 should be spawned. At some later time, the application downloads the configuration file, and writes the persistent parameters to the SLA Mon config file. This file is monitored by the SLA monitor agent, and it is the Agent responsibility to update with the values of the relevant parameters.
Note:
For further information on the SLA Monitor Agent, see [7.1-31a,b,c,d,e,f,g,h,i].
Parameters that control its operation are specified in COMPAS ID 148798[7.1-31f].
Note:
The Agent will attempt to register with an SLA Monitor server using an IP address and port number received in a UDP discovery message. Registration will be done over a TLS connection. If trusted certificates have been downloaded based on TRUSTCERTS, they will be used to authenticate the server’s certificate, otherwise a copy of the Avaya SIP Root CA certificate that is built into the Agent will be used. The registration message sent by the Agent will identify the UDP port number that it will reserve for performing RTP tests, which will not be opened until after registration. After registration, the TCP port used for registration will be closed, and received UDP test request messages will be authenticated using a session key that was established during registration.
Support of SLA Monitor is a high priority for Services because it can be used to remotely detect, diagnose and report on network performance issues. It can also support a remote port mirroring capability to provide protocol traces for debugging.
96x1H-IPI.5.1.940: Qtest
Approved
When Qtest is activated, a UDP message containing a 4 octet Packet ID and a 4 octet Transmit Timestamp (with a precision of at least 1 millisecond) will be sent every 20 milliseconds to the IP address specified by the value of QTESTRESPONDER. Each message will be padded to a length of 180 octets (including the UDP header).
A UDP port will only be opened for Qtest while it is active.
The following values will be generated from the echoed replies:
the total number of packets sent
the total number of packets received
the percentage of packets lost
the largest number of sequential packets lost (the largest burst lost)
the number of packets received out of sequence
the average round-trip delay
the maximum round-trip delay
the percentage of round trip delays longer than 400 milliseconds
the average jitter (the number of milliseconds of delay introduced by the telephone’s jitter buffer)
Note:
QTESTRESPONDER must specify the address of a server that supports the echo service on UDP port 7, as specified in IETF RFC 862 [7.3-10].
Note:
Qtest can be activated and the results will be displayed via the Network Information item on the Phone Settings menu (see 96x1LA.5.3.6000 in [7.1-5]).
Note:
Some networks provide higher quality of service for RTP packets that use a specific UDP port range, so the same quality of service may not be applied to Qtest packets.
Rationale:
The length of a Qtest message is specified as 180 octets in the requirement above, even though requirement 108639.2.2.325 in [7.1-28] requires that Qtest messages be 260 bytes long, because a G.711 RTP packet with 30 milliseconds of audio data would be 260 bytes long (including the UDP header), but Qtest requires sending a message every 20 milliseconds. A G.711 RTP packet with 20 milliseconds of audio data would be only 180 bytes long.
Rationale:
Even though ICMP Destination Unreachable/Port Unreachable error messages returned by a device that does not support echo on port 7 would include the first 64 bits (8 octets) of the Qtest UDP message, these ICMP messages will not be supported to generate Qtest results because they could be rate-limited to resist denial-of-service attacks, which would result in very bad network quality being reported. It is assumed that QTESTRESPONDER will only be set to the IP address of a device that supports echo on port 7.
96x1H-IPI.5.1.950: Audio quality statistics
Approved
Audio quality statistics will be based on characteristics of the receivedaudio stream, as specified below, although the statistic(s) displayed and the display format used may vary. Values will be updated approximately every 5 seconds and will be based on audio data from the previous 5-second interval. When a received audio stream terminates, the last values will continue to be displayed for 5 seconds unless they are replaced by values from a subsequent connection.
Statistic
Values
Received Audio Coding
“G.711”, “G.722”, “G.726”, or “G.729”.
Silence Suppression
“Yes” if it is known that the far-end has silence suppression enabled, “No” if it is known that the far-end does not have silence suppression enabled, or “No data” if it is not initially known whether the far-end has silence suppression enabled. However, RTP or SRTP sequence numbers (see 96x1H-IPI.5.1.900) will be used, if necessary, to determine whether the far-end is doing silence suppression.
Packet Loss
A decimal percentage or “No data”. Late and out-of-sequence packets will be counted as lost if they are discarded. Packet(s) will not be counted as lost until a subsequent packet is received and the loss is confirmed through the use of the RTP or SRTP sequence number.
Packetization Delay
An integer number of milliseconds or “No data”. The value will reflect the nominal number of milliseconds of data in received audio packets (i.e., it will not reflect any “short” packets associated with silence suppression), and it will include any look-ahead delay associated with the codec.
An integer number of milliseconds or “No data”. The value will be one-half of the value that RTCP or SRTCP computes for the round-trip time (see 96x1H-IPI.5.1.900).
Network Jitter Compensation Delay
An integer number of milliseconds or “No data”. The value will reflect the average delay introduced by the telephone’s jitter buffer, as indicated by the parameter JMSEC (see 96x1H-IPI.5.1.900).
Approved for 6.4+
Local Network Quality
The LNQ internal parameter should be set to "0" if audio data is not available, otherwise
LNQ will be set to "6" if packet loss is < 1% and round-trip network delay is < 400 milliseconds and jitter compensation delay is < 80 milliseconds, otherwise
LNQ will be set to "5" if packet loss is < 2% and round-trip network delay is < 480 milliseconds and jitter compensation delay is < 100 milliseconds, otherwise
LNQ will be set to "4" if packet loss is < 3% and round-trip network delay is < 560 milliseconds and jitter compensation delay is < 120 milliseconds, otherwise
LNQ will be set to "3" if packet loss is < 4% and round-trip network delay is < 640 milliseconds and jitter compensation delay is < 160 milliseconds, otherwise
LNQ will be set to "2" if packet loss is < 5% and round-trip network delay is < 720 milliseconds and jitter compensation delay is < 200 milliseconds, otherwise
LNQ will be set to "1".
(see 96x1COPS.2.1.100 in [7.1-4].)
Note:
The received audio coding may be based on either H.323 signaling or on information in the RTP header (see 96x1H-IPI.5.1.900).
Note:
If each packet contains 10ms of audio, the loss of one packet in 5 seconds is 0.2%, so that is the minimum that can be measured. With a 10ms packet size over an interval of 5 seconds, <1% loss is up to 5 packets, <5% loss is up to 25 packets, <10% loss is up to 50 packets, etc. For a 30ms packet size, the loss of one packet in 5 seconds is 0.6%, so <1% loss is up to 1 packet, <5% loss is up to 8 packets, <10% loss is up to 16 packets, etc.
Note:
The Local Network Quality is termed this way because it only characterizes network performance between the telephone and the far-end RTP/RTCP termination. However, if the RTP/RTCP terminates on a conferencing bridge or on a gateway (especially one that does audio transcoding), the quality perceived by the user could be quite a bit worse than is indicated by this metric.
Rationale:
This requirement is intended to standardize the types of audio information presented to the user, even if different telephone models with different display capabilities don’t display all of the information, or if they display it in different formats (e.g., text vs. graphics).
Packetization delay is included as a network delay because it is sometimes added by network gateways, and even when it is added by the far-end endpoint, it only exists because a packet network is being used. The comparable number for a circuit-switched network would be zero (to the closest millisecond).
Delay due to media encryption is not currently included because the current algorithm only adds about 1 msec of delay. In the future, if more secure algorithms are used that add additional delay, it should be included.
