A resolver for the Domain Name System (DNS) will be supported as specified in IETF STD 13 (RFCs 1034 and 1035) [7.3-11a,b], IETF STD 3 (RFC 1123) Sections 2.1, 2.2, 2.3 and 6.1 [7.3-3b], RFC 3596 (DNS Extensions to Support IP Version 6) [7.3-42g], and as further specified below.
Note:
Support of RFC 3596 is required by Requirement 33 in Section 5.3.5.4.10 of UCR 2008 [7.8-1d].
Approved
DNS will use UDP as a transport-layer protocol (see 96x1H-IPI.5.1.400), but messages received on the DNS UDP port will only be processed if they are received in response to a DNS message transmitted by the telephone.
The DNS resolver will return at most one IP address to the requesting application.
The DNS resolver will support both A (IPv4) and AAAA (IPv6) records. If IPv4-only operation is enabled (see 96x1H-IPI.5.1.300), only A records will be requested from the DNS server and returned to the requesting application. If IPv6-only operation is enabled, only AAAA records will be requested from the DNS server and returned to the requesting application. If IP dual-stack operation is enabled, both A and AAAA records will be requested from the DNS server, unless the application explicitly requests that only one type of address be returned.
If both A and AAAA records are returned by the DNS server, the IP address returned to the requesting application will be chosen 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.
Note:
The support of both A and AAAA records is required by Section 2.2 of RFC 4213 (Basic Transition Mechanisms for IPv6 Hosts and Routers) [7.3-42k], which is required by Requirement 1 in Section 5.3.5.4 of UCR 2008 [7.8-1d].
Approved
The DNS resolver will be used to attempt to obtain an IP address for a parameter value any time the value is not a valid ASCII-encoded IP address. DNS names in parameter values received via DHCP (see 96x1H-IPI.5.1.600) or a configuration file (see 96x1PKG.2.4.100 in [7.1-10]) will not be resolved until all of the values from that source have been processed.
Labels (separated by periods) in the value of the parameter DOMAIN (see 96x1H-IPI.2.1.900) will be appended to the QNAME in a DNS query when DNS names in parameter values are being resolved.
DOMAIN will not be used in resolving host names in URLs/URIs.
If the value of DNSSRVR (see 96x1H-IPI.2.1.900) does not contain at least one valid non-zero IP address, DNS will fail; otherwise, the first IP address in DNSSRVR will be used as the IP address to which DNS query messages will be sent. If DNSSRVR contains a list of IP addresses, each will be queried sequentially in the order given if a response is not received from the previous address on the list.
Note:
When a DNS name in a parameter value is resolved, the DNS name in the parameter value is not replaced by an ASCII dotted-decimal equivalent of the IP address.
Note:
The DOMAIN parameter is provided to allow shorter (potentially only host) names to be used as DNS names in parameter values. However, if a customer’s servers are located on different sub-domains, the sub-domain name(s) must be included with the host names in parameter values because only the common portion of the domain can be in DOMAIN. If DOMAIN is null, DNS names in parameter values must be fully qualified.
Note:
A domain name is an octet string of node labels with the highest-level node label at the right end of the string. Each node label may be up to 63 characters long. When displayed for or input by humans, node labels are separated by a period character (“.”). A Fully Qualified Domain Name (FQDN) includes all node labels up to the global top-level domain.
RFC 1034, Section 3.1, states that, by convention, domain name comparisons are done in a case-insensitive manner assuming an ASCII character set, and Section 3.5 states that node labels must start with a letter (A-Z, a-z), end with a letter or a digit (A-Z, a-z, 0-9), and have as interior characters only letters, digits and hyphens. Section 3.1 also identifies a domain name format to be used internally by software. This second representation eliminates the periods and precedes each node label with a single length octet, and terminates with a length octet of zero to represent the root domain. The software representation is therefore one octet longer than the human format if the human format ends in a period, or two octets longer if the human format does not end in a period, which is more common in practice. Since the total length of a domain name is specified to be 255 octets in software format, a human-format domain name would have a maximum length of 253 characters if it does not end in a period, and a maximum length of 254 characters if it does end in a period.
However, RFC 2181 [7.3-11e], Section 11, states that any binary string whatever can be used as the label of any DNS resource record, and that a full domain name is limited to 255 octets (including the separators) without distinguishing between human and software formats.
Note:
DNS can return multiple IP addresses for a single query. Each IP address is associated with the DNS name via an ‘A’ (IPv4 address) record in the DNS database. When a query is performed, all matching ‘A’ records are returned. ‘A’ records do not contain port numbers. A newer SRV record type has been defined (see RFC 2782, [7.3-11h]) that can specify IP addresses (or DNS names) and ports associated with services, but it is not known how widely SRV records are supported by customers’ DNS servers.
Rationale:
RFC 1123, Section 6.1.1 requires that a DNS resolver be implemented by every host. DNS is required to support the Web access application to resolve URLs into IP addresses, and it would be a waste to provide it for that application and not make it available for general use. Customers may be able to manage their IP addresses better and provide for load balancing and backup of servers by putting the DNS names of servers in the DHCP name=value pairs rather than fixed dotted-decimal values.
RFC 1035 p.32 and RFC 1123 pp.75-76 state that UDP is preferred for DNS queries.
DNS names in parameter values are not replaced by an ASCII dotted-decimal equivalent of the IP address when the DNS name is resolved because the DNS server may provide a different IP address the next time the name is resolved (for server relocation, load-balancing, fault-recovery or other reasons). However, the “INUSE” objects in the SNMP MIB always contain the numeric value of the IP address currently in use (see 96x1H-IPI.5.1.1100).
Since DNS queries must contain a Fully Qualified Domain Name, DOMAIN is provided to help mitigate limitations in parameter value lengths (see Section 2.1) and limitations in DHCP message and option lengths (see 96x1H-IPI.5.1.600) imposed by the standard or by specific server implementations.
DNS names in parameter values received via DHCP or a configuration will not be resolved until all of the values from that source have been processed to prevent values received before a new setting of DOMAIN from using a previous value of DOMAIN.
96x1H-IPI.5.1.900: Real-Time Transport Protocol (RTP), Real-Time Transport Control Protocol (RTCP) and Secure RTP/RTCP (SRTP/SRTCP)
Approved
RTP and RTCP will be supported as specified in RFC 3550 [7.3-22d],
RTCP as further specified in Avaya RTCP Requirements [7.1-13], and both as further specified below.
RTP payload types and encodings will be supported as specified in RFC 3551 [7.3-22e].
Note:
RFC 3551 covers G.711, G.722, G.726 and G.729.
Approved
Forward Error Correction (FEC, e.g., as specified in RFC 2733 [7.3-22a]) will not be supported.
AES media encryption will be supported as specified in [7.1-18] if and only if the value of ALLOW_MEDIA_ENCRYPTION is “1”.
Note:
AES media encryption was an Avaya-proprietary precursor to SRTP.
Approved
SRTP and SRTCP will be supported as specified in RFC 3711 [7.3-22f], and as further specified below, if and only if the value of ALLOW_MEDIA_ENCRYPTION is “1”.
Note:
Support of the following are mandatory per the cited section of RFC 3711:
AES-CM-128 (AES Counter Mode with a 128-bit key length) and NULL encryption (Section 5),
HMAC-SHA1 message authentication (Section 5), and
authenticated SRTCP (Section 3) with an 80-bit authentication tag (Section 5.2),
AES-CM-128 PRF key derivation (Section 5.3).
Approved
The following optional capabilities of SRTP and SRTCP will be supported:
authenticated or unauthenticated SRTP (see Section 3.1)
shared master keys for SRTP and SRTCP (see Section 3.2.1)
replay protection for both SRTP and SRTCP with a window size of 64 (see Section 3.3.2)
authentication tag length of 80 or 32 bits for SRTP (see Sections 5.2 and 7.5).
The following optional capabilities of SRTP and SRTCP will not be supported:
encryption of SRTCP (see Section 3.4)
the f8 mode of the AES-128 encryption algorithm (see Section 4.1.2)
re-keying via a key derivation rate (see Section 4.3.1)
re-keying via the MKI (Master Key Identifier) or index range (see Section 8.1)
non-default FEC ordering (see Section 10).
Note:
The use of SRTP/SRTCP (vs. RTP/RTCP) and the associated key distribution and management is specified by 96x1Tel.2.1.1200 in [7.1-6].
Rationale:
The optional SRTP and SRTCP capabilities that are listed as not supported are primarily due to lack of support by CM and media gateways; see Sections 2.4.5 and 2.4.6 of [7.1-26].
Approved
RTP, RTCP, SRTP and SRTCP will use UDP (see 96x1H-IPI.5.1.400) as a transport-layer protocol.
Audio data will be accumulated from the telephone’s transducers and will be transmitted via RTP or SRTP to the IP address indicated by the parameter FEIPADD (see 96x1H-IPI.2.1.1400'>96x1H-IPI.2.1.1400) and to the UDP port indicated by the parameter FEPORT (see 96x1H-IPI.2.1.1400 and 96x1H-IPI.5.1.400) only if the telephone is off-hook, mute is not activated, and the value of FEIPADD is not null. FEIPADD will be set to null if the telephone goes on-hook.
Audio data will be accumulated in a buffer until the amount of data is greater than or equal to the value of the parameter TMSEC (see 96x1H-IPI.2.1.1400), at which time it will be transmitted. The transmit buffer will be able to accommodate up to at least 60 msec of audio data. Transmitted audio will be encoded according to the codec specified by the parameter CODECT (see 96x1H-IPI.2.1.1400). Audio data will stop being accumulated and the transmit buffer will be emptied when the telephone goes on-hook, when mute is activated, or when FEIPADD is set to null.
Rationale:
TMSEC is measured in milliseconds rather than in octets because different codecs (and even a single codec doing silence suppression) may use a different number of octets to encode the same amount of audio.
Approved
For transmission:
the version number will be 2;
the padding bit will be 0;
the extension bit will be 0;
the CC field (CSRC count) will be 0;
the marker bit will be set to 0, except when a payload contains the first non- silence frame after a
silence interval (whether or not SID (Silence Insertion Descriptor) frames were sent during the interval), in which case it will be set to 1;
the payload type code will be as specified below;
the sequence number will be incremented by one for each RTP data packet actually sent; and
whether or not audio packets are transmitted (i.e., even if silence is being suppressed).
Note:
For codecs that sample at 8000 Hz (such as G.711, G.726 and G.729), the timestamp will be incremented by one ‘tick’ every 125 microseconds, resulting in timestamps that differ by 80 ticks for two successive RTP data packets that each contain 10 milliseconds of audio data.
Rationale:
The timestamp must be incremented based on the sampling rate because some RTP implementations (such as Microsoft NetMeeting) will discard received audio if the timestamp is not incremented in this manner.
Note:
Section 4.5.2 of RFC 3551 [7.3-22e] specifies that even though the sampling rate for G.722 is 16,000 Hz, the RTP clock rate for G.722 is 8000 Hz, resulting in two samples (a sample-pair) for every ‘tick’, due to an error in the earlier RFC 1890.
Approved
Audio received via RTP or SRTP will be regenerated through the appropriate audio transducer if and only if the telephone is off-hook and if the IP datagrams in which the RTP or SRTP is received are received on the UDP port indicated by the value of the parameter PORTAUD (see 96x1H-IPI.2.1.1400 and 96x1H-IPI.5.1.400) and if they have a nonzero Source Address equal to the value of the parameter FEIPADD. Received audio from any IP Source Address other than FEIPADD will be discarded. All received RTP and SRTP will be discarded when the telephone is on-hook or when the value of FEIPADD is null.
On reception:
if the version number is not 2, the packet will be discarded;
the marker bit will be ignored;
a change in the SSRC will reset the jitter buffer and will reset the roll-over counter used by media
encryption algorithms;
the timestamp will be used in the jitter calculation;
if the received payload type is not supported, the payload will be discarded;
if the received payload type is supported, the specified codec will be used to decode the received
audio data, otherwise the payload will be discarded; and
the sequence number will be used to detect lost (“erased”) packets so that the codec may invoke its
“error concealment strategy” (see 96x1H-IPI.5.1.1000). If a packet is received with a sequence number that precedes a sequence number of a packet that has already been processed (or for which an “erasure” has already been indicated to the codec), the payload will be discarded. If a packet is received with a sequence number that precedes a sequence number for a packet that has already been received but not yet processed, the payload will be inserted into the appropriate place in the receive buffer.
A dynamic jitter buffer (i.e., one that automatically increases and decreases the amount of buffered audio data based on the detected variation in packet arrival) will be supported for received audio packets. The jitter buffer will be able to accommodate up to at least 200 milliseconds of audio data. Approximately every 5 seconds, the average delay introduced by the jitter buffer (in integer milliseconds) will be stored in the parameter JMSEC (see 96x1H-IPI.2.1.200).
Rationale:
RFC 3551, Section 4.2, states that, “A receiver should accept packets representing between 0 and 200 ms of audio data.”
Approved
“Shuffling” of the transmitted and received audio streams during a call will be supported when a new non-null value of FEIPADD is established and/or a new codec is specified “on the fly”. Transmission to the new address will begin immediately, and the receive buffer will be emptied of audio data from the old IP address before the first packet is accumulated from the new address. A delay of up to 100 msec may occur if a new codec is specified.
Only a single RTP or SRTP packet header will be transmitted per UDP datagram, even if multiple codec frames are being transmitted at the same time.
Note:
Some codecs (such as G.723.1 and G.729) encode audio into fixed-sized frames. One or more frames may be transmitted per RTP packet. TMSEC indicates the minimum number of milliseconds of audio transmitted per packet whether frames are used or not. G.729 and G.723.1 are always transmitted in multiples of 10 msec and 30 msec, respectively.
Approved
The following payload types will be supported for transmission and reception, depending on the codec(s) supported (see 96x1H-IPI.5.1.1000):
Payload Type (PT) Code
RTP Profile Payload Encoding Name
Payload Contents
0
PCMU
G.711 mu-law
8
PCMA
G.711 A-law
9
G722
G.722
18
G729
G.729, G.729A or G.729B
A dynamic payload type code will also be supported for G.726A-32.
Dynamic payload type codes may also be supported for payloads as specified by H.323 signaling requirements.
Note:
Payload type codes are specified in RFC 3551, Tables 4 and 5 [7.3-22e]. Dynamically-assigned payload type codes are used for some audio codecs such as G.726, for video, and for sending of DTMF digits via RFC 2833 [7.3-29a,b]. Audio encrypted using AES media encryption [7.1-18] uses a dynamic payload type code, but audio encrypted by SRTP uses the same payload type code as unencrypted audio for the same codec.
Approved
RTCP will be supported as specified by Avaya RTCP Requirements (with RTP-MIB Additions) [7.1-13].
If the value of the parameter RTCPCONT (see 96x1H-IPI.2.1.1400) is “1”, RTCP will be transmitted to FEIPADD while an RTP audio stream is active, and SRTCP will be transmitted to FEIPADD while an SRTP audio stream is active. RTCP and SRTCP will have a flow rate (in seconds) as specified by the value of the parameter RTCPFLOW.
If the value of the parameter RTCPMON is a non-null unicast IPv4 address and if FEIPADD is an IPv4 address, RTCP packets will also be sent to that IP address, with a destination port number equal to the value of RTCPMONPORT, when RTCP or SRTCP is active (i.e., when RTCP or SRTCP is already being transmitted to FEIPADD).
Rationale:
RTCP is sent to RTCPMON even if SRTCP is being sent to FEIPADD because there is no key exchange between the telephone and the RTCP monitor.
Approved
If the value of RTCPCONT, RTCPFLOW, RTCPMON or RTCPMONPORT changes after an audio stream has become active, the new value is not required to take effect until after the current audio stream is terminated.
Traceroute tests invoked by RTCP monitoring will comply with 96x1H-IPI.5.1.450.
RTP and RTCP may also be activated by other explicitly specified procedures, which may or may not be affected by the values of RTCPCONT, RTCPFLOW, RTCPMON or RTCPMONPORT.
Note:
RTP and RTCP are used for call-associated audio streams (see H.323 requirements), and for non-call-associated CNA audio tests (see 96x1H-IPI.5.1.920). RTP is also used (without RTCP) for non-call-associated audio streams “pushed” to or “pulled” from the telephone’s audio transducers (see [7.1-6]), and RTCP is also used to calculate audio quality statistics (see 96x1H-IPI.5.1.950).
Rationale:
On-hook privacy is supported by not transmitting audio unless the phone goes off-hook. Forcing the “far-end” IP address to zero when the phone goes on-hook protects against a server that is slow to clear the “far-end” IP address and prevents the phone from transmitting to a “stale” address when it goes back off-hook.
