Technical Summary
The document defines RTSP version 2.0 which obsoletes RTSP version 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).
Working Group Summary
The document has been work in progress for an extended period of time dating back to 2002. Earlier versions saw decent WG participation however the later versions have primarily been driven by the document authors with limited overall discussion in the group, especially towards the end of the process. There are no known issues or major discussion points, and there has been no indication of lack of consensus in the WG.
Document Quality
The document has been reviewed in detail several times after WGLC and in preparation for the publication request and the authors have made several updates as a result of those. The document is considered to be of high quality at this point.
There is one known implementation of the specification, and many of the extensions compared to RTSP 1.0 have been implemented separately as well.
A Media type review was done for "text/parameters". The review thread can be found at: http://www.ietf.org/mail-archive/web/ietf-types/current/msg01656.html
Personnel
Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo
RFC Editor's Note:
Section 2 of this document and its subsections provide "an informative overview
of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high
level understanding". As such, it's very important that it be clear and well
written. Some reviewers have found the English to be difficult. Please take
an especially critical pen to this section, making sure that the grammar and
usage are correct, and that the language is clear.
Please make this change:
OLD
C.1.6.3. Bit-rate adaption
RTCP Receiver reports and any additional feedback from the client
MUST be used to adapt the bit-rate used over the transport for all
cases when RTP is sent over UDP. An RTP sender without reserved
resources MUST NOT use more than its fair share of the available
resources. This can be determined by comparing on short to medium
term (some seconds) the used bit-rate and adapt it so that the RTP
sender sends at a bit-rate comparable to what a TCP sender would
achieve on average over the same path.
To ensure that the implementation's adaptation mechanism has a well
defined outer envelope, all implementations using a non-congestion
controlled unicast transport protocol, like UDP, MUST implement
Multimedia Congestion Control: Circuit Breakers for Unicast RTP
Sessions [I-D.ietf-avtcore-rtp-circuit-breakers].
NEW
C.1.6.3. Bit-rate adaptation
RTCP Receiver reports and any additional feedback from the client
MUST be used to adapt the bit-rate used over the transport for all
cases when RTP is sent over UDP. An RTP sender without reserved
resources MUST NOT use more than its fair share of the available
resources. This can be determined by comparing on short to medium
term (some seconds) the used bit-rate and adapt it so that the RTP
sender sends at a bit-rate comparable to what a TCP sender would
achieve on average over the same path.
To ensure that the implementation's adaptation mechanism has a well
defined outer envelope, all implementations using a non-congestion
controlled unicast transport protocol, like UDP, MUST implement
congestion control. A baseline safety against persistent congestion
is "Multimedia Congestion Control: Circuit Breakers for Unicast RTP
Sessions" [I-D.ietf-avtcore-rtp-circuit-breakers]. There is also
ongoing work on standard specifications for RTP/RTCP congestion
control in the IETF in the RMCAT WG. Implementers are strongly
encouraged adopt the latest usable work.