draft-ietf-mmusic-rfc2326bis-36.txt   draft-ietf-mmusic-rfc2326bis-37.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: March 15, 2014 R. Lanphier Expires: March 28, 2014 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
September 11, 2013 September 24, 2013
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-36 draft-ietf-mmusic-rfc2326bis-37
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2014. This Internet-Draft will expire on March 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 50 skipping to change at page 8, line 50
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 235 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 235
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 235 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 235
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 236 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 236
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 236 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 236
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 237 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 237
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 239 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 239
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 239 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 239
22.16. Media Type Registration for text/parameters . . . . . . 240 22.16. Media Type Registration for text/parameters . . . . . . 240
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 242 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 242
23.1. Normative References . . . . . . . . . . . . . . . . . . 242 23.1. Normative References . . . . . . . . . . . . . . . . . . 242
23.2. Informative References . . . . . . . . . . . . . . . . . 244 23.2. Informative References . . . . . . . . . . . . . . . . . 245
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 247 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 247
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 247 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 247
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 251 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 251
A.3. Secured Media Session for on Demand Content . . . . . . 253 A.3. Secured Media Session for on Demand Content . . . . . . 253
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 256 A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 256
A.5. Single Stream Container Files . . . . . . . . . . . . . 260 A.5. Single Stream Container Files . . . . . . . . . . . . . 260
A.6. Live Media Presentation Using Multicast . . . . . . . . 262 A.6. Live Media Presentation Using Multicast . . . . . . . . 262
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 263 A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 263
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 265 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 265
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 265 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 265
skipping to change at page 36, line 31 skipping to change at page 36, line 31
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server, or server to RTSP messages consist of requests from client to server, or server to
client, and responses in the reverse direction. Request (Section 7) client, and responses in the reverse direction. Request (Section 7)
and Response (Section 8) messages use a format based on the generic and Response (Section 8) messages use a format based on the generic
message format of RFC 2822 [RFC2822] for transferring bodies (the message format of RFC 5322 [RFC5322] for transferring bodies (the
payload of the message). Both types of messages consist of a start- payload of the message). Both types of messages consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the headers, and possibly the data of the message body. The end of the headers, and possibly the data of the message body. The
below ABNF [RFC5234] is for information and the formal message below ABNF [RFC5234] is for information and the formal message
specification is present in Section 20.2.2. specification is present in Section 20.2.2.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
skipping to change at page 153, line 16 skipping to change at page 153, line 16
allows "pre-expiration" of responses without storing separate allows "pre-expiration" of responses without storing separate
Expires values for each resource). Expires values for each resource).
A received message that does not have a Date header field MUST be A received message that does not have a Date header field MUST be
assigned one by the recipient if the message will be cached by that assigned one by the recipient if the message will be cached by that
recipient. An RTSP implementation without a clock MUST NOT cache recipient. An RTSP implementation without a clock MUST NOT cache
responses without revalidating them on every use. An RTSP cache, responses without revalidating them on every use. An RTSP cache,
especially a shared cache, SHOULD use a mechanism, such as NTP, to especially a shared cache, SHOULD use a mechanism, such as NTP, to
synchronize its clock with a reliable external standard. synchronize its clock with a reliable external standard.
The RTSP-date, a full date as specified by Section 3.3 of [RFC2822], The RTSP-date, a full date as specified by Section 3.3 of [RFC5322],
sent in a Date header SHOULD NOT represent a date and time subsequent sent in a Date header SHOULD NOT represent a date and time subsequent
to the generation of the message. It SHOULD represent the best to the generation of the message. It SHOULD represent the best
available approximation of the date and time of message generation, available approximation of the date and time of message generation,
unless the implementation has no means of generating a reasonably unless the implementation has no means of generating a reasonably
accurate date and time. In theory, the date ought to represent the accurate date and time. In theory, the date ought to represent the
moment just before the message body is generated. In practice, the moment just before the message body is generated. In practice, the
date can be generated at any time during the message origination date can be generated at any time during the message origination
without affecting its semantic value. without affecting its semantic value.
Note: The RTSP 2.0 date is defined as RFC 2822 format date. This Note: The RTSP 2.0 date is defined as RFC 5322 format date. This
format is more allowing than the RTSP 1.0 and earlier draft format is more allowing than the RTSP 1.0 and earlier draft
versions using RFC 1123 date format. Thus implementations should versions using RFC 1123 date format. Thus implementations should
use single spaces as recommended as separators and support use single spaces as recommended as separators and support
receiving the obsoleted identifiers. receiving the obsoleted identifiers.
18.22. Expires 18.22. Expires
The Expires message-header field gives a date and time after which The Expires message-header field gives a date and time after which
the description or media-stream should be considered stale. The the description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
skipping to change at page 206, line 30 skipping to change at page 206, line 30
m-subtype = extension-token / iana-token m-subtype = extension-token / iana-token
iana-token = token iana-token = token
m-parameter = m-attribute EQUAL m-value m-parameter = m-attribute EQUAL m-value
m-attribute = token m-attribute = token
m-value = token / quoted-string m-value = token / quoted-string
CSeq = "CSeq" HCOLON cseq-nr CSeq = "CSeq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date Date = "Date" HCOLON RTSP-date
RTSP-date = date-time ; RTSP-date = date-time ;
date-time = <As defined in RFC 2822> date-time = <As defined in RFC 5322>
Expires = "Expires" HCOLON RTSP-date Expires = "Expires" HCOLON RTSP-date
From = "From" HCOLON from-spec From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-REQ-URI / absolute-URI addr-spec = RTSP-REQ-URI / absolute-URI
absolute-URI = < As defined in RFC 3986> absolute-URI = < As defined in RFC 3986>
display-name = *(token LWS) / quoted-string display-name = *(token LWS) / quoted-string
from-param = tag-param / generic-param from-param = tag-param / generic-param
tag-param = "tag" EQUAL token tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ("*" / message-tag-list) If-Match = "If-Match" HCOLON ("*" / message-tag-list)
skipping to change at page 244, line 20 skipping to change at page 244, line 20
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
skipping to change at page 245, line 35 skipping to change at page 245, line 41
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
skipping to change at page 317, line 24 skipping to change at page 317, line 24
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already participating in the MMUSIC-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi,
Francisco Cortes, Elwyn Davies, Kelly Djahandari, Martin Dunsmuir, Francisco Cortes, Elwyn Davies, Kelly Djahandari, Martin Dunsmuir,
Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy
Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Grignon, Christian Groves, V. Guruprasad, Peter Haight, Mark Handley,
Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, Brad Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori,
Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders
Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Chris Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F.
Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Martti Mela, Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool,
David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli,
Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Igor Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi,
Plotnikov, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Igor Plotnikov, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David
Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John
Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker,
Stephan Wenger, Dale R. Worley, and Byungjo Yoon , and especially to Stephan Wenger, Dale R. Worley, and Byungjo Yoon , and especially to
Flemming Andreasen. Flemming Andreasen.
J.1. Contributors J.1. Contributors
The following people have made written contributions that were The following people have made written contributions that were
included in the specification: included in the specification:
 End of changes. 12 change blocks. 
20 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/