RSVP will be supported for IPv4 audio connections only, as specified in IETF RFC 2205 [7.3-21a] and below.
RSVP will be used to request a reservation for each audio connection if and only if the value of the parameter RSVPCONT (see 96x1H-IPI.2.1.1400) is “1”. A reservation is requested when an RTP or SRTP audio connection is initially established, and the reservation is removed (if active) when the RTP or SRTP audio connection is terminated. If RSVPCONT is set to “0” after a reservation is established, the reservation will not be removed until the audio connection is terminated.
The refresh period R, which is also transmitted in TIME_VALUES objects (see RFC 2205, Section 3.1.2, p.34 and Appendix A.4, p.80) will be set to a value that is 1000 times greater than the value of the parameter RSVPRFRSH (see 96x1H-IPI.2.1.1400; R is in milliseconds and RSVPRFRSH is in seconds).
If a reservation attempt fails, the telephone will retry at intervals equal to the refresh interval if and only if the value of the parameter RSVPRTRY is “1”.
The FLOWSPEC requested in an Resv message (see RFC 2205, Section 1.2, p.8, and RFC 2210, Section 3.2, p.12) will be based on the value of the parameter RSVPPROF (see 96x1H-IPI.2.1.1400): “Guaranteed” if RSVPPROF is “0”, and “Controlled-Load” if RSVPPROF is “1”.
Note:
RSVP does not use a transport protocol, it is an Internet control protocol similar to ICMP
(see 96x1H-IPI.5.1.304).
Note:
Avaya RSVP usage is specified in [7.1-15].
Rationale:
Requirements 7 and 7.1 in Section 5.3.5.4.2 of UCR 2008 [7.8-1d] require that the Flow Label field not be used as described in RFC 2460 (IPv6) and that it be set to zero when originating a packet. Since the Flow Label value is obtained via RSVP, this implies that RSVP should not be supported for IPv6.
96x1H-IPI.5.1.400: User Datagram Protocol (UDP)
Approved
UDP will be supported as specified in IETF STD 6 (RFC 768) [7.3-5] and IETF STD 3 (RFC 1122) Section 4.1 [7.3-3a], and as further clarified below.
Port numbers used with UDP will be as specified below and as specified in H.323 requirements documents. Messages will not be transmitted to unspecified UDP destination ports. Unspecified UDP destination ports on the IP telephone will remain closed at all times.
Received packets (the IP telephone is the Destination):
A port number specified in the SLA test request message
SLMTEST
(if the value is even) or
SLMTEST – 1
(if the value is odd)
Transmitted SLA RTP test packets
96x1H-IPI.5.1.930
33434 - 33523
(starts with 33434, increments by 1 for each message sent,
3 messages per hop,
up to 30 hops)
SLMTEST + 1
(if the value is even) or
SLMTEST
(if the value is odd)
Transmitted SLA traceroute messages
96x1H-IPI.5.1.930
1719
an unused port number in the range from 49300 to 49309
H.323 RAS messages
Note #1:
RFC 768, p.1, states that “Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted.”
Note #2:
RTP and signaling protocol port numbers are determined by H.323 signaling. RFC 3550 Section 11 p.68, RFC 3551 Section 8 page 34, H.225 Annex A Section A.10 and H.225 Annex B Section B.7 all specify that RTP use an even port number and that the corresponding RTCP stream use the next higher (odd) port number. RFC 3551 Section 8 p.35 and H.225 Annex B Section B.7 both note that any such port pair may be used and that port numbers 5004 and 5005 have been registered as a default pair for use with the profile defined in that document. RFC 3550, Section 11, recommends that if an application is supplied with an odd number for use as an RTP port, that the application should use the next lower (even) number.
Note #4:
Some data networking equipment supports a quality of service (QOS) mechanism called ‘port selection’ by which packets with port numbers in a certain range are given priority over other packets. Because this range is not standardized, the telephone needs to be able to be told what port(s) to use.
Rationale:
The initial destination port used by IP telephones for traceroute (33434) was found in the Rationale to requirement [110406-410] in Issue 0.5 of COMPAS ID 110406. The UNIX implementation of traceroute uses an initial destination port number of 32768 logically ORed with the process id of the traceroute process because multiple instances of traceroute may be running simultaneously on UNIX and each must be able to distinguish its own responses.
96x1H-IPI.5.1.450: Traceroute
Approved
The ability to perform a traceroute will be supported as specified below.
Traceroute sends a sequence of UDP messages to a specified IP address. The initial destination port will be as specified in 96x1H-IPI.5.1.400, and the initial IPv4 Time-to-Live (TTL) or IPv6 Hop Limit field will have a value of 1.
Three messages will be sent for each ‘hop’ in the route. Each message for a hop will contain the same TTL or Hop Limit value but the destination port number will be incremented by one for each message sent.
If an ICMP Time Exceeded or Destination Unreachable message is received in response, the source IP address of the received message and the elapsed time between the sending of the UDP message and the receipt of the response will be saved for that hop. If more than one response is received, the saved elapsed time for that hop will be an average of the individual elapsed times.
If an ICMP Destination Unreachable message is received in response, no further messages will be sent.
If an ICMP Destination Unreachable message is not received in response within 3 seconds, the TTL or Hop Limit value will be incremented by one, and the destination port number will continue to be incremented by one for each message sent. Messages will be sent for the next hop if the TTL or Hop Limit value is not greater than 30. If the TTL or Hop Limit value is greater than 30, no further messages will be sent.
The process that initiates traceroute will be able to terminate it at any time.
Note:
There is no standard for traceroute. Implementations vary, and some use ICMP Echo (ping) messages instead of UDP messages, but customers are increasingly configuring their routers to block pings because they are also used in denial-of-service attacks.
Note:
Currently, traceroute may be invoked by CM (see 96x1Tel.6.1.300 in [7.1-6]) or by RTCP (see 93608-190 and 93608-195 in [7.1-13] or 120310-C-25 and 120310-C-25 in [7.1-14a]) when RTCP monitoring is enabled (see 96x1H-IPI.5.1.900) and for CNA tests (see 96x1H-IPI.5.1.920).
Note:
An ICMPv4 Time Exceeded message returns only the first 64 bits (8 octets) of the data portion of the UDP message (see p.6 of [7.3-4e]). The UNIX implementation includes a sequence number, a copy of the TTL value, and a timestamp as data.
Note:
The signaling or procedures for invoking and for reporting the results of the traceroute are system- or application-specific.
Rationale:
The intent of this requirement is to specify a single traceroute procedure to be supported by IP telephones.
The destination port number is incremented for each message sent in case the target IP device supports a port in this range. Trying several port numbers improves the chances of getting a Destination Unreachable response for one of the ports.
