Real-Time Streaming Protocol Version 2.0
RFC 7826

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    mmusic mailing list <mmusic@ietf.org>,
    mmusic chair <mmusic-chairs@tools.ietf.org>
Subject: Protocol Action: 'Real Time Streaming Protocol 2.0 (RTSP)' to Proposed Standard (draft-ietf-mmusic-rfc2326bis-40.txt)

The IESG has approved the following document:
- 'Real Time Streaming Protocol 2.0 (RTSP)'
  (draft-ietf-mmusic-rfc2326bis-40.txt) as Proposed Standard

This document is the product of the Multiparty Multimedia Session Control
Working Group.

The IESG contact persons are Gonzalo Camarillo and Richard Barnes.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/


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.