draft-ietf-mmusic-rfc2326bis-23.txt   draft-ietf-mmusic-rfc2326bis-24.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: September 9, 2010 R. Lanphier Expires: January 3, 2011 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
March 8, 2010 July 2, 2010
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-23 draft-ietf-mmusic-rfc2326bis-24
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 which is defined in RFC 2326. 1.0 which is 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
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 3, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Presentation Description . . . . . . . . . . . . . . . . 11 2.1. Presentation Description . . . . . . . . . . . . . . . . 13
2.2. Session Establishment . . . . . . . . . . . . . . . . . 12 2.2. Session Establishment . . . . . . . . . . . . . . . . . 14
2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15
2.4. Session Parameter Manipulations . . . . . . . . . . . . 15 2.4. Session Parameter Manipulations . . . . . . . . . . . . 17
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 15 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 17
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18
2.6. Session Maintenance and Termination . . . . . . . . . . 18 2.6. Session Maintenance and Termination . . . . . . . . . . 20
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 19 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 29
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 27 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 28 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 29 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31
4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 29 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 29 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 30 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32
4.9.1. Random Access and Seeking . . . . . . . . . . . . . 31 4.9.1. Random Access and Seeking . . . . . . . . . . . . . 33
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 31 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33
4.9.3. Content Modifications . . . . . . . . . . . . . . . 32 4.9.3. Content Modifications . . . . . . . . . . . . . . . 34
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 32 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 32 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 37 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 40 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 42 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 45 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 47 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 49 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 52 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 53 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 53 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 54 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 55 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 57
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 57 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 59
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 58 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 60
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 59 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 61
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 60 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 62
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 62 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.3.1. Changing Transport Parameters . . . . . . . . . . . 65 13.3.1. Changing Transport Parameters . . . . . . . . . . . 67
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 66 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 68
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 66 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 68
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 71 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 72
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 72 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 73
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 73 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 76
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 74 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 76
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 74 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 76
13.4.7. Playing Live with Recording . . . . . . . . . . . . 75 13.4.7. Playing Live with Recording . . . . . . . . . . . . 77
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 75 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 78
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 76 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 78
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 77 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 79
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 78 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 80
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 79 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 81
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 80 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 83 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 85
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 83 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 85
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 84 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 86
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 85 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 87
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 86 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 88
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 88 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 90
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 91 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 93
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 93 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 95
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 93 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 95
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 93 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 95
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 93 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 95
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 93 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 95
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 93 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 95
15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 94 15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 96
15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 94 15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 96
15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 94 15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 96
15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 94 15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 96
15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 95 15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 97
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 95 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 97
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 95 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 97
15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 95 15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 97
15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 96 15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 98
15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 96 15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 98
15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 96 15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 98
15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 96 15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 98
15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 96 15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 98
15.4.8. 407 Proxy Authentication Required . . . . . . . . . 97 15.4.8. 407 Proxy Authentication Required . . . . . . . . . 99
15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 97 15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 99
15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 97 15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 99
15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 97 15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 99
15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 98 15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 100
15.4.13. 413 Request Message Body Too Large . . . . . . . . . 98 15.4.13. 413 Request Message Body Too Large . . . . . . . . . 100
15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 98 15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 100
15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 98 15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 100
15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 98 15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 100
15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 98 15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 100
15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 99 15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 101
15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 99 15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 101
15.4.20. 455 Method Not Valid in This State . . . . . . . . . 99 15.4.20. 455 Method Not Valid in This State . . . . . . . . . 101
15.4.21. 456 Header Field Not Valid for Resource . . . . . . 99 15.4.21. 456 Header Field Not Valid for Resource . . . . . . 101
15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 99 15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 101
15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 99 15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 101
15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 99 15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 101
15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 99 15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 101
15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 100 15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 102
15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 100 15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 102
15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 100 15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 102
15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 100 15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 102
15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 100 15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 102
15.4.31. 470 Connection Authorization Required . . . . . . . 100 15.4.31. 470 Connection Authorization Required . . . . . . . 102
15.4.32. 471 Connection Credentials not accepted . . . . . . 101 15.4.32. 471 Connection Credentials not accepted . . . . . . 103
15.4.33. 472 Failure to establish secure connection . . . . . 101 15.4.33. 472 Failure to establish secure connection . . . . . 103
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 101 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 103
15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 101 15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 103
15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 101 15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 103
15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 101 15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 103
15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 101 15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 103
15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 102 15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 104
15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 102 15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 104
15.5.7. 551 Option not supported . . . . . . . . . . . . . . 102 15.5.7. 551 Option not supported . . . . . . . . . . . . . . 104
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 103 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 105
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 113 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 115
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 113 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 115
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 116
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 117
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 118
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 116 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 118
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 116 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 118
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 117 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 119
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 117 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 119
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 120
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 120 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 122
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 121 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 123
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 122 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 124
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 122 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 124
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 123 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 125
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 123 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 125
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 124 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 126
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 124 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 126
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 124 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 126
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 127
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 126 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 128
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 127 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 129
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 129
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 127 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 130
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 128 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 130
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 129 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 131
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 129 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 131
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 129 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 132
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 131 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 134
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 132 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 132 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 135
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 133 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 135
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 136
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 134 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 136
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 134 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 136
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 135 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 137
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 138
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 139
16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 138 16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 140
16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 139 16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 141
16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 139 16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 141
16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 140 16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 142
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 140 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 143
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 143 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 145
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 144 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 146
16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148
16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 146 16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 148
16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 147 16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 149
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 148 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 150
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 148 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 150
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 149 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 151
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 149 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 151
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 156 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 158
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 156 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 158
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 157 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 159
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 157 16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 160
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 158 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 160
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 160 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 162
17.2. Multiplexing and Demultiplexing of Messages . . . . . . 161 17.2. Multiplexing and Demultiplexing of Messages . . . . . . 163
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 162 18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 164
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 164 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 166
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 164 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 166
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 164 18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 166
18.1.4. Rules for When to Use Message Body Tags and 18.1.4. Rules for When to Use Message Body Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 166 Last-Modified Dates . . . . . . . . . . . . . . . . 168
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 168 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 170
18.2. Invalidation After Updates or Deletions . . . . . . . . 168 18.2. Invalidation After Updates or Deletions . . . . . . . . 170
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 170 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 172
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 170 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 172
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 170 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 172
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 171 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 173
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 172 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 174
19.3.2. User approved TLS procedure . . . . . . . . . . . . 173 19.3.2. User approved TLS procedure . . . . . . . . . . . . 175
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 176 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 178
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 178 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 180
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 178 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 180
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 181 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 183
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 185 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 187
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 194 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 196
21. Security Considerations . . . . . . . . . . . . . . . . . . . 195 21. Security Considerations . . . . . . . . . . . . . . . . . . . 197
21.1. Remote denial of Service Attack . . . . . . . . . . . . 197 21.1. Remote denial of Service Attack . . . . . . . . . . . . 199
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 199 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 199 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 201
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 199 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 201
22.1.2. Registering New Feature-tags with IANA . . . . . . . 200 22.1.2. Registering New Feature-tags with IANA . . . . . . . 202
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 200 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 202
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 200 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 202
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 200 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 202
22.2.2. Registering New Methods with IANA . . . . . . . . . 201 22.2.2. Registering New Methods with IANA . . . . . . . . . 203
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 201 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 203
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 201 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 203
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 201 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 203
22.3.2. Registering New Status Codes with IANA . . . . . . . 202 22.3.2. Registering New Status Codes with IANA . . . . . . . 204
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 202 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 204
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 202 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 204
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 202 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 204
22.4.2. Registering New Headers with IANA . . . . . . . . . 202 22.4.2. Registering New Headers with IANA . . . . . . . . . 204
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 203 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 205
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 203 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 205
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 203 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 205
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 204 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 206
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 204 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 206
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 205 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 207
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 205 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 207
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 205 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 207
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 206 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 208
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 206 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 208
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 206 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 206 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 208
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 207 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 209
22.9. Range header formats . . . . . . . . . . . . . . . . . . 207 22.9. Range header formats . . . . . . . . . . . . . . . . . . 209
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 207 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 207 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 209
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 207 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 209
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 208 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 210
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 208 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 210
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 208 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 210
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 208 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 210
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 208 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 209 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 211
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 209 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 211
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 209 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 211
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 209 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 211
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 209 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 211
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 210 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 212
22.13. Transport Header Registries . . . . . . . . . . . . . . 210 22.13. Transport Header Registries . . . . . . . . . . . . . . 212
22.13.1. Transport Protocol Specification . . . . . . . . . . 210 22.13.1. Transport Protocol Specification . . . . . . . . . . 212
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 211 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 213
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 212 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 214
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 212 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 214
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 212 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 214
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 213 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 215
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 214 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 216
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 215 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 217
22.16. Media Type Registration for text/parameters . . . . . . 216 22.16. Media Type Registration for text/parameters . . . . . . 218
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 218 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 220
23.1. Normative References . . . . . . . . . . . . . . . . . . 218 23.1. Normative References . . . . . . . . . . . . . . . . . . 220
23.2. Informative References . . . . . . . . . . . . . . . . . 220 23.2. Informative References . . . . . . . . . . . . . . . . . 222
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 223 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 225
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 223 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 225
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 227 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 229
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 229 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 231
A.4. Single Stream Container Files . . . . . . . . . . . . . 233 A.4. Single Stream Container Files . . . . . . . . . . . . . 235
A.5. Live Media Presentation Using Multicast . . . . . . . . 235 A.5. Live Media Presentation Using Multicast . . . . . . . . 237
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 236 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 238
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 238 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 240
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 238 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 240
B.2. State variables . . . . . . . . . . . . . . . . . . . . 238 B.2. State variables . . . . . . . . . . . . . . . . . . . . 240
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 238 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 240
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 239 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 241
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 245 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 247
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 245 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 247
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 245 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 247
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 245 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 247
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 246 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 248
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 247 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 249
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 247 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 249
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 247 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 249
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 248 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 250
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 249 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 251
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 249 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 251
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 253 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 255
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 257 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 259
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 259 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 261
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 259 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 261
C.7. Maintaining NPT synchronization with RTP timestamps . . 259 C.7. Maintaining NPT synchronization with RTP timestamps . . 261
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 259 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 261
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 259 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 261
C.10. Usage of SSRCs and the RTCP BYE Message During an C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 259 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 261
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 260 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 262
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 261 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 263
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 261 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 263
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 261 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 263
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 262 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 264
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 263 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 265
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 263 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 265
D.1.5. Directionality of media stream . . . . . . . . . . . 263 D.1.5. Directionality of media stream . . . . . . . . . . . 265
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 264 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 266
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 265 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 267
D.1.8. Connection Information . . . . . . . . . . . . . . . 265 D.1.8. Connection Information . . . . . . . . . . . . . . . 267
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 265 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 267
D.2. Aggregate Control Not Available . . . . . . . . . . . . 266 D.2. Aggregate Control Not Available . . . . . . . . . . . . 268
D.3. Aggregate Control Available . . . . . . . . . . . . . . 266 D.3. Aggregate Control Available . . . . . . . . . . . . . . 268
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 267 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 269
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 268 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 270
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 269 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 271
E.1. On-demand Playback of Stored Content . . . . . . . . . . 269 E.1. On-demand Playback of Stored Content . . . . . . . . . . 271
E.2. Unicast Distribution of Live Content . . . . . . . . . . 270 E.2. Unicast Distribution of Live Content . . . . . . . . . . 272
E.3. On-demand Playback using Multicast . . . . . . . . . . . 271 E.3. On-demand Playback using Multicast . . . . . . . . . . . 273
E.4. Inviting an RTSP server into a conference . . . . . . . 271 E.4. Inviting an RTSP server into a conference . . . . . . . 273
E.5. Live Content using Multicast . . . . . . . . . . . . . . 272 E.5. Live Content using Multicast . . . . . . . . . . . . . . 274
Appendix F. Text format for Parameters . . . . . . . . . . . . . 274 Appendix F. Text format for Parameters . . . . . . . . . . . . . 276
Appendix G. Requirements for Unreliable Transport of RTSP . . . 275 Appendix G. Requirements for Unreliable Transport of RTSP . . . 277
Appendix H. Backwards Compatibility Considerations . . . . . . . 277 Appendix H. Backwards Compatibility Considerations . . . . . . . 279
H.1. Play Request in Play mode . . . . . . . . . . . . . . . 277 H.1. Play Request in Play State . . . . . . . . . . . . . . . 279
H.2. Using Persistent Connections . . . . . . . . . . . . . . 277 H.2. Using Persistent Connections . . . . . . . . . . . . . . 279
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 278 Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 280
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 279 Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 281
J.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 279 J.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 281
J.2. Detailed List of Changes . . . . . . . . . . . . . . . . 280 J.2. Detailed List of Changes . . . . . . . . . . . . . . . . 282
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 287 Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 289
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 287 K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 289
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 289 Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 291
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 290 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 292
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, as you know it from "network remote control" for multimedia servers, similar to the
your TV set. remote control for a DVD player.
The protocol operates between RTSP 2.0 clients and servers, but also The protocol operates between RTSP 2.0 clients and servers, but also
supports the usage of proxies placed between clients and servers. supports the usage of proxies placed between clients and servers.
Clients can request information about streaming media from servers, Clients can request information about streaming media from servers by
by asking for a description of the media or use media description asking for a description of the media or use media description
provided externally. Then the media delivery protocol is used to provided externally. The media delivery protocol is used to
establish the media streams described by the media description. establish the media streams described by the media description.
Clients can then request to play out the media, pause it, or stop it Clients can then request to play out the media, pause it, or stop it
completely, as known from a regular DVD player remote control. The completely, as known from a regular DVD player remote control. The
requested media can consist of multiple audio and video streams that requested media can consist of multiple audio and video streams that
are delivered as a time-synchronized streams from servers to clients. are delivered as a time-synchronized streams from servers to clients.
RTSP 2.0 is an replacement of RTSP 1.0 [RFC2326] that obsoletes that RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] that obsoletes that
specification. This protocol is based on RTSP 1.0 but not backwards specification. This protocol is based on RTSP 1.0 but is not
compatible other than in the basic version negotiation mechanism. backwards compatible other than in the basic version negotiation
The changes are documented in Appendix J. There are many reasons why mechanism. The changes are documented in Appendix J. There are many
RTSP 2.0 can't be backwards compatible with RTSP 1.0 but some of the reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but
main ones are; that most header that needed to be extensible did not some of the main ones are:
define the allowed syntax preventing safe deployment of extensions;
the changed behavior of the PLAY method when received in playing
state; changed behavior of the extensibility model and its mechanism;
the change of syntax for some headers. The summary is that there are
so many small details that changing version become necessary to
enable clarification and consistent behavior.
This document is structured in the way that it begins with an o Most headers that needed to be extensible did not define the
overview of the protocol operations and its functions in an informal allowed syntax, preventing safe deployment of extensions;
way. Then a set of definitions of used terms and document
conventions is introduced. Then comes the actual protocol o The changed behavior of the PLAY method when received in Play
specification. In the appendix some functionality that isn't core state;
RTSP defined, but still important to enable some usage, like RTP
o Changed behavior of the extensibility model and its mechanism;
o The change of syntax for some headers.
In summary, there are so many small details that changing version
become necessary to enable clarification and consistent behavior.
This document is structured as follows. It begins with an overview
of the protocol operations and its functions in an informal way.
Then a set of definitions of used terms and document conventions is
introduced. It is followed by the actual protocol specification. In
the appendix some functionality that isn't core RTSP, but still
important to enable some usage, is defined. RTP usage is defined in
Appendix C and SDP usage with RTSP Appendix D, making these two Appendix C and SDP usage with RTSP Appendix D, making these two
appendixes mandatory. This is followed by a number of informational appendixes mandatory. This is followed by a number of informational
parts discussing the changes, use cases, different considerations or parts discussing the changes, use cases, different considerations or
motivations. motivations.
2. Protocol Overview 2. Protocol Overview
This section provides a informative overview of the different This section provides a informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about considered use
cases for RTSP see Appendix E. cases for RTSP see Appendix E.
RTSP 2.0 is a bi-directional request and response protocol that first RTSP 2.0 is a bi-directional request and response protocol that first
establish a context including content resources (the media) and then establishes a context including content resources (the media) and
controls the delivery of these content resources from the server to then controls the delivery of these content resources from the server
the client. RTSP has three fundamental parts of interest: Session to the client. RTSP has three fundamental parts: Session
Establishment, Media Delivery Control, and an extensibility model Establishment, Media Delivery Control, and an extensibility model
described below. The protocol is based on some assumptions on described below. The protocol is based on some assumptions about
existing functionality to provide a complete solution for client existing functionality to provide a complete solution for client
controlled real-time media delivery. controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol and version and the line that identifies the method, the protocol and version and the
resource to act on. Following the method line follows a number of resource to act on. Following the method line are a number of RTSP
RTSP headers. This part is ended by two consecutive carriage return headers. This part is ended by two consecutive carriage return line
line feed (CRLF) character pairs. The message body if present feed (CRLF) character pairs. The message body if present follows the
follows the two CRLF and the bodies length are described by a message two CRLF and the body's length are described by a message header.
header. RTSP responses are similar, but start with a response line RTSP responses are similar, but start with a response line with the
with protocol and version, followed by a status code and a reason protocol and version, followed by a status code and a reason phrase.
phrase. RTSP messages are sent over a reliable transport protocol RTSP messages are sent over a reliable transport protocol between the
between the client and server. RTSP 2.0 requires clients and servers client and server. RTSP 2.0 requires clients and servers to
to implement TCP, and TLS over TCP, as mandatory transports for RTSP implement TCP, and TLS over TCP, as mandatory transports for RTSP
messages. messages.
2.1. Presentation Description 2.1. Presentation Description
RTSP exists to provide access to multi-media presentations and RTSP exists to provide access to multi-media presentations and
content, but tries to be agnostic to the media type or the actual content, but tries to be agnostic about the media type or the actual
media delivery protocol that is used. To enable a client to media delivery protocol that is used. To enable a client to
implement a complete system, an RTSP-external mechanism for implement a complete system, an RTSP-external mechanism for
describing the presentation and the delivery protocol(s) is used. describing the presentation and the delivery protocol(s) is used.
RTSP assumes that this description is either delivered completely out RTSP assumes that this description is either delivered completely out
of bands or as a data object in the response to a client's request of bands or as a data object in the response to a client's request
using the DESCRIBE method (Section 13.2). using the DESCRIBE method (Section 13.2).
Parameters that commonly have to be included in the Content Parameters that commonly have to be included in the Content
Description are the following: Description are the following:
o Number of media streams o Number of media streams
o The resource identifier for each media stream/resource that is to o The resource identifier for each media stream/resource that is to
be controlled by RTSP be controlled by RTSP
o The protocol that each media stream is to be delivered over o The protocol that each media stream is to be delivered over
o Transport protocol parameters that are not negotiated or varies o Transport protocol parameters that are not negotiated or vary with
with each client each client
o Media encoding information enabling client to correctly decode it o Media encoding information enabling a client to correctly decode
upon reception it upon reception
o An aggregate control resource identifier o An aggregate control resource identifier
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
resources and aggregates under common control. resources and aggregates under common control.
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for Content Description for Content Description
2.2. Session Establishment 2.2. Session Establishment
The RTSP client can request the establishment of an RTSP session The RTSP client can request the establishment of an RTSP session
after having used the presentation description to determine which after having used the presentation description to determine which
media streams are available, and also which media delivery protocol media streams are available, and also which media delivery protocol
is used and their particular resource identifiers. The RTSP session is used and their particular resource identifiers. The RTSP session
is a common context between the client and the server that consist of is a common context between the client and the server that consist of
one or more media resource that is to be under common media delivery one or more media resources that are to be under common media
control. delivery control.
The client creates an RTSP session by sending an request using the The client creates an RTSP session by sending a request using the
SETUP method (Section 13.3) to the server. In the SETUP request the SETUP method (Section 13.3) to the server. In the SETUP request the
client also includes all the transport parameter necessary to enable client also includes all the transport parameters necessary to enable
the media delivery protocol to function in the "Transport" header the media delivery protocol to function in the "Transport" header
(Section 16.52). This includes parameters that are pre-established (Section 16.52). This includes parameters that are pre-established
by the presentation description but necessary for any middlebox to by the presentation description but necessary for any middlebox to
correctly handle the media delivery protocols. The Transport header correctly handle the media delivery protocols. The Transport header
in a request may contain multiple alternatives for media delivery in in a request may contain multiple alternatives for media delivery in
a prioritized list, which the server can select from. These a prioritized list, which the server can select from. These
alternatives are typically based on information in the content alternatives are typically based on information in the content
description. description.
The server determines if the media resource is available upon The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is session context is created and the relevant parameters and state is
stored. An identifier is created for the RTSP session and included stored. An identifier is created for the RTSP session and included
in the response in the Session header (Section 16.47). The SETUP in the response in the Session header (Section 16.47). The SETUP
response includes a Transport header that specifies which of the response includes a Transport header that specifies which of the
alternatives that have been selected and relevant parameters. alternatives has been selected and relevant parameters.
A SETUP request that references an existing RTSP session but A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media identifies a new media resource is a request to add that media
resource under common control with the already present media resource under common control with the already present media
resources in an aggregated session. A client can expect this to work resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multi-media for all media resources under RTSP control within a multi-media
content. However, aggregating resources from different content are content. However, aggregating resources from different content are
likely to be refused by the server. The RTSP session as aggregate is likely to be refused by the server. The RTSP session as aggregate is
referenced by the aggregate control URI, even if the RTSP session referenced by the aggregate control URI, even if the RTSP session
only contains a single media. only contains a single media.
To avoid an extra round trip in the session establishment of To avoid an extra round trip in the session establishment of
aggregated RTSP sessions, RTSP 2.0 supports pipelined requests, i.e., aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e.,
the client can send multiple requests back to back without waiting the client can send multiple requests back-to-back without waiting
first for the completion of any of them. The client uses client first for the completion of any of them. The client uses client-
selected identifier in the Pipelined-Requests header to instruct the selected identifier in the Pipelined-Requests header to instruct the
server to bind multiple requests together as if they included the server to bind multiple requests together as if they included the
session identifier. session identifier.
The SETUP response also provides additional information about the The SETUP response also provides additional information about the
established sessions in a couple of different headers. The Media- established sessions in a couple of different headers. The Media-
Properties header include a number of properties that apply for the Properties header includes a number of properties that apply for the
aggregate that is valuable when doing media delivery control and aggregate that is valuable when doing media delivery control and
configuring user interface. The Accept-Ranges header inform the configuring user interface. The Accept-Ranges header informs the
client about which range formats that the server supports with these client about which range formats that the server supports with these
media resources. The Media-Range header inform the client about the media resources. The Media-Range header inform the client about the
time range of the media currently available. time range of the media currently available.
2.3. Media Delivery Control 2.3. Media Delivery Control
After having established an RTSP session, the client can start After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are Start by controlling the media delivery. The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
method (Section 13.6). PLAY also allows for choosing the starting method (Section 13.6). PLAY also allows for choosing the starting
skipping to change at page 15, line 11 skipping to change at page 16, line 11
types, such as: on-demand, live, and live with simultaneous types, such as: on-demand, live, and live with simultaneous
recording. Even within these categories there are differences in how recording. Even within these categories there are differences in how
the content is generated and distributed, which affect how it can be the content is generated and distributed, which affect how it can be
accessed for playback. The properties applicable for the RTSP accessed for playback. The properties applicable for the RTSP
session are provided by the server in the SETUP response using the session are provided by the server in the SETUP response using the
Media-Properties header (Section 16.28). These are expressed using Media-Properties header (Section 16.28). These are expressed using
one or several independent attributes. A first attribute is Random one or several independent attributes. A first attribute is Random
Access, which expresses if positioning can be done, and with what Access, which expresses if positioning can be done, and with what
granularity. Another aspect is whether the content will change granularity. Another aspect is whether the content will change
during the lifetime of the session. While on-demand content will during the lifetime of the session. While on-demand content will
provided in its completeness from the beginning, a live stream being provided in full from the beginning, a live stream being recorded
recorded results in that the length of the accessible content grows results in the length of the accessible content growing as the
as the session goes on. There also exist content that is dynamically session goes on. There also exist content that is dynamically built
built by another protocol than RTSP and thus also changes in steps by another protocol than RTSP and thus also changes in steps during
during the session, but maybe not continuously. Furthermore, when the session, but maybe not continuously. Furthermore, when content
content is recorded, there are cases where not the complete content is recorded, there are cases where not the complete content is
is maintained, but, for example, only the last hour. All these maintained, but, for example, only the last hour. All these
properties result in the need for mechanisms that will be discussed properties result in the need for mechanisms that will be discussed
below. below.
When the client accesses on-demand content, that is possible to When the client accesses on-demand content that allows random access
perform random access in, the client can issue the PLAY request for in, the client can issue the PLAY request for any point in the
any point in the content between the start and the end. The server content between the start and the end. The server will deliver media
will deliver media from the closest random access point prior to the from the closest random access point prior to the requested point and
requested point and indicate that in its PLAY response. If the indicate that in its PLAY response. If the client issues a PAUSE,
client issues a pause the delivery will be halted and the point at the delivery will be halted and the point at which the server stopped
which the server stopped will be reported back in the response. The will be reported back in the response. The client can later resume
client can later resume by a PLAY request without a range header. by a sending PLAY request without a range header. When the server is
When the server is about to completed the PLAY request by delivering about to complete the PLAY request by delivering the end of the
the end of the content or the requested range the server will send a content or the requested range, the server will send a PLAY_NOTIFY
PLAY_NOTIFY request indicating this. request indicating this.
When playing live content with no extra functions, such as recording, When playing live content with no extra functions, such as recording,
the client will receive the live media from the server after having the client will receive the live media from the server after having
sent a PLAY request. Seeking in such content is not possible as the sent a PLAY request. Seeking in such content is not possible as the
server does not store it, but only forwards it from the source of the server does not store it, but only forwards it from the source of the
session. Thus delivery continues until the client sends a PAUSE session. Thus delivery continues until the client sends a PAUSE
request, tears down the session, or the content ends. request, tears down the session, or the content ends.
For live sessions that are being recorded the client will need to For live sessions that are being recorded the client will need to
keep track of how the recording progresses. Upon session keep track of how the recording progresses. Upon session
establishment the client will learn the current duration of the establishment the client will learn the current duration of the
recording from the Media-Range header. As the recording is ongoing recording from the Media-Range header. As the recording is ongoing
the content grows in direct relation to the passed time. Therefore, the content grows in direct relation to the passed time. Therefore,
each server's response to a PLAY request will contain the current each server's response to a PLAY request will contain the current
Media-Range header. The server should also send regularly every 5 Media-Range header. The server should also regularly send every 5
minutes the current media range in a PLAY_NOTIFY request. If the minutes the current media range in a PLAY_NOTIFY request. If the
live transmission ends, the server must send a PLAY_NOTIFY request live transmission ends, the server must send a PLAY_NOTIFY request
with the updated Media-Properties indicating that the content stopped with the updated Media-Properties indicating that the content stopped
being a recorded live session and instead become a on-demand content. being a recorded live session and instead become a on-demand content;
The request also contains the final media range. While the live the request also contains the final media range. While the live
delivery continues the client can request to play what is delivered delivery continues the client can request to play the current live
just now by using the NPT timescale symbol "now", or it can request a point by using the NPT timescale symbol "now", or it can request a
specific point in the available content by an explicit range request specific point in the available content by an explicit range request
for that point. If the requested point is outside of the available for that point. If the requested point is outside of the available
interval the server will adjust the position to the closest available interval the server will adjust the position to the closest available
point, i.e., either at the beginning or the end. point, i.e., either at the beginning or the end.
A special case of recording is, where the recording is not retained A special case of recording is that where the recording is not
longer than a specific time period, thus as the live delivery retained longer than a specific time period, thus as the live
continues the client can access any media within a moving window that delivery continues the client can access any media within a moving
covers for example "now" to "now" minus 1 hour. A client that pauses window that covers, for example, "now" to "now" minus 1 hour. A
on a specific point within the content may not be able to retrieve client that pauses on a specific point within the content may not be
the content anymore. If the client waits too long before resuming able to retrieve the content anymore. If the client waits too long
the pause point, the content may no longer be available. In this before resuming the pause point, the content may no longer be
case the pause point will be adjusted to the end of the available available. In this case the pause point will be adjusted to the end
media. of the available media.
2.4. Session Parameter Manipulations 2.4. Session Parameter Manipulations
A session may have additional state or functionality that effects how A session may have additional state or functionality that effects how
the server or client treats the session, content, how it functions, the server or client treats the session, content, how it functions,
or feedback on how well the session works. Such extensions are not or feedback on how well the session works. Such extensions are not
defined in this specification, but may be done in various extensions. defined in this specification, but may be done in various extensions.
RTSP has two methods for retrieving and setting parameter values on RTSP has two methods for retrieving and setting parameter values on
either the client or the server: GET_PARAMETER (Section 13.8) and either the client or the server: GET_PARAMETER (Section 13.8) and
SET_PARAMETER (Section 13.9). These methods carry the parameters in SET_PARAMETER (Section 13.9). These methods carry the parameters in
a message body of the appropriate format. One can also headers to a message body of the appropriate format. One can also use headers
query state with the GET_PARAMETER method. As an example, clients to query state with the GET_PARAMETER method. As an example, clients
needing to know the current Media-Range for a time-progressing needing to know the current media-range for a time-progressing
session can use the GET_PARAMETER method and include the media-range. session can use the GET_PARAMETER method and include the media-range.
Furthermore, synchronization information can be requested by using a Furthermore, synchronization information can be requested by using a
combination of RTP-Info and Range. combination of RTP-Info and Range.
RTSP 2.0 does not have a strong mechanism for providing negotiation RTSP 2.0 does not have a strong mechanism for providing negotiation
of which headers, or parameters and their formats, that can be used. of which headers, or parameters and their formats, that can be used.
However, responses will indicate request headers or parameters that However, responses will indicate request headers or parameters that
are not supported. A priori determination of what features are are not supported. A priori determination of what features are
available needs to be done through out-of-band mechanisms, like the available needs to be done through out-of-band mechanisms, like the
session description, or through the usage of feature tags session description, or through the usage of feature tags
skipping to change at page 17, line 6 skipping to change at page 18, line 6
2.5. Media Delivery 2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol The delivery of media to the RTSP client is done with a protocol
outside of RTSP and this protocol is determined during the session outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with establishment. This document specifies how media is delivered with
RTP over UDP, TCP or the RTSP control connection. Additional RTP over UDP, TCP or the RTSP control connection. Additional
protocols may be specified in the future based on demand. protocols may be specified in the future based on demand.
The usage of RTP as media delivery protocol requires some additional The usage of RTP as media delivery protocol requires some additional
information to function well. The PLAY responses contains information to function well. The PLAY response contains information
synchronization information to enable reliable and timely deliver of to enable reliable and timely deliver of how a client should
how a client should synchronize different sources in the different synchronize different sources in the different RTP sessions. It also
RTP sessions. It also provides a mapping between RTP timestamps and provides a mapping between RTP timestamps and the content time scale.
the content time scale. When the server want to notify the client When the server want to notify the client about the completion of the
about the completion of the media delivery, it sends a PLAY_NOTIFY media delivery, it sends a PLAY_NOTIFY request to the client. The
request to the client. The PLAY_NOTIFY request includes information PLAY_NOTIFY request includes information about the stream end,
about the stream end, including the last RTP sequence number for each including the last RTP sequence number for each stream, thus enabling
stream, thus enabling the client to empty the buffer smoothly. the client to empty the buffer smoothly.
2.5.1. Media Delivery Manipulations 2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP is to request content for a The basic playback functionality of RTSP enables delivery of a range
particular range to be delivered to the client in a pace that enables of requested content to the client at the pace intended by the the
playback as intended by the creator. However, RTSP can also content's creator. However, RTSP can also manipulate the delivery to
manipulate how this delivery is done to the client in two ways. the client in two ways.
Scale: The ratio of media content time delivered per unit playback Scale: The ratio of media content time delivered per unit playback
time. time.
Speed: The ratio of playback time delivered per unit of wallclock Speed: The ratio of playback time delivered per unit of wallclock
time. time.
Both affect the media delivery per time unit. However, they Both affect the media delivery per time unit. However, they
manipulate two independent time scales and the effects are possible manipulate two independent time scales and the effects are possible
to combine. to combine.
Scale is used for fast forward or slow motion control as it changes Scale is used for fast forward or slow motion control as it changes
the amount of content timescale that should be played back per time the amount of content timescale that should be played back per time
unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in unit. Scale > 1.0, means fast forward, e.g. Scale=2.0 results in
that 2 seconds of content is played back every second of playback. that 2 seconds of content is played back every second of playback.
Scale = 1.0 is the default value that is used if no Scale is Scale = 1.0 is the default value that is used if no Scale is
specified, i.e. playback at the contents original rate. Scale values specified, i.e., playback at the content's original rate. Scale
between 0 and 1.0 is providing for slow motion. Scale can be values between 0 and 1.0 is providing for slow motion. Scale can be
negative to allow for reverse playback in either regular pace (Scale negative to allow for reverse playback in either regular pace (Scale
= -1.0) or fast backwards (Scale < -1.0) or slow motion backwards = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards
(-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed. (-1.0 < Scale < 0). Scale = 0 is equal to pause and is not allowed.
In most cases the realization of scale means server side manipulation In most cases the realization of scale means server side manipulation
of the media to ensure that the client can actually play it back. of the media to ensure that the client can actually play it back.
These media manipulation and when they are needed are highly media These media manipulation and when they are needed are highly media-
type dependent. Lets exemplify with two common media types audio and type dependent. Lets exemplify with two common media types audio and
video. video.
It is very difficult to modify the playback rate of audio. A maximum It is very difficult to modify the playback rate of audio. A maximum
of 10-30% is possible by changing the pitch-rate of speech. Music of 10-30% is possible by changing the pitch-rate of speech. Music
goes out of tune if one tries to manipulate the playback rate by goes out of tune if one tries to manipulate the playback rate by
resampling it. This is a well known problem and audio is commonly resampling it. This is a well known problem and audio is commonly
muted or played back in short segments with skips to keep up with the muted or played back in short segments with skips to keep up with the
current playback point. current playback point.
For video is possible to manipulate the frame rate, although the For video is possible to manipulate the frame rate, although the
rendering capabilities are often limited to certain frame rates. rendering capabilities are often limited to certain frame rates.
Also the allowed bit-rates in decoding, the structured used in the Also the allowed bitrates in decoding, the structured used in the
encoding and its dependency between frames and other capabilities of encoding and the dependency between frames and other capabilities of
the rendering device limits the possible manipulations. Therefore the rendering device limits the possible manipulations. Therefore,
basic fast forward capabilities often is implemented by selecting the basic fast forward capabilities often are implemented by
certain sub-sets of frames. selecting certain subsets of frames.
Due to the media restrictions, the possible scale values are commonly Due to the media restrictions, the possible scale values are commonly
restricted to a limited set of possible scale ratios. To enable the restricted to the set of realizable scale ratios. To enable the
clients to select from the possible scale values, RTSP can signal the clients to select from the possible scale values, RTSP can signal the
supported Scale ratios for the content. To support aggregated or supported Scale ratios for the content. To support aggregated or
dynamic content, where this may change during the ongoing session and dynamic content, where this may change during the ongoing session and
dependent on the location within the content, a mechanism for dependent on the location within the content, a mechanism for
updating the media properties and the current used scale factor updating the media properties and the currently used scale factor
exist. exist.
Speed affects how much of the playback timeline that is delivered in Speed affects how much of the playback timeline is delivered in a
a given wallclock period. The default is Speed = 1 which is to given wallclock period. The default is Speed = 1 which means to
deliver at the same rate the media is consumed. Speed > 1 means that deliver at the same rate the media is consumed. Speed > 1 means that
the receiver will get content faster than it regularly would consume the receiver will get content faster than it regularly would consume
it. Speed < 1 means that delivery is slower than the regular media it. Speed < 1 means that delivery is slower than the regular media
rate. Speed values of 0 or lower has no meaning and are not allowed. rate. Speed values of 0 or lower have no meaning and are not
This mechanism enables two general functionalities. Client side allowed. This mechanism enables two general functionalities. One is
scale operations, i.e. the client receives all the frames and makes client side scale operations, i.e. the client receives all the frames
the adjustment to the playback locally. The second usage is to and makes the adjustment to the playback locally. The second is
control delivery for buffering of media. By specifying a speed over delivery control for buffering of media. By specifying a speed over
1.0 the client can build up the amount of playback time it has 1.0 the client can build up the amount of playback time it has
present in its buffers to a level that is sufficient for its needs. present in its buffers to a level that is sufficient for its needs.
A naive implementation of Speed would only affect the transmission A naive implementation of Speed would only affect the transmission
schedule of the media and has a clear impact on the needed bandwidth. schedule of the media and has a clear impact on the needed bandwidth.
This would result in the data rate being proportional to the speed This would result in the data rate being proportional to the speed
factor. Speed = 1.5, i.e. 50% faster than normal delivery, will then factor. Speed = 1.5, i.e., 50% faster than normal delivery, would
result in a 50% increase in the data transport rate. If that can be result in a 50% increase in the data transport rate. If that can be
supported or not depends solely on the underlying network path. supported or not depends solely on the underlying network path.
Scale may also have some impact on the required bandwidth due to the Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example manipulation of the content in the new playback schedule. An example
is fast forward where only the independently decodable intra frames is fast forward where only the independently decodable intra frames
are included in the media stream. This usage of solely intra frames are included in the media stream. This usage of solely intra frames
increase the data rate significantly compared to a normal sequence increases the data rate significantly compared to a normal sequence
with the same number of frames where most frames are encoded using with the same number of frames, where most frames are encoded using
prediction. prediction.
This potential increase of the data rate needs to be handled by the This potential increase of the data rate needs to be handled by the
media sender. The client has requested that the media is delivered media sender. The client has requested that the media will be
in a specific way, which should be honored. However, the media delivered in a specific way, which should be honored. However, the
sender can not ignore if the network path between the sender and the media sender cannot ignore if the network path between the sender and
receiver can't handle the resulting media stream. In that case the the receiver can't handle the resulting media stream. In that case
media stream needs to be adapted to fit the available resources of the media stream needs to be adapted to fit the available resources
the path. This can result in that media quality has be reduced due of the path. This can result in a reduced media quality.
to the delivery modifications that the client has requested.
The need for bitrate adaptation becomes especially problematic in The need for bitrate adaptation becomes especially problematic in
connection to Speed. If the goal is to fill up the buffer, the connection with the Speed semantics. If the goal is to fill up the
client may not want to do that at the cost of reduced quality. If buffer, the client may not want to do that at the cost of reduced
you like to do local playout changes then you may actually require quality. If the client wants to make local playout changes then it
that the requested speed is honored. To resolve this issue, the may actually require that the requested speed be honored. To resolve
usage of speed specifies a range so that both usages can be this issue, Speed uses a range so that both cases can be supported.
supported. The server is requested to use the highest possible speed The server is requested to use the highest possible speed value
value within the range which is compatible with the available within the range which is compatible with the available bandwidth.
bandwidth. As long as the server can maintain a speed value within As long as the server can maintain a speed value within the range it
the range it shall not change the media quality, but instead modify shall not change the media quality, but instead modify the actual
the speed value in response to available bandwidth. However, if this delivery rate in response to available bandwidth and reflect this in
is not possible, the server should instead modify the media quality the Speed value in the response. However, if this is not possible,
to respect the lowest speed value and the available bandwidth. the server should instead modify the media quality to respect the
lowest speed value and the available bandwidth.
This functionality enables the local scaling implementation to use a This functionality enables the local scaling implementation to use a
tight range, or even a range where the lower bound equals the upper tight range, or even a range where the lower bound equals the upper
bound, to identify that it requires the server to deliver the bound, to identify that it requires the server to deliver the
requested amount of media time per delivery time independent of how requested amount of media time per delivery time independent of how
much it needs to adapt the media quality to fit within the available much it needs to adapt the media quality to fit within the available
path bandwidth. For buffer fill up, it is suitable to use a range path bandwidth. For buffer filling, it is suitable to use a range
with a reasonable span and with a lower bound at the nominal media with a reasonable span and with a lower bound at the nominal media
rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the
buffer, it can specify an upper bound that is below 1.0 to force the buffer, it can specify an upper bound that is below 1.0 to force the
server to deliver slower than the nominal media rate. server to deliver slower than the nominal media rate.
2.6. Session Maintenance and Termination 2.6. Session Maintenance and Termination
The session context that has been established is kept alive by having The session context that has been established is kept alive by having
the client show liveness. This is done in two main ways: the client show liveness. This is done in two main ways:
o Media transport protocol keep-alive. RTCP is possible to use when o Media transport protocol keep-alive. RTCP may be used when using
using RTP. RTP.
o Any RTSP request referencing the session context. o Any RTSP request referencing the session context.
Section 10.5 discusses the methods for showing liveness in more Section 10.5 discusses the methods for showing liveness in more
depth. If the client fails to show liveness for more than the depth. If the client fails to show liveness for more than the
established session timeout value (normally 60 seconds), the server established session timeout value (normally 60 seconds), the server
may terminate the context. Other values may be selected by the may terminate the context. Other values may be selected by the
server through the inclusion of the timeout parameter in the session server through the inclusion of the timeout parameter in the session
header. header.
The session context is normally terminated by the client by sending a The session context is normally terminated by the client sending a
TEARDOWN request to the server referencing the aggregated control TEARDOWN request to the server referencing the aggregated control
URI. An individual media resource can be removed from a session URI. An individual media resource can be removed from a session
context by a TEARDOWN request referencing that particular media context by a TEARDOWN request referencing that particular media
resource. If all media resources are removed from a session context, resource. If all media resources are removed from a session context,
the session context is terminated. the session context is terminated.
A client may keep the session alive indefinitely if allowed by the A client may keep the session alive indefinitely if allowed by the
server, however it is recommend to release the session context when server; however, it is recommended to release the session context
an extended period of time without media delivery activity has when an extended period of time without media delivery activity has
passed. It can re-establish the session context if required later. passed. The client can re-establish the session context if required
One issue is that what is an extended period of time is dependent on later. What constitutes an extended period of time is dependent on
the server and its usage. It is recommended that the client the server and its usage. It is recommended that the client
terminates the session before 10*times the session timeout value has terminates the session before 10*times the session timeout value has
passed. A server may terminate the session after one session timeout passed. A server may terminate the session after one session timeout
period without any client activity beyond keep-alive. When a server period without any client activity beyond keep-alive. When a server
terminates the session context, it does that by sending a TEARDOWN terminates the session context, it does that by sending a TEARDOWN
request indicating the reason. request indicating the reason.
A server can also request that the client tear down the session and A server can also request that the client tear down the session and
re-establish it at an alternative server, as may be needed for re-establish it at an alternative server, as may be needed for
maintenance. This is done by using the REDIRECT method. The maintenance. This is done by using the REDIRECT method. The
Terminate-Reason header is used to indicate when and why. The Terminate-Reason header is used to indicate when and why. The
Location header indicates where it should connect if there is an Location header indicates where it should connect if there is an
alternative server available. When the deadline expires, the server alternative server available. When the deadline expires, the server
simply stops providing the service. To achieve a clean closure, the simply stops providing the service. To achieve a clean closure, the
client needs to initiate session termination prior to the deadline. client needs to initiate session termination prior to the deadline.
In case the server has no other server to redirect to, and likes to In case the server has no other server to redirect to, and wants to
close the session for maintenance, it shall use the TEARDOWN method close the session for maintenance, it shall use the TEARDOWN method
with a Terminate-Reason header. with a Terminate-Reason header.
2.7. Extending RTSP 2.7. Extending RTSP
RTSP is quite a versatile protocol which supports extensions in many RTSP is quite a versatile protocol which supports extensions in many
different directions. Even this core specification contains several different directions. Even this core specification contains several
blocks of functionality that are optional to implement. The use case blocks of functionality that are optional to implement. The use case
and need for the protocol deployment is what should determine what is and need for the protocol deployment should determine what parts are
implemented. Allowing for extensions makes it possible for RTSP to implemented. Allowing for extensions makes it possible for RTSP to
reach out to additional use cases. However, extensions will affect reach out to additional use cases. However, extensions will affect
the interoperability of the protocol and therefore it is important the interoperability of the protocol and therefore it is important
that it can be done in a structured way. that they can be added in a structured way.
The client can learn the servers capability through the usage of the The client can learn the capability of a server by using the OPTIONS
OPTIONS method (Section 13.1) and the Supported header method (Section 13.1) and the Supported header (Section 16.49). It
(Section 16.49). It can also try and possibly fail by using new can also try and possibly fail using new methods, or require that
methods or require that particular features are supported using the particular features are supported using the Require or Proxy-Require
Require or Proxy-Require header. header.
The RTSP protocol in itself can be extended in three ways, listed The RTSP protocol in itself can be extended in three ways, listed
here in order of the magnitude of changes supported: here in order of the magnitude of changes supported:
o Existing methods can be extended with new parameters, for example, o Existing methods can be extended with new parameters, for example,
headers, as long as these parameters can be safely ignored by the headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgement when a recipient. If the client needs negative acknowledgement when a
method extension is not supported, a tag corresponding to the method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy- extension may be added in the field of the Require or Proxy-
Require headers (see Section 16.35). Require headers (see Section 16.35).
skipping to change at page 24, line 12 skipping to change at page 25, line 12
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 20 and transmitted over a connection or a connectionless Section 20 and transmitted over a connection or a connectionless
transport. A message is either a Request or a Response. transport. A message is either a Request or a Response.
Message Body: The information transferred as the payload of a Message Body: The information transferred as the payload of a
message (Request and response). A message body consists of meta- message (Request and response). A message body consists of meta-
information in the form of message-headers and content in the form information in the form of message-body headers and content in the
of an message-body, as described in Section 9. form of a message-body, as described in Section 9.
Non-Aggregated Control: Control of a single media stream. Non-Aggregated Control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
description as defined below. Presentations with more than one description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control. media stream are often handled in RTSP under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a presentation, information about one or more media streams within a presentation,
skipping to change at page 25, line 5 skipping to change at page 26, line 5
entities. entities.
RTSP session: A stateful abstraction upon which the main control RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a common context; it methods of RTSP operate. An RTSP session is a common context; it
is created, maintained and destroyed on client's request. It is is created, maintained and destroyed on client's request. It is
established by an RTSP server upon the completion of a successful established by an RTSP server upon the completion of a successful
SETUP request (when a 200 OK response is sent) and is labeled with SETUP request (when a 200 OK response is sent) and is labeled with
a session identifier at that time. The session exists until timed a session identifier at that time. The session exists until timed
out by the server or explicitly removed by a TEARDOWN request. An out by the server or explicitly removed by a TEARDOWN request. An
RTSP session is a stateful entity; an RTSP server maintains an RTSP session is a stateful entity; an RTSP server maintains an
explicit session state machine (see Appendix A) where most state explicit session state machine (see Appendix B) where most state
transitions are triggered by client requests. The existence of a transitions are triggered by client requests. The existence of a
session implies the existence of state about the session's media session implies the existence of state about the session's media
streams and their respective transport mechanisms. A given streams and their respective transport mechanisms. A given
session can have one or more media streams associated with it. An session can have one or more media streams associated with it. An
RTSP server uses the session to aggregate control over multiple RTSP server uses the session to aggregate control over multiple
media streams. media streams.
Origin Server: The server on which a given resource resides. Origin Server: The server on which a given resource resides.
Transport initialization: The negotiation of transport information Transport initialization: The negotiation of transport information
skipping to change at page 26, line 38 skipping to change at page 27, line 38
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport (UDP in RTSP transport of the RTSP messages over unreliable transport (UDP in RTSP
1.0). The details of the syntax of "rtsp" and "rtsps" URIs has been 1.0). A RTSP server MUST response with with an error code indicating
changed from RTSP 1.0. the "rtspu" scheme is not implemented (501) to a request that carries
a "rtspu" URI scheme. The details of the syntax of "rtsp" and
"rtsps" URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs RTSP IRI format MUST use the rules and transformation for IRIs
defined in [RFC3987]. This way RTSP 2.0 URIs for request can be defined in [RFC3987]. This way RTSP 2.0 URIs for request can be
produced from an RTSP IRI. produced from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in [RFC3986] and RFC [RFC3987]: generic syntax defined in [RFC3986] and [RFC3987]:
o An absolute URI requires the authority part; i.e., a host identity o An absolute URI requires the authority part; i.e., a host identity
must be provided. must be provided.
o Parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
The RTSP URI and IRI is case sensitive, with the exception of those The RTSP URI and IRI is case sensitive, with the exception of those
parts that [RFC3986] and [RFC3987] defines as case-insensitive; for parts that [RFC3986] and [RFC3987] defines as case-insensitive; for
example, the scheme and host part. example, the scheme and host part.
skipping to change at page 27, line 28 skipping to change at page 28, line 28
to interpret the value of the fragment based on the media type the to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requester's (usually the server) specific. The query is, from the requester's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
Please note that relative URI with queries are difficult to handle Please note that relative URI with queries are difficult to handle
due to the RFC 3986 relative URI handling rules. Any change of the due to the RFC 3986 relative URI handling rules. Any change of the
path element using a relative URI results in the stripping of the path element using a relative URI results in the stripping of the
query. Which means the relative part needs to contain the query. query, which means the relative part needs to contain the query.
The URI scheme "rtsp" requires that commands are issued via a The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme reliable protocol (within the Internet, TCP), while the scheme
"rtsps" identifies a reliable transport using secure transport (TLS "rtsps" identifies a reliable transport using secure transport (TLS
[RFC5246], see (Section 19). [RFC5246], see (Section 19).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 MUST be used. For the scheme part of the URI port number 554 MUST be used. For the scheme
"rtsps", the TCP port 322 is registered and MUST be assumed. "rtsps", the TCP port 322 is registered and MUST be assumed.
skipping to change at page 29, line 4 skipping to change at page 30, line 4
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default SMPTE format with the origin at the start of the clip. The default SMPTE format
is "SMPTE 30 drop" format, with frame rate is 29.97 frames per is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
second. Other SMPTE codes MAY be supported (such as "SMPTE 25") second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
through the use of alternative use of "smpte-type". For SMPTE 30, through the use of "smpte-type". For SMPTE 30, the "frames" field in
the "frames" field in the time value can assume the values 0 through the time value can assume the values 0 through 29. The difference
29. The difference between 30 and 29.97 frames per second is handled between 30 and 29.97 frames per second is handled by dropping the
by dropping the first two frame indices (values 00 and 01) of every first two frame indices (values 00 and 01) of every minute, except
minute, except every tenth minute. If the frame and the subframe every tenth minute. If the frame and the subframe values are zero,
values are zero, they may be omitted. Subframes are measured in one- they may be omitted. Subframes are measured in one-hundredth of a
hundredth of a frame. frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
4.5. Normal Play Time 4.5. Normal Play Time
skipping to change at page 30, line 51 skipping to change at page 31, line 51
4.8. Message Body Tags 4.8. Message Body Tags
Message body tags are opaque strings that are used to compare two Message body tags are opaque strings that are used to compare two
message bodies from the same resource, for example in caches or to message bodies from the same resource, for example in caches or to
optimize setup after a redirect. Message body tags can be carried in optimize setup after a redirect. Message body tags can be carried in
the MTag header (see Section 16.30) or in SDP (see Appendix D.1.9). the MTag header (see Section 16.30) or in SDP (see Appendix D.1.9).
MTag is similar to ETag in HTTP/1.1. MTag is similar to ETag in HTTP/1.1.
A message body tag MUST be unique across all versions of all message A message body tag MUST be unique across all versions of all message
bodies associated with a particular resource. A given message body bodies associated with a particular resource. A given message body
tag value MAY be used for message body obtained by requests on tag value MAY be used for message bodies obtained by requests on
different URIs. The use of the same message body tag value in different URIs. The use of the same message body tag value in
conjunction with message bodies obtained by requests on different conjunction with message bodies obtained by requests on different
URIs does not imply the equivalence of those message bodies URIs does not imply the equivalence of those message bodies
Message body tags are used in RTSP to make some methods conditional. Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers, The methods are made conditional through the inclusion of headers;
see "If-Match" (Section 16.23) and "If-None-Match" (Section 16.25). see "If-Match" (Section 16.23) and "If-None-Match" (Section 16.25).
Note that RTSP message body tags apply to the complete presentation; Note that RTSP message body tags apply to the complete presentation;
i.e., both the presentation description and the individual media i.e., both the presentation description and the individual media
streams. Thus message body tags can be used to verify at setup time streams. Thus message body tags can be used to verify at setup time
after a redirect that the same session description applies to the after a redirect that the same session description applies to the
media at the new location using the If-Match header. media at the new location using the If-Match header.
4.9. Media Properties 4.9. Media Properties
When an RTSP server handles media, it is important to consider the When an RTSP server handles media, it is important to consider the
skipping to change at page 31, line 42 skipping to change at page 32, line 42
Dynamic On-demand: This is a variation of the on-demand case where Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is a content media setup for the RTSP session. The main example is a content
defined by a playlist. defined by a playlist.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
accessed. accessed.
Live with Recording: A Live stream that is combined with a server Live with Recording: A Live stream that is combined with a server-
side capability to store and retain the content of the live side capability to store and retain the content of the live
session for random access delivery within the part of the already session, and allow for random access delivery within the part of
recorded content. The actual behavior of the media stream is very the already recorded content. The actual behavior of the media
much depending on the retention policy for the media stream. stream is very much dependent on the retention policy for the
Either the server will be able to capture the complete media media stream; either the server will be able to capture the
stream, or it will have a limitation in how much will be retained. complete media stream, or it will have a limitation in how much
The media range will dynamically change as the session progress. will be retained. The media range will dynamically change as the
For servers with a limited amount of storage available for session progress. For servers with a limited amount of storage
recording, there will typically be a sliding window that goes available for recording, there will typically be a sliding window
forwards while data is made available and content that is older that moves forwards while new data is made available and older
than a limit will be discarded. data is discarded.
To cover the above usages, the following media properties with To cover the above usages, the following media properties with
appropriate values are specified: appropriate values are specified:
4.9.1. Random Access and Seeking 4.9.1. Random Access and Seeking
Random Access is about the possibility to specify and get media Random Access is the ability to specify and get media delivered from
delivered from any point inside the content, an operation called any point inside the content, an operation called seeking. This
seeking. This possibility is signaled using Seek-Style which can possibility is signaled using the Seek-Style header (see Section
take the following different values: Section 16.45) which can take the following different values:
Random Access: The media are seekable to any out of a large number Random Access: The media are seekable to any out of a large number
of points within the media. Due to media encoding limitations, a of points within the media. Due to media encoding limitations, a
particular point may not be reachable, but seeking to a point particular point may not be reachable, but seeking to a point
close by is enabled. A floating point number of seconds may be close by is enabled. A floating point number of seconds may be
provided to express the worst case distance between random access provided to express the worst case distance between random access
points. points.
Conditional Random Access: Based on the above Random Access but Conditional Random Access: Based on the above Random Access but
intended to handle a case where the distance in the media between intended to handle a case where the distance in the media between
random access points are large and where small seek forward using random access points are large, and where small seek forward using
Random Access would move the client further away then the current Random Access would move the client further away then the current
point. point.
Return To Start: Seeking is only possible to beginning of the Return To Start: Seeking is only possible to the beginning of the
content. content.
No seeking: Seeking is not possible at all. No seeking: Seeking is not possible at all.
4.9.2. Retention 4.9.2. Retention
Media may have different retention policy in place that affect the Media may have different retention policies in place that affect the
operation on the media. The following different media retention operation on media. The following different media retention policies
policies are envisioned and taken into consideration where are envisioned and taken into consideration where applicable:
applicable.
Unlimited: The media will not be removed as long as the RTSP session Unlimited: The media will not be removed as long as the RTSP session
is in existence. is in existence.
Time Limited: The media will at least not be removed before given Time Limited: The media will not be removed before given wallclock
wallclock time. After that time it may or may not be available time. After that time it may or may not be available any more.
any more.
Duration limited: Each individual unit of the media will be retained Duration limited: Each individual unit of the media will be retained
for the specified duration. for the specified duration.
4.9.3. Content Modifications 4.9.3. Content Modifications
There is also the question of how the content may change during time There is also the question of how the content may change during time
for a give media resource: for a give media resource:
Immutable: The content of the media will not change, even if the Immutable: The content of the media will not change, even if the
representation, i.e encoding, quality, etc, may change. representation, i.e., encoding, quality, etc., may change.
Dynamic: Between explicit updates the media content will not change, Dynamic: Between explicit updates the media content will not change,
but the content may change due to external methods or triggers, but the content may change due to external methods or triggers,
such as playlists. such as playlists.
Time Progressing: As times progress new content will become Time Progressing: As times progresses new content will become
available. If the content also is retained it will become longer available. If the content also is retained it will become longer
and longer as everything between the start point and the point in as everything between the start point and the point currently
currently being made available can be accessed. being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also
change as time progresses.
4.9.4. Supported Scale Factors 4.9.4. Supported Scale Factors
The content is often limiting the possible rates of scale that can be Content often suppports only a limited set or range of scales when
supported when delivering the media. To enable the client to know delivering the media.. To enable the client to know what values or
what values or ranges of scale operations that the whole content or ranges of scale operations that the whole content or the current
the current position supports a media properties attribute for this position supports, a media properties attribute for this is defined
is defined. It contains a list with the values and/or ranges that which contains a list with the values and/or ranges that are
are supported. The attribute is named "Scales". It may be updated supported. The attribute is named "Scales". It may be updated at
at any point in the content due to content consisting of spliced any point in the content due to content consisting of spliced pieces
pieces or content being dynamically updated by out of bands or content being dynamically updated by out-of-band mechanisms.
mechanisms.
4.9.5. Mapping to the Attributes 4.9.5. Mapping to the Attributes
This section exemplifies how one would map the above listed usages to This section shows exemaples of how one would map the above usages to
the properties and their values. the properties and their values.
On-demand: Random Access: Random Access=5s, Content Modifications: On-demand: Random Access: Random Access=5s, Content Modifications:
Immutable, Retention: unlimited or time limited. Immutable, Retention: unlimited or time limited.
Dynamic On-demand: Random Access: Random Access=3s, Content Dynamic On-demand: Random Access: Random Access=3s, Content
Modifications: Dynamic, Retention: unlimited or time limited. Modifications: Dynamic, Retention: unlimited or time limited.
Live: Random Access: No seeking, Content Modifications: Time Live: Random Access: No seeking, Content Modifications: Time
Progressing, Retention: Duration limited=0.0s Progressing, Retention: Duration limited=0.0s
skipping to change at page 35, line 19 skipping to change at page 35, line 19
Text-based protocols make it easier to add optional parameters in Text-based protocols make it easier to add optional parameters in
a self-describing manner. Since the number of parameters and the a self-describing manner. Since the number of parameters and the
frequency of commands is low, processing efficiency is not a frequency of commands is low, processing efficiency is not a
concern. Text-based protocols, if done carefully, also allow easy concern. Text-based protocols, if done carefully, also allow easy
implementation of research prototypes in scripting languages such implementation of research prototypes in scripting languages such
as TCL, Visual Basic and Perl. as TCL, Visual Basic and Perl.
The ISO 10646 character set avoids tricky character set switching, The ISO 10646 character set avoids tricky character set switching,
but is invisible to the application as long as US-ASCII is being but is invisible to the application as long as US-ASCII is being
used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1 used. This is also the encoding used for RTCP [RFC3550].
translates directly into Unicode with a high-order octet of zero.
ISO 8859-1 characters with the most-significant bit set are
represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629])
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 uses a format based on the generic and Response Section 8 messages use a format based on the generic
message format of RFC 0822 [RFC0822] for transferring bodies (the message format of RFC 0822 [RFC0822] for transferring bodies (the
payload of the message). Both types of message consist of a start- payload of the message). Both types of message 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 header, and possibly the data of the message-body. end of the header, and possibly the data of the message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
skipping to change at page 36, line 30 skipping to change at page 36, line 25
appending each subsequent field-value to the first, each separated by appending each subsequent field-value to the first, each separated by
a comma. The order in which header fields with the same field-name a comma. The order in which header fields with the same field-name
are received is therefore significant to the interpretation of the are received is therefore significant to the interpretation of the
combined field value, and thus a proxy MUST NOT change the order of combined field value, and thus a proxy MUST NOT change the order of
these field values when a message is forwarded. these field values when a message is forwarded.
Unknown message headers MUST be ignored (skipping over the header to Unknown message headers MUST be ignored (skipping over the header to
the next protocol element, and not causing an error) by a RTSP server the next protocol element, and not causing an error) by a RTSP server
or client. An RTSP Proxy MUST forward unknown message headers. or client. An RTSP Proxy MUST forward unknown message headers.
Message headers defined outside of this specification that are Message headers defined outside of this specification that are
required to be interpret by the RTSP agent will need to use feature required to be interpreted by the RTSP agent will need to use feature
tags (Section 4.7) and include it in the appropriate Require tags (Section 4.7) and include them in the appropriate Require
(Section 16.41) or Proxy-Require (Section 16.35) header. (Section 16.41) or Proxy-Require (Section 16.35) header.
5.3. Message Body 5.3. Message Body
The message-body (if any) of an RTSP message is used to carry further The message-body (if any) of an RTSP message is used to carry further
information for a particular resource associated with the request or information for a particular resource associated with the request or
response. An example for a message body is the Session Description response. An example of a message body is the Session Description
Protocol (SDP). Protocol (SDP).
The presence of a message-body in either a request or a response MUST The presence of a message-body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 16.16). Section 16.16).
The presence of a message-body in a request is signaled by the The presence of a message-body in a request is signaled by the
inclusion of a Content-Length header field in the RTSP message. A inclusion of a Content-Length header field in the RTSP message. A
message-body MUST NOT be included in a request or response if the message-body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions specification of the particular method (see Method Definitions
skipping to change at page 38, line 7 skipping to change at page 38, line 7
header whenever it contains a message body. Note that RTSP does not header whenever it contains a message body. Note that RTSP does not
support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]). support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).
Given the moderate length of presentation descriptions returned, Given the moderate length of presentation descriptions returned,
the server should always be able to determine its length, even if the server should always be able to determine its length, even if
it is generated dynamically, making the chunked transfer encoding it is generated dynamically, making the chunked transfer encoding
unnecessary. unnecessary.
6. General Header Fields 6. General Header Fields
General headers are headers that may be used in both request and General headers are headers that may be used in both requests and
responses. The general headers are listed in Table 1: responses. The general headers are listed in Table 1:
+--------------------+--------------------+ +--------------------+--------------------+
| Header Name | Defined in Section | | Header Name | Defined in Section |
+--------------------+--------------------+ +--------------------+--------------------+
| Accept-Ranges | Section 16.5 | | Accept-Ranges | Section 16.5 |
| | | | | |
| Cache-Control | Section 16.10 | | Cache-Control | Section 16.10 |
| | | | | |
| Connection | Section 16.11 | | Connection | Section 16.11 |
skipping to change at page 42, line 31 skipping to change at page 42, line 31
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Transport | Section 16.52 | | Transport | Section 16.52 |
| | | | | |
| User-Agent | Section 16.54 | | User-Agent | Section 16.54 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 16. Detailed header definition are provided in Section 16.
New request headers may be defined. If the receiver of the request New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header. header to ensure the processing of the header.
8. Response 8. Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. Normally, there is only one, responds with an RTSP response message. Normally, there is only one,
final, response. It is only for responses using the response code final, response. Only responses using the response code class 1xx,
class 1xx, that it is allowed to send one or more 1xx response that it is allowed to send one or more 1xx response messages prior to
messages prior to the final response message. the final response message.
The valid response codes and the methods they can be used with are The valid response codes and the methods they can be used with are
listed in Table 4. listed in Table 4.
8.1. Status-Line 8.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
skipping to change at page 46, line 31 skipping to change at page 46, line 31
| 501 | Not Implemented | all | | 501 | Not Implemented | all |
| | | | | | | |
| 502 | Bad Gateway | all | | 502 | Bad Gateway | all |
| | | | | | | |
| 503 | Service Unavailable | all | | 503 | Service Unavailable | all |
| | | | | | | |
| 504 | Gateway Timeout | all | | 504 | Gateway Timeout | all |
| | | | | | | |
| 505 | RTSP Version Not Supported | all | | 505 | RTSP Version Not Supported | all |
| | | | | | | |
| 551 | Option not support | all | | 551 | Option Not Support | all |
+------+----------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
8.2. Response Headers 8.2. Response Headers
The response-header allow the request recipient to pass additional The response-header allows the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header give information about the server and about Line. This header give information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in
Table 5. Table 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 16.12 | | Connection-Credentials | Section 16.12 |
skipping to change at page 47, line 41 skipping to change at page 47, line 41
| | | | | |
| Unsupported | Section 16.53 | | Unsupported | Section 16.53 |
| | | | | |
| Vary | Section 16.55 | | Vary | Section 16.55 |
| | | | | |
| WWW-Authenticate | Section 16.57 | | WWW-Authenticate | Section 16.57 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-headers names can be extended reliably only in combination Response-header names can be extended reliably only in combination
with a change in the protocol version. However, the usage of with a change in the protocol version. However, the usage of
feature-tags in the request allows the responding party to learn the feature-tags in the request allows the responding party to learn the
capability of the receiver of the response. New or experimental capability of the receiver of the response. A new or experimental
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be response-header. in the communication recognize them to be response-header.
Unrecognized headers in responses are treated as message-headers. Unrecognized headers in responses are treated as message-headers.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body, if not Request and Response messages MAY transfer a message body, if not
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
The message body consists of message-body header fields and an the The message body consists of message-body header fields and the
content data itself. content data itself.
The SET_PARAMETER and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have an message body. All 4xx and 5xx DESCRIBE response MAY have an message body. All 4xx and 5xx
responses MAY also have an message body. responses MAY also have an message body.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message or the server, depending on who sends and who receives the message
body. body.
skipping to change at page 48, line 50 skipping to change at page 48, line 50
| | | | | |
| Content-Type | Section 16.18 | | Content-Type | Section 16.18 |
| | | | | |
| Expires | Section 16.21 | | Expires | Section 16.21 |
| | | | | |
| Last-Modified | Section 16.26 | | Last-Modified | Section 16.26 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP message-body headers Table 6: The RTSP message-body headers
The extension-header mechanism allows additional message-header The extension-header mechanism allows additional message-body header
fields to be defined without changing the protocol, but these fields fields to be defined without changing the protocol, but these fields
cannot be assumed to be recognizable by the recipient. Unrecognized cannot be assumed to be recognizable by the recipient. Unrecognized
header fields MUST be ignored by the recipient and forwarded by header fields MUST be ignored by the recipient and forwarded by
proxies. proxies.
9.2. Message Body 9.2. Message Body
RTSP message with an message body MUST include the Content-Type and RTSP message with an message body MUST include the Content-Type and
Content-Length headers. When a message body is included with a Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the message, the data type of that content data is determined via the
skipping to change at page 50, line 38 skipping to change at page 50, line 38
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see Section 12). responses to requests if the requests are pipelined (see Section 12).
It is also useful in proxies for keeping track of the different It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP requests when aggregating several client requests on a single TCP
connection. connection.
10.1. Reliability and Acknowledgements 10.1. Reliability and Acknowledgements
When RTSP messages are transmitted using reliable transport Since RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication provide reliability. The RTSP implementation may use any indication
of reception acknowledgement of the message from the underlying of reception acknowledgement of the message from the underlying
transport protocols to optimize the RTSP behavior. transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport such as TCP and the RTSP If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, each packet loss or message loss application retransmit requests, each packet loss or message loss
may result in two retransmissions. The receiver typically cannot may result in two retransmissions. The receiver typically cannot
take advantage of the application-layer retransmission since the take advantage of the application-layer retransmission since the
skipping to change at page 51, line 44 skipping to change at page 51, line 44
the client wishes to send a new request, such as a PAUSE for the the client wishes to send a new request, such as a PAUSE for the
session, a new connection would be opened. This connection may session, a new connection would be opened. This connection may
either be transient or persistent. either be transient or persistent.
An RTSP agent SHOULD NOT have more than one connection to the server An RTSP agent SHOULD NOT have more than one connection to the server
at any given point. If a client or proxy handles multiple RTSP at any given point. If a client or proxy handles multiple RTSP
sessions on the same server, it SHOULD use only one connection for sessions on the same server, it SHOULD use only one connection for
managing those sessions. managing those sessions.
This saves connection resources on the server. It also reduces This saves connection resources on the server. It also reduces
complexity by and enabling the server to maintain less state about complexity by enabling the server to maintain less state about its
its sessions and connections. sessions and connections.
RTSP allows a server to send requests to a client. However, this can RTSP allows a server to send requests to a client. However, this can
be supported only if a client establishes a persistent connection be supported only if a client establishes a persistent connection
with the server. In cases where a persistent connection does not with the server. In cases where a persistent connection does not
exist between a server and its client, due to the lack of a signaling exist between a server and its client, due to the lack of a signaling
channel the server may be forced to silently discard RTSP messages, channel the server may be forced to silently discard RTSP messages,
and may even drop an RTSP session without notifying the client. An and may even drop an RTSP session without notifying the client. An
example of such a case is when the server desires to send a REDIRECT example of such a case is when the server desires to send a REDIRECT
request for an RTSP session to the client but is not able to do so request for an RTSP session to the client but is not able to do so
because it cannot reach the client. A server that attempt to send a because it cannot reach the client. A server that attempts to send a
request to a client that has no connection currently to the server request to a client that has no connection currently to the server
SHOULD discard the request directly, it MAY queue it for later SHOULD discard the request directly, but it MAY queue it for later
delivery. However, if the server queue the request it should when delivery. However, if the server queues the request it should when
adding additional requests to the queue ensure to remove older adding additional requests to the queue ensure to remove older
requests that are now redundant. requests that are now redundant.
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
The sending of client and server requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
To avoid deadlock situations both client and server MUST be able to To avoid deadlock situations both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be send and receive requests simultaneously. As an RTSP response may be
queued up for transmission, reception or processing behind the peer queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. The issue is certain capability of handling outstanding messages. A potential
that outstanding requests may timeout despite them being processed by issue is that outstanding requests may timeout despite them being
the peer due to the response is caught in the queue behind a number processed by the peer due to the response is caught in the queue
of request that the RTSP agent is processing but that take some time behind a number of request that the RTSP agent is processing but that
to complete. To avoid this problem an RTSP agent is recommended to take some time to complete. To avoid this problem an RTSP agent is
buffer incoming messages locally so that any response messages can be recommended to buffer incoming messages locally so that any response
processed immediately upon reception. If responses are separated messages can be processed immediately upon reception. If responses
from requests and directly forwarded for processing can not only the are separated from requests and directly forwarded for processing,
result be used immediately, the state associated with that not only the result be used immediately, the state associated with
outstanding request can also be released. However, buffering a that outstanding request can also be released. However, buffering a
number of requests on the receiving RTSP agent consumes resources and number of requests on the receiving RTSP agent consumes resources and
enables a resource exhaustion attack on the agent. Therefore this enables a resource exhaustion attack on the agent. Therefore this
buffer should be limited so that an unreasonable number of requests buffer should be limited so that an unreasonable number of requests
or total message size is not allowed to consume the receiving agents or total message size is not allowed to consume the receiving agent's
resources. In most APIs having the receiving agent stop reading from resources. In most APIs having the receiving agent stop reading from
the TCP socket will result in TCP's window being clamped. Thus the TCP socket will result in TCP's window being clamped. Thus
forcing the buffering on the sending agent when the load is larger forcing the buffering onto the sending agent when the load is larger
than expected. However, as both RTSP message sizes and frequency may than expected. However, as both RTSP message sizes and frequency may
be changed in the future by protocol extension an agent should be be changed in the future by protocol extensions, an agent should be
careful against taking harsher measurements against a potential careful against taking harsher measurements against a potential
attack. When under attack an RTSP agent can close TCP connections attack. When under attack an RTSP agent can close TCP connections
and release state associated with that TCP connection. and release state associated with that TCP connection.
To provide some guidance on what is reasonable the following To provide some guidance on what is reasonable the following
guidelines are given. An RTSP agent should not have more than 10 guidelines are given. An RTSP agent should not have more than 10
outstanding requests per RTSP session. An RTSP agent should not have outstanding requests per RTSP session. An RTSP agent should not have
more than 10 outstanding requests that aren't related to an RTSP more than 10 outstanding requests that aren't related to an RTSP
session or that are requesting to create an RTSP session. session or that are requesting to create an RTSP session.
skipping to change at page 53, line 43 skipping to change at page 53, line 43
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 15.4.25) are used for negotiating capabilities Allowed" (Section 15.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the flip side, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
The server MAY close a connection if he receives an incomplete
message and if the message is not completed within a reasonable
amount of time. It is RECOMMENDED that the server waits at least 1
second for the completion of a message or for the next part of the
message to arrive (which is an indication that the transport and the
client are still alive).
If a server closes a connection while the client is attempting to If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current send a new request, the client will have to close its current
connection, establish a new connection and send its request over the connection, establish a new connection and send its request over the
new connection. new connection.
An RTSP message should not be terminated by closing the connection. An RTSP message should not be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 5. Section 5.
skipping to change at page 55, line 9 skipping to change at page 55, line 20
liveness of the RTSP client. It is RECOMMENDED that a client does liveness of the RTSP client. It is RECOMMENDED that a client does
not wait to the last second of the timeout before trying to send a not wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using liveness message. The RTSP message may be lost or when using
reliable protocols, such as TCP, the message may take some time to reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be issued to accomplish other things, the following mechanisms can be
used, in descending order of preference: used, in descending order of preference:
RTCP: If RTP is used for media transport RTCP SHOULD be used. If RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it MUST also work RTCP is used to report transport statistics, it MUST also work
as keep alive. The server can determine the client by used as keep alive. The server can determine the client by network
network address and port together with the fact that the client address and port together with the fact that the client is
is reporting on the servers SSRC(s). A downside of using RTCP reporting on the servers SSRC(s). A downside of using RTCP is
is that it only gives statistical guarantees to reach the that it only gives statistical guarantees to reach the server.
server. However, that probability is so low that it can be However, the probability of a false client timeout is so low
ignored in most cases. For example, a session with 60 seconds that it can be ignored in most cases. For example, assume a
timeout and enough bitrate assigned to RTCP messages to send a session with 60 seconds timeout and enough bitrate assigned to
message from client to server on average every 5 seconds. That RTCP messages to send a message from client to server on
client have for a network with 5 % packet loss, the probability average every 5 seconds. That client have, for a network with
to fail showing liveness sign in that session within the 5 % packet loss, the probability to fail showing liveness sign
timeout interval of 2.4*E-16. In sessions with shorter timeout in that session within the timeout interval of 2.4*E-16. In
times, or much higher packet loss, or small RTCP bandwidths sessions with shorter timeouts, or much higher packet loss, or
SHOULD also use any of the mechanisms below. small RTCP bandwidths SHOULD also use any of the mechanisms
below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
SHOULD be included. This method is the RECOMMENDED RTSP method SHOULD be included. This method is the RECOMMENDED RTSP method
to use in request only intended to perform keep-alive. to use for a request intended only to perform keep-alive.
GET_PARAMETER: When using GET_PARAMETER for keep alive, no body GET_PARAMETER: When using GET_PARAMETER for keep alive, no body
SHOULD be included. SHOULD be included.
OPTIONS: This method is also usable, but it causes the server to OPTIONS: This method is also usable, but it causes the server to
perform more unnecessary processing and result in bigger perform more unnecessary processing and result in bigger
responses than necessary for the task. The reason is that the responses than necessary for the task. The reason is that the
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
The timeout parameter MAY be included in a SETUP response, and MUST The timeout parameter MAY be included in a SETUP response, and MUST
NOT be included in requests. The server uses it to indicate to the NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of or other signs of life before closing the session due to lack of
activity (see below and Appendix B). The timeout is measured in activity (see Appendix B). The timeout is measured in seconds, with
seconds, with a default of 60 seconds. The length of the session a default of 60 seconds. The length of the session timeout MUST NOT
timeout MUST NOT be changed in an established session. be changed in an established session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
skipping to change at page 56, line 22 skipping to change at page 57, line 22
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover whether it is supported. This is done by issuing method to discover whether it is supported. This is done by issuing
a OPTIONS request to the other party. Depending on the URI it will a OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST in general, or simply the next hop. The OPTIONS response MUST
contain a Public header which declares all methods supported for the contain a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
the client could simply try the method. If the receiver of the as the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the method is either not implemented (501) or does code indicating the method is either not implemented (501) or does
not apply for the resource (405). The choice between the two not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
Feature-Tags are defined to handle functionality additions that are Feature-Tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A feature-tag can for example represents can vary significantly. A feature-tag can for example
represent the functionality a single RTSP header provides. Another represent the functionality a single RTSP header provides. Another
skipping to change at page 56, line 45 skipping to change at page 57, line 45
for playback implementation. for playback implementation.
Feature-tags are used to determine whether the client, server or Feature-tags are used to determine whether the client, server or
proxy supports the functionality that is necessary to achieve the proxy supports the functionality that is necessary to achieve the
desired service. To determine support of a feature-tag, several desired service. To determine support of a feature-tag, several
different headers can be used, each explained below: different headers can be used, each explained below:
Supported: This header is used to determine the complete set of Supported: This header is used to determine the complete set of
functionality that both client and server have. The intended functionality that both client and server have. The intended
usage is to determine before one needs to use a functionality usage is to determine before one needs to use a functionality
that it is supported. It can be used in any method, however, that it is supported. It can be used in any method, but
OPTIONS is the most suitable one as it at the same time OPTIONS is the most suitable one as it at the same time
determines all methods that are implemented. When sending a determines all methods that are implemented. When sending a
request the requester declares all its capabilities by request the requester declares all its capabilities by
including all supported feature-tags. This results in that the including all supported feature-tags. This results in the
receiver learns the requesters feature support. The receiver receiver learns the requester's feature support. The receiver
then includes its set of features in the response. then includes its set of features in the response.
Proxy-Supported: This header is used similar to the Supported Proxy-Supported: This header is used similarly to the Supported
header, but instead of giving the supported functionality of header, but instead of giving the supported functionality of
the client or server it provides both the requester and the the client or server it provides both the requester and the
responder a view of what functionality the proxy chain between responder a view of what functionality the proxy chain between
the two supports. Proxies are required to add this header the two supports. Proxies are required to add this header
whenever the Supported header is present, but proxies may whenever the Supported header is present, but proxies may also
independently of the requester add it. add it independently of the requester.
Require: The header can be included in any request where the end- Require: This header can be included in any request where the end-
point, i.e. the client or server, is required to understand the point, i.e. the client or server, is required to understand the
feature to correctly perform the request. This can, for feature to correctly perform the request. This can, for
example, be a SETUP request where the server is required to example, be a SETUP request where the server is required to
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require MUST negatively receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not supported are 551 (Option Not Supported). Also the not supported are 551 (Option Not Supported). Also the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
Proxy-Require: This header has the same purpose and workings as Proxy-Require: This header has the same purpose and workings as
Require except that it only applies to proxies and not the end- Require except that it only applies to proxies and not the end-
point. Features that needs to be supported by both proxies and point. Features that need to be supported by both proxies and
end-point needs to be included in both the Require and Proxy- end-points need to be included in both the Require and Proxy-
Require header. Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which features were not supported. Such a response is indicate which features were not supported. Such a response is
only the result of the usage of the Require and/or Proxy- only the result of the usage of the Require and/or Proxy-
Require header where one or more feature where not supported. Require header where one or more feature where not supported.
This information allows the requester to make the best of This information allows the requester to make the best of
situations as it knows which features are not supported. situations as it knows which features are not supported.
12. Pipelining Support 12. Pipelining Support
skipping to change at page 58, line 18 skipping to change at page 59, line 18
response protocols by allowing the requesting agent to have more than response protocols by allowing the requesting agent to have more than
one request outstanding and send them over the same persistent one request outstanding and send them over the same persistent
connection. For RTSP, where the relative order of requests will connection. For RTSP, where the relative order of requests will
matter, it is important to maintain the order of the requests. matter, it is important to maintain the order of the requests.
Because of this, the responding agent MUST process the incoming Because of this, the responding agent MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same as the sending order. The processing of the
request MUST also have been finished before processing the next request MUST also have been finished before processing the next
request from the same agent. The responses MUST be sent in the order request from the same agent. The responses MUST be sent in the order
the requests was processed. the requests were processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate The major improvement is to allow all requests to setup and initiate
media delivery to be pipelined after each other. This is media delivery to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (see accomplished by the utilization of the Pipelined-Requests header (see
Section 16.32). This header allows a client to request that two or Section 16.32). This header allows a client to request that two or
more requests are processed in the same RTSP session context which more requests are processed in the same RTSP session context which
the first request creates. In other words, a client can request that the first request creates. In other words, a client can request that
two or more media streams are set-up and then played without needing two or more media streams are set-up and then played without needing
to wait for a single response. This speeds up the initial startup to wait for a single response. This speeds up the initial startup
time for an RTSP session with at least one RTT. time for an RTSP session with at least one RTT.
If a pipelined request builds on the successful completion of one or If a pipelined request builds on the successful completion of one or
more prior requests the requester must verify that all requests were more prior requests the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the and a PLAY request. In case one of the SETUP fails unexpectedly, the
PLAY request can still be successfully executed. However, not as PLAY request can still be successfully executed. However, the
expected by the requesting client as only a single media instead of resulting presentation will not be as expected by the requesting
two will be played. In this case the client can send a PAUSE client, as only a single media instead of two will be played. In
request, correct the failing SETUP request and then request it to be this case the client can send a PAUSE request, correct the failing
played. SETUP request and then request it to be played.
13. Method Definitions 13. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names MUST NOT New methods may be defined in the future. Method names MUST NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 24) and MUST be a token as defined
by the ABNF [RFC5234] in the syntax chapter Section 20. The methods by the ABNF [RFC5234] in the syntax chapter Section 20. The methods
are summarized in Table 7. are summarized in Table 7.
skipping to change at page 59, line 43 skipping to change at page 60, line 43
| REDIRECT | S -> C | P,S | optional | required | | REDIRECT | S -> C | P,S | optional | required |
| | | | | | | | | | | |
| SETUP | C -> S | S | required | required | | SETUP | C -> S | S | required | required |
| | | | | | | | | | | |
| SET_PARAMETER | C -> S | P,S | required | optional | | SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | | | | | | | |
| | S -> C | P,S | optional | optional | | | S -> C | P,S | optional | optional |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | required | required |
| | | | | | | | | | | |
| | S -> C | | required | required | | | S -> C | P | required | required |
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Respond, (P: presentation, S: stream) they operate on.
Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GET_PARAMETER is recommended, but not required. Note on Table 7: GET_PARAMETER is recommended, but not required.
For example, a fully functional server can be built to deliver For example, a fully functional server can be built to deliver
media without any parameters. SET_PARAMETER is required, however, media without any parameters. SET_PARAMETER is required, however,
due to its usage for keep-alive. PAUSE is now required due to due to its usage for keep-alive. PAUSE is now required because it
that it is the only way of getting out of the state machines play is the only way of leaving the Play state without terminating the
state without terminating the whole session. whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
An RTSP proxy who's main function is to log or audit and not modify An RTSP proxy whose main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note, the proxy still needs to perform the minimal unknown methods. Note that the proxy still needs to perform the
required processing, like adding the Via header. minimal required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
The semantics of the RTSP OPTIONS method is similar to that of the The semantics of the RTSP OPTIONS method is similar to that of the
HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can request it to a server and vice
versa. A client MUST implement the capability to send an OPTIONS versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability. implement the converse of their required capability.
skipping to change at page 61, line 7 skipping to change at page 62, line 7
the request is limited to a media resource, the Allow header MUST be the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
such as 3rr or 4xx. The Supported header MAY be included in the such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the request to query the set of features that are supported by the
responding RTSP agent. responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive However, this is not the preferred way of session keep-alive
signaling, see Section 16.47. An OPTIONS request intended for signaling, see Section 16.47. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS rtsp://server.example.com RTSP/2.0 C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 61, line 38 skipping to change at page 62, line 38
fictional features. fictional features.
13.2. DESCRIBE 13.2. DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server MUST respond description formats that it understands. The server MUST respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the message body of the response. The DESCRIBE reply- description in the message body of the response, if the DESCRIBE
method request can be successfully fulfilled. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
The DESCRIBE response SHOULD contain all media initialization
information for the resource(s) that it describes. Servers SHOULD
NOT use the DESCRIBE response as a means of media indirection by
having the description point at another server; instead, using the
3rr responses is RECOMMENDED.
By forcing a DESCRIBE response to contain all media initialization
for the set of streams that it describes, and discouraging the use
of DESCRIBE for media indirection, any looping problems can be
avoided that might have resulted from other approaches.
Example: Example:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer/1.1
Content-Base: rtsp://server.example.com/fizzle/foo/ Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 358 Content-Length: 358
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=control:* a=control:*
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=control:audio a=control:audio
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
a=control:video a=control:video
The DESCRIBE response SHOULD contain all media initialization
information for the resource(s) that it describes. Servers SHOULD
NOT use the DESCRIBE response as a means of media indirection by
having the description point at another server, instead usage of 3rr
responses are recommended.
By forcing a DESCRIBE response to contain all media initialization
for the set of streams that it describes, and discouraging the use
of DESCRIBE for media indirection, any looping problems can be
avoided that might have resulted from other approaches.
Media initialization is a requirement for any RTSP-based system, but Media initialization is a requirement for any RTSP-based system, but
the RTSP specification does not dictate that this is required to be the RTSP specification does not dictate that this is required to be
done via the DESCRIBE method. There are three ways that an RTSP done via the DESCRIBE method. There are three ways that an RTSP
client may receive initialization information: client may receive initialization information:
o via an RTSP DESCRIBE request o via an RTSP DESCRIBE request
o via some other protocol (HTTP, email attachment, etc.) o via some other protocol (HTTP, email attachment, etc.)
o via some form of user interface o via some form of user interface
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. The client should use issuing a DESCRIBE request for the same media. The client should use
any MTag to either validate the presentation description or make the any MTag to either validate the presentation description or make the
session establishment conditional on being valid. session establishment conditional on being valid.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
skipping to change at page 63, line 24 skipping to change at page 64, line 19
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in two used for the streamed media. The SETUP method may be used in two
different cases; Create an RTSP session and change the transport different cases; Create an RTSP session and change the transport
parameters of already set up media stream. SETUP can be used in all parameters of already set up media stream. SETUP can be used in all
three states; INIT, and READY, for both purposes and in PLAY to three states; Init, and Ready, for both purposes and in PLAY to
change the transport parameters. There is also a third possible change the transport parameters. There is also a third possible
usage for the SETUP method which is not specified in this memo: usage for the SETUP method which is not specified in this memo:
adding a media to a session. Using SETUP to add media to an existing adding a media to a session. Using SETUP to add media to an existing
session, when the session is in PLAY state, is unspecified. session, when the session is in Play state, is unspecified.
The Transport header, see Section 16.52, specifies the media The Transport header, see Section 16.52, specifies the media
transport parameters acceptable to the client for data transmission; transport parameters acceptable to the client for data transmission;
the response will contain the transport parameters selected by the the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number possible configurations that are offered to select a limited number possible configurations that are offered to
the server to choose from. All transport related parameters shall be the server to choose from. All transport related parameters shall be
included in the Transport header, the use of other headers for this included in the Transport header; the use of other headers for this
purpose is discouraged due to middleboxes, such as firewalls or NATs. purpose is discouraged due to middleboxes, such as firewalls or NATs.
For the benefit of any intervening firewalls, a client MUST indicate For the benefit of any intervening firewalls, a client MUST indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization information, Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
initialization. initialization.
The client MUST include the Accept-Ranges header in the request The client MUST include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which format it may use in future session allows the server to know which format it may use in future session
related responses, such as PLAY response without any range in the related responses, such as a PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server MUST respond using 456 (Header Field Not the presentation the server MUST respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server MUST include the Accept-Ranges header In a SETUP response the server MUST include the Accept-Ranges header
(see Section 16.5) to indicate which time formats that are acceptable (see Section 16.5) to indicate which time formats are acceptable to
to use for this media resource. use for this media resource.
The SETUP response 200 OK MUST include the Media-Properties header The SETUP response 200 OK MUST include the Media-Properties header
(see Section 16.28 ). The combination of the parameters of the (see Section 16.28 ). The combination of the parameters of the
Media-Properties header indicate the nature of the content present in Media-Properties header indicate the nature of the content present in
the session (see also Section 4.9). For example, a live stream with the session (see also Section 4.9). For example, a live stream with
time shifting is indicated by time shifting is indicated by
o Random Access set to Random-Access, o Random Access set to Random-Access,
o Content Modifications set to Time Progressing, o Content Modifications set to Time Progressing,
skipping to change at page 65, line 15 skipping to change at page 65, line 41
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer/1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/ "192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED "198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=3.2, Time-Progressing, Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0 Time-Duration=3600.0
Media-Range: npt=0-2893.23 Media-Range: npt=0-2893.23
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
skipping to change at page 66, line 30 skipping to change at page 67, line 9
further discussion see Section 16.47. Signs of liveness for an RTSP further discussion see Section 16.47. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client which includes a Session header o Any RTSP request from a client which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is as valid for keep-alive. conference session and is valid for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams MUST remain unchanged from their values as if the SETUP streams MUST remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
13.3.1. Changing Transport Parameters 13.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). MUST respond with error 455 (Method Not Valid In This State). The
Reasons to support changing transport parameters, is to allow for reasons to support changing transport parameters include allowing
application layer mobility and flexibility to utilize the best application layer mobility and flexibility to utilize the best
available transport as it becomes available. If a client receives a available transport as it becomes available. If a client receives a
455 when trying to change transport parameters while the server is in 455 when trying to change transport parameters while the server is in
play state, it MAY try to put the server in ready state using PAUSE, Play state, it MAY try to put the server in ready state using PAUSE,
before issuing the SETUP request again. If also that fails the before issuing the SETUP request again. If that also fails the
changing of transport parameters will require that the client changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then setting it up performs a TEARDOWN of the affected media and then to set it up
again. In aggregated session avoiding tearing down all the media at again. In aggregated session avoiding tearing down all the media at
the same time will avoid the creation of a new session. the same time will avoid the creation of a new session.
All transport parameters MAY be changed. However, the primary usage All transport parameters MAY be changed. However, the primary usage
expected is to either change transport protocol completely, like expected is to either change the transport protocol completely, like
switching from Interleaved TCP mode to UDP or vice versa or change switching from Interleaved TCP mode to UDP or vice versa, or to
delivery address. change the delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server MUST include the Range to indicate while in Play state, the server MUST include the Range to indicate at
from what point the new transport parameters are used. Further, if what point the new transport parameters will be used. Further, if
RTP is used for delivery, the server MUST also include the RTP-Info RTP is used for delivery, the server MUST also include the RTP-Info
header to indicate from what timestamp and RTP sequence number the header to indicate at what timestamp and RTP sequence number the
change has taken place. If both RTP-Info and Range is included in change will take place. If both RTP-Info and Range are included in
the response the "rtp_time" parameter and start point in the Range the response the "rtp_time" parameter and start point in the Range
header MUST be for the corresponding time, i.e. be used in the same header MUST be for the corresponding time, i.e. be used in the same
way as for PLAY to ensure the correct synchronization information is way as for PLAY to ensure the correct synchronization information is
available. available.
If the transport parameters change while in PLAY state results in a If the transport parameters change while in Play state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However, the server is RECOMMENDED to synchronization information. However, the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
13.4. PLAY 13.4. PLAY
This section describes the usage of the PLAY method in general, for This section describes the usage of the PLAY method in general, for
aggregated sessions, and in different usage scenarios. aggregated sessions, and in different usage scenarios.
13.4.1. General Usage 13.4.1. General Usage
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in READY or played out. PLAY requests are valid when the session is in Ready or
PLAY states. A PLAY request MUST include a Session header to Play states. A PLAY request MUST include a Session header to
indicate which session the request applies to. indicate which session the request applies to.
Upon receipt of the PLAY request, the server MUST position the normal Upon receipt of the PLAY request, the server MUST position the normal
play time to the beginning of the range specified in the received play time to the beginning of the range specified in the received
Range header and deliver stream data until the end of the range if Range header and deliver stream data until the end of the range if
given, or until a new PLAY request is received, else to the end of given, until a new PLAY request is received, or until the end of the
the media is reached. If no Range header is present in the PLAY media is reached. If no Range header is present in the PLAY request
request the server shall play from current pause point until the end the server SHALL play from current pause point until the end of
of media. The pause point defaults at session start to the beginning media. The pause point defaults at session start to the beginning of
of the media. For media that is time-progressing and has no the media. For media that is time-progressing and has no retention,
retention, the pause point will always be set equal to NPT "now", the pause point will always be set equal to NPT "now", i.e., the
i.e. current delivery point. The pause point may also be set to a current delivery point. The pause point may also be set to a
particular point in the media by the PAUSE method, see Section 13.6. particular point in the media by the PAUSE method, see Section 13.6.
The pause point for media that is currently playing is equal to the The pause point for media that is currently playing is equal to the
current media position. For time-progressing media with time-limited current media position. For time-progressing media with time-limited
retention, if the pause point represents a position that is older retention, if the pause point represents a position that is older
than what is retained by the server, the pause point will be moved to than what is retained by the server, the pause point will be moved to
the oldest retained. the oldest retained.
What range values are valid depends on the type of content. For What range values are valid depends on the type of content. For
content that isn't time progressing the range value is valid if the content that isn't time progressing the range value is valid if the
given range is part of any media within the aggregate. In other given range is part of any media within the aggregate. In other
words the valid media range for the aggregate is the union of all of words the valid media range for the aggregate is the union of all of
the media components in the aggregate. If a given range value points the media components in the aggregate. If a given range value points
outside of the media, the response MUST be the 457 (Invalid Range) outside of the media, the response MUST be the 457 (Invalid Range)
error code and include the Media-Range header (Section 16.29) with error code and include the Media-Range header (Section 16.29) with
the valid range for the media. Except for time progressing content the valid range for the media. Except for time progressing content
where the client request a start point prior to what is retained, the where the client requests a start point prior to what is retained,
start point is adjusted to the oldest retained content. For a start the start point is adjusted to the oldest retained content. For a
point that is beyond the media front edge, i.e. beyond the current start point that is beyond the media front edge, i.e. beyond the
value for "now", the server shall adjust the start value to the current value for "now", the server SHALL adjust the start value to
current front edge. The Range headers end point value may point the current front edge. The Range header's stop point value may
beyond the current media edge. In that case, the server shall point beyond the current media edge. In that case, the server SHALL
deliver media from the requested (and possibly adjusted) start point deliver media from the requested (and possibly adjusted) start point
until the provided end-point, or the end of the media is reached until the provided stop point, or the end of the media is reached
prior to the specified stop point. Please note that if one simply prior to the specified stop point. Please note that if one simply
want to play from a particular start point until the end of media wants to play from a particular start point until the end of media
using an Range header with an implicit stop point is recommended. using an Range header with an implicit stop point is RECOMMENDED.
If a client request starting playing media at the end-point either If a client requests to start playing at the end of media, either
explicitly with a Range header or implicit by having a pause point explicitly with a Range header or implicitly with a pause point that
that is at the end of the media, a 457 (Invalid Range) error MUST be is at the end of media, a 457 (Invalid Range) error MUST be sent and
sent and include the Media-Range header (Section 16.29). Below is include the Media-Range header (Section 16.29). Below is specified
specified that the Range header also must be included, and will in that the Range header also must be included, and will in the case of
the case of Ready-State carry the pause point. Note that this also Ready State carry the pause point. Note that this also applies if
applies if the pause point or requested start point is at the the pause point or requested start point is at the beginning of the
beginning of the media and a Scale header (Section 16.44) is included media and a Scale header (Section 16.44) is included with a negative
with a negative value (playing backwards). value (playing backwards).
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 16.45) use. This is done by including the Seek-Style header (Section 16.45)
in the PLAY request. The Seek-Style applied will effect the content in the PLAY request. The Seek-Style applied will effect the content
of the Range header as it will be adjusted to indicate from what of the Range header as it will be adjusted to indicate from what
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
npt=0-. If a PLAY request is received without a Range header and npt=0-. If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with an
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g. "npt=-30"). When used in a PLAY request,
the server treats this as a request to start/resume delivery from the the server treats this as a request to start or resume delivery from
current pause point, ending at the end time specified in the Range the current pause point, ending at the end time specified in the
header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response MUST be given. value, a 457 (Invalid Range) response MUST be given.
The example below will play seconds 10 through 25. It also request The example below will play seconds 10 through 25. It also requests
the server to deliver media from the first Random Access Point prior the server to deliver media from the first Random Access Point prior
to the indicated start point. to the indicated start point.
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=10-25 Range: npt=10-25
Seek-Style: RAP Seek-Style: RAP
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 69, line 34 skipping to change at page 70, line 13
no Range header was present in the request. The response MUST use no Range header was present in the request. The response MUST use
the same format as the request's range header contained. If no Range the same format as the request's range header contained. If no Range
header was in the request, the format used in any previous PLAY header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been request within the session SHOULD be used. If no format has been
indicated in a previous request the server MAY use any time format indicated in a previous request the server MAY use any time format
supported by the media and indicated in the Accept-Ranges header in supported by the media and indicated in the Accept-Ranges header in
the SETUP request. It is RECOMMENDED that NPT is used if supported the SETUP request. It is RECOMMENDED that NPT is used if supported
by the media. by the media.
For any error response to a PLAY request, the server's response For any error response to a PLAY request, the server's response
depends on the current session state. If the session is in ready depends on the current session state. If the session is in Ready
state, the current pause-point is returned using Range header with state, the current pause-point is returned using Range header with
the pause point as the explicit start-point and an implicit end- the pause point as the explicit start-point and an implicit stop-
point. For time-progressing content where the pause-point moves with point. For time-progressing content where the pause-point moves with
real-time due to limited retention, the current pause point is real-time due to limited retention, the current pause point is
returned. For sessions in playing state, the current playout point returned. For sessions in Play state, the current playout point and
and the remaining parts of the range request is returned. For any the remaining parts of the range request is returned. For any media
media with retention longer than 0 seconds the currently valid Media- with retention longer than 0 seconds the currently valid Media-Range
Range header shall also be included in the response. header SHALL also be included in the response.
A PLAY response MAY include a header carrying synchronization A PLAY response MAY include a header carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
are needed. For RTP the RTP-Info header is specified, see are needed. For RTP the RTP-Info header is specified, see
Section 16.43, and used in the following example. Section 16.43, and used in the following example.
Here is a simple example for a single audio stream where the client Here is a simple example for a single audio stream where the client
requests the media starting from 3.52 seconds and to the end. The requests the media starting from 3.52 seconds and to the end. The
server sends a 200 OK response with the actual play time which is 10 server sends a 200 OK response with the actual play time which is 10
skipping to change at page 70, line 16 skipping to change at page 70, line 44
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=3.52- Range: npt=3.52-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: npt=3.51-324.39 Range: npt=3.51-324.39
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.51 S->C: RTP Packet TS=2345962545 => NPT=3.51
Media duration=0.16 seconds Media duration=0.16 seconds
The server reply with the actual start point that will be delivered. The server replies with the actual start point that will be
This may differ from the requested range if alignment of the delivered. This may differ from the requested range if alignment of
requested range to valid frame boundaries is required for the media the requested range to valid frame boundaries is required for the
source. Note that some media streams in an aggregate may need to be media source. Note that some media streams in an aggregate may need
delivered from even earlier points. Also, some media format have a to be delivered from even earlier points. Also, some media formats
very long duration per individual data unit, therefore it might be have a very long duration per individual data unit, therefore it
necessary for the client to parse the data unit, and select where to might be necessary for the client to parse the data unit, and select
start. The server shall also indicate which policy it uses for where to start. The server SHALL also indicate which policy it uses
selecting the actual start point by including a Seek-Style header. for selecting the actual start point by including a Seek-Style
header.
In the following example the client receives the first media packet In the following example the client receives the first media packet
that stretches all the way up and past the requested playtime. Thus, that stretches all the way up and past the requested playtime. Thus,
it is the client's decision if to render to the user the time between it is the client's decision whether to render to the user the time
3.52 and 7.05, or to skip it. In most cases it is probably most between 3.52 and 7.05, or to skip it. In most cases it is probably
suitable not to render that time period. most suitable not to render that time period.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=7.05- User-Agent: PhonyClient/1.2 Range: npt=7.05-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: npt=3.52- Range: npt=3.52-
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds Duration=4.15 seconds
After playing the desired range, the presentation does NOT transition After playing the desired range, the presentation does NOT transition
to the READY state, media delivery simply stops. A PAUSE request to the Ready state, media delivery simply stops. A PAUSE request
MUST be issued before the stream enters the READY state. A PLAY MUST be issued before the stream enters the Ready state. A PLAY
request while the stream is still in the PLAYING state is legal, and request while the stream is still in the Play state is legal, and can
can be issued without an intervening PAUSE request. Such a request be issued without an intervening PAUSE request. Such a request MUST
MUST replace the current PLAY action with the new one requested, i.e. replace the current PLAY action with the new one requested, i.e.
being handle the same as the request was received in ready state. In being handle the same as the request was received in Ready state. In
the case the range in Range header has a implicit start time the case the range in Range header has a implicit start time
(-endtime), the server MUST continue to play from where it currently (-endtime), the server MUST continue to play from where it currently
was until the specified end point. This is useful to change end at was until the specified end point. This is useful to change end at
another point than in the previous request. another point than in the previous request.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines, where following lines headers has been broken into several lines, where following lines
start with whitespace as allowed by the syntax. start with whitespace as allowed by the syntax.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 833 CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: smpte=0:10:22-0:15:45 Range: smpte=0:10:22-0:15:45
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/twister.en" RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be For playing back a recording of a live presentation, it may be
desirable to use clock units: desirable to use clock units:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: clock=19961108T142300Z-19961108T143520Z Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/meeting.en" RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019 ssrc=0D12F123:seq=53745;rtptime=484589019
13.4.2. Aggregated Sessions 13.4.2. Aggregated Sessions
PLAY requests can operate on sessions controlling a single media and PLAY requests can operate on sessions controlling a single media and
on aggregated sessions controlling multiple media. on aggregated sessions controlling multiple media.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server MUST response with error 460 (Only Aggregate control URI. A server MUST respond with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for a single
media. The media in an aggregate MUST be played in sync. If a media. The media in an aggregate MUST be played in sync. If a
client wants individual control of the media, it needs to use client wants individual control of the media, it needs to use
separate RTSP sessions for each media. separate RTSP sessions for each media.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY session) is followed by one or more additional SETUP requests, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has delay from start of session establishment until media play-out has
started with one round trip time. However, a client needs to be started with one round trip time. However, a client needs to be
aware that using this procedure will result in the playout of the aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e., server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request in after the processing of all the requests prior to the PLAY request in
the pipeline. This may not be the intended one due to failure of any the pipeline. This state may not be the intended one due to failure
of the prior requests. However, a client can easily determine this of any of the prior requests. A client can easily determine this
based on the responses from those requests. In case of failure, the based on the responses from those requests. In case of failure, the
client can halt the media playout using PAUSE and try to establish client can halt the media playout using PAUSE and try to establish
the intended state again before issuing another PLAY request. the intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY requests while the stream is in PLAYING state Clients can issue PLAY requests while the stream is in Play state and
and thus updating their request. thus updating their request.
The important difference compared to a PLAY request in ready state is The important difference compared to a PLAY request in Ready state is
the handling of the current play point and how the range header in the handling of the current play point and how the Range header in
request is constructed. The session is actively playing media and request is constructed. The session is actively playing media and
the play point will be moving making the exact time a request will the play point will be moving, making the exact time a request will
take action is hard to predict. Depending on how the PLAY header take action is hard to predict. Depending on how the PLAY header
appears two different cases exist: total replacement or continuation. appears two different cases exist: total replacement or continuation.
A total replacement is signaled by having the first range A total replacement is signaled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In and then a new play request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and a explicit stop value (Z), e.g. npt=-60, which start point and a explicit stop value (Z), e.g. npt=-60, which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the stop point is beyond the the request originally played. If the stop point is beyond the
current delivery point, the server SHALL immediately pause delivery. current delivery point, the server SHALL immediately pause delivery.
As the request has been completed successfully it shall be responded As the request has been completed successfully it shall be responded
with 200 OK. A PLAY-Notify with end-of-stream is also sent to with 200 OK. A PLAY-NOTIFY with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to requested indicate the actual stop point. The pause point is set to the
stop point. requested stop point.
An example of this behavior. The server has received requests to Following is an example of this behavior: The server has received
play ranges 10 to 15. If the new PLAY request arrives at the server requests to play ranges 10 to 15. If the new PLAY request arrives at
4 seconds after the previous one, it will take effect while the the server 4 seconds after the previous one, it will take effect
server still plays the first range (10-15). Thus changing the while the server still plays the first range (10-15). The server
behavior of this range to continue to play to 25 seconds, i.e. the changes the current play to continue to 25 seconds, i.e. the
equivalent single request would be PLAY with range: npt=10-25. equivalent single request would be PLAY with range: npt=10-25.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678 Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: npt=10-15 Range: npt=10-15
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=-25 Range: npt=-25
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: 12345678 Session: 12345678
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: npt=14-25 Range: npt=14-25
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
A common use of a PLAY request while in Play state is changing the
scale of the media, i.e., entering or leaving from fast forward or
fast rewind. The client can issue an updating PLAY request that is
either a continunation or a complete replacement, as discussed above
this section. We give an example of a client that is requesting a
fast forward without giving a stop point and the change from fast
forward to regular playout (scale = 1).
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034
Session: 12345678 Session: 12345678
Range: npt=now-
Scale: 2.0
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 2034
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: 12345678
Server: PhonyServer/1.0
Range: npt=2:17:21.394-
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678
[playing in fast forward and now returing to scale = 1]
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035
Session: 12345678
Range: npt=now-
Scale: 1.0
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 2035
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: 12345678
Server: PhonyServer/1.0
Range: npt=2:19:32.144-
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
13.4.4. Playing On-Demand Media 13.4.4. Playing On-Demand Media
On-demand media is indicated by the content of the Media-Properties On-demand media is indicated by the content of the Media-Properties
header in the SETUP response by (see also Section 16.28): header in the SETUP response by (see also Section 16.28):
o Random-Access property is set to Random Access; o Random-Access property is set to Random Access;
o Content Modifications set to Immutable; o Content Modifications set to Immutable;
o Retention set Unlimited or Time-Limited.
o Retention set to Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1. Section 13.4.1.
13.4.5. Playing Dynamic On-Demand Media 13.4.5. Playing Dynamic On-Demand Media
Dynamic on-demand media is indicated by the content of the Media- Dynamic on-demand media is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 16.28):
o Random-Access set to Random Access; o RandomAccess set to Random-Access;
o Content Modifications set to dynamic; o Content Modifications set to Dynamic;
o Retention set Unlimited or Time-Limited. o Retention set to Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1 as long as the media has not been changed. Section 13.4.1 as long as the media has not been changed.
There are two ways for the client to get informed about changes of There are two ways for the client to be informed about changes of
media resources in play state. The client will receive a PLAY_NOTIFY media resources in Play state. The client will receive a PLAY_NOTIFY
request with Notify-Reason header set to media-properties-update (see request with Notify-Reason header set to media-properties-update (see
Section 13.5.2. The client can use the value of the Media-Range to Section 13.5.2. The client can use the value of the Media-Range to
decide further actions, if the Media-Range header is present in the decide further actions, if the Media-Range header is present in the
PLAY_NOTIFY request. The second way is that the client issues a PLAY_NOTIFY request. The second way is that the client issues a
GET_PARAMETER request without a body but including a Media-Range GET_PARAMETER request without a body but including a Media-Range
header. The 200 OK response MUST include the current Media-Range header. The 200 OK response MUST include the current Media-Range
header (see Section 16.29). header (see Section 16.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 16.28):
o Random-Access set to no-seeking; o Random-Access set to No-Seeking;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention with Time-Duration set to 0.0. o Retention with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK MUST include the Media- For live media, the SETUP response 200 OK MUST include the Media-
Range header (see Section 16.29). Range header (see Section 16.29).
A client MAY send PLAY requests without the Range header, if the A client MAY send PLAY requests without the Range header. If the
request include the Range header it MUST use a symbolic value request includes the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server MUST include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate an explicit time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words npt=now- is not a valid to use in the response. Instead the words, "npt=now-" is not a valid to use in the response. Instead the
time since session start is recommended expressed as an open time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The
UTC clock format can only be used if client has shown support for it UTC clock format can only be used if client has shown support for it
using the Accept-Ranges header. using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media server may offer recording services of live sessions to Certain media server may offer recording services of live sessions to
their clients. This recording would normally be from the beginning their clients. This recording would normally be from the beginning
of the media session. Clients can randomly access the media between of the media session. Clients can randomly access the media between
now and the beginning of the media session. This live media with now and the beginning of the media session. This live media with
recording is indicated by the content of the Media-Properties header recording is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 16.28):
o Random-Access set to random-access; o Random-Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-limited or Unlimited o Retention set to Time-limited or Unlimited
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with Section 16.29) for this type of media. For live media with
recording, the Range header indicates the current delivery point in recording, the Range header indicates the current delivery point in
the media and the Media-Range header indicates the currently the media and the Media-Range header indicates the currently
available media window around the current time. This window can available media window around the current time. This window can
skipping to change at page 76, line 50 skipping to change at page 78, line 14
13.4.8. Playing Live with Time-Shift 13.4.8. Playing Live with Time-Shift
Certain media server may offer time-shift services to their clients. Certain media server may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 16.28):
o Random-Access set to random-access; o Random-Access set to Random-Access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-Duration and a value indicating the o Retention set to Time-Duration and a value indicating the
recording interval (>0). recording interval (>0).
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with recording Section 16.29) for this type of media. For live media with recording
the Range header indicates the current time in the media and the the Range header indicates the current time in the media and the
Media Range indicates a window around the current time. This window Media Range indicates a window around the current time. This window
can cover recorded content in the past (seen from current time in the can cover recorded content in the past (seen from current time in the
skipping to change at page 77, line 26 skipping to change at page 78, line 38
border of the window, if the client requests a play point that is border of the window, if the client requests a play point that is
located outside the recording windows, e.g., if requested too far in located outside the recording windows, e.g., if requested too far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests delivery considerations in Section 13.5.3 apply, if a client requests delivery
using a Scale (Section 16.44) value other than 1.0 (Normal playback using a Scale (Section 16.44) value other than 1.0 (Normal playback
rate) while delivering live media with time-shift. rate) while delivering live media with time-shift.
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an asynchronously event for a session in play state. The Session an asynchronous event for a session in Play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client. no way for the server to send this request method to the client.
PLAY_NOTIFY requests have an end-to-end (i.e. server to client) PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
scope, as they carry the Session header, and apply only to the given scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the session. The client SHOULD immediately return a response to the
server. server.
PLAY_NOTIFY requests MAY be used with a message body, depending on PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used. particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. There is in this case a need to obey some limitations message body. In this case, there is a need to obey some limitations
when adding new Notify-Reasons that intend to use a message body: The when adding new Notify-Reasons that intend to use a message body: the
server can send any type of message body, but it is not ensured that server can send any type of message body, but it is not ensured that
the client can understand the received message body. This is related the client can understand the received message body. This is related
to DESCRIBE (see Section 13.2 ), but in this particular case the to DESCRIBE (see Section 13.2 ), but in this particular case the
client can state its acceptable message bodies by using the Accept client can state its acceptable message bodies by using the Accept
header. In the case of PLAY_NOTIFY, the server does not know which header. In the case of PLAY_NOTIFY, the server does not know which
message bodies are understood by the client. message bodies are understood by the client.
The Notify-Reason header (see Section 16.31) specifies the reason why The Notify-Reason header (see Section 16.31) specifies the reason why
the server sends the PLAY_NOTIFY request. This is extensible and new the server sends the PLAY_NOTIFY request. This is extensible and new
reasons MAY be added in the future. In case the client does not reasons MAY be added in the future. In case the client does not
skipping to change at page 78, line 20 skipping to change at page 79, line 31
o media-properties-update (see Section 13.5.2); o media-properties-update (see Section 13.5.2);
o scale-change (see Section 13.5.3). o scale-change (see Section 13.5.3).
13.5.1. End-of-Stream 13.5.1. End-of-Stream
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
indicates the completion or near completion of the PLAY request and indicates the completion or near completion of the PLAY request and
the ending delivery of the media stream(s). The request MUST NOT be the ending delivery of the media stream(s). The request MUST NOT be
issued unless the server is in the playing state. The end of the issued unless the server is in the Play state. The end of the media
media stream delivery notification may be used to indicate either a stream delivery notification may be used to indicate either a
successful completion of the PLAY request currently being served, or successful completion of the PLAY request currently being served, or
to indicate some error resulting in failure to complete the request. to indicate some error resulting in failure to complete the request.
The Request-Status header (Section 16.40) MUST be included to The Request-Status header (Section 16.40) MUST be included to
indicate which request the notification is for and its completion indicate which request the notification is for and its completion
status. The message response status codes (Section 8.1.1) are used status. The message response status codes (Section 8.1.1) are used
to indicate how the PLAY request concluded. The sender of a to indicate how the PLAY request concluded. The sender of a
PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a PLAY_NOTIFY can issue an updated PLAY_NOTIFY, in the case of a
PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY
was issued before reaching the end-of-stream, but some error occurred was issued before reaching the end-of-stream, but some error occurred
resulting in that the previously sent PLAY_NOTIFY contained a wrong resulting in that the previously sent PLAY_NOTIFY contained a wrong
skipping to change at page 78, line 48 skipping to change at page 80, line 11
is not 1. The Range header indicates the point in the stream or is not 1. The Range header indicates the point in the stream or
streams where delivery is ending with the timescale that was used by streams where delivery is ending with the timescale that was used by
the server in the PLAY response for the request being fulfilled. The the server in the PLAY response for the request being fulfilled. The
server MUST NOT use the "now" constant in the Range header; it MUST server MUST NOT use the "now" constant in the Range header; it MUST
use the actual numeric end position in the proper timescale. When use the actual numeric end position in the proper timescale. When
end-of-stream notifications are issued prior to having sent the last end-of-stream notifications are issued prior to having sent the last
media packets, this is evident as the end time in the Range header is media packets, this is evident as the end time in the Range header is
beyond the current time in the media being received by the client, beyond the current time in the media being received by the client,
e.g., npt=-15, if npt is currently at 14.2 seconds. The Scale header e.g., npt=-15, if npt is currently at 14.2 seconds. The Scale header
is to be included so that it is evident if the media time scale is is to be included so that it is evident if the media time scale is
moving backwards and/or have a non-default pace. moving backwards and/or have a non-default pace. The end-of-stream
notification does not prevent the client from sending a new PLAY
request.
If RTP is used as media transport, a RTP-Info header MUST be If RTP is used as media transport, a RTP-Info header MUST be
included, and the RTP-Info header MUST indicate the last sequence included, and the RTP-Info header MUST indicate the last sequence
number in the seq parameter. number in the seq parameter.
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
MUST NOT carry a message body. MUST NOT carry a message body.
This example request notifies the client about a future end-of-stream This example request notifies the client about a future end-of-stream
event: event:
skipping to change at page 79, line 39 skipping to change at page 81, line 4
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update indicates an update of the media properties for the properties-update indicates an update of the media properties for the
given session (see Section 16.28) and/or the available media range given session (see Section 16.28) and/or the available media range
that can be played as indicated by Media-Range (Section 16.29). that can be played as indicated by Media-Range (Section 16.29).
PLAY_NOTIFY requests with Notify-Reason header set to media- PLAY_NOTIFY requests with Notify-Reason header set to media-
properties-update MUST include a Media-Properties and Date header and properties-update MUST include a Media-Properties and Date header and
SHOULD include a Media-Range header. SHOULD include a Media-Range header.
This notification MUST be sent for media that are time-progressing This notification MUST be sent for media that are time-progressing
every time an event happens that changes the basis for making every time an event happens that changes the basis for making
estimations on how the media range progress. In addition it is estimates on how the media range progress. In addition it is
RECOMMENDED that the server sends these notifications every 5 minutes RECOMMENDED that the server sends these notifications every 5 minutes
for time-progressing content to ensure the long term stability of the for time-progressing content to ensure the long-term stability of the
client estimation and allowing for clock skew detection by the client estimation and allowing for clock skew detection by the
client. Requests for the just mentioned reasons MUST include Media- client. Requests for the just mentioned reasons MUST include Media-
Range header to provide current Media duration and the Range header Range header to provide current Media duration and the Range header
to indicate the current playing point and any remaining parts of the to indicate the current playing point and any remaining parts of the
requested range. requested range.
The recommendation for sending updates every 5 minutes is due to The recommendation for sending updates every 5 minutes is due to
any clock skew issues. In 5 minutes the clock skew should not any clock skew issues. In 5 minutes the clock skew should not
become too significant as this is not used for media playback and become too significant as this is not used for media playback and
synchronization, only for determining which content is available synchronization, only for determining which content is available
skipping to change at page 80, line 37 skipping to change at page 81, line 50
delivery using a Scale (Section 16.44) value other than 1.0 (normal delivery using a Scale (Section 16.44) value other than 1.0 (normal
playback rate). For time progressing media with some retention, i.e. playback rate). For time progressing media with some retention, i.e.
the server stores already sent content, a client requesting to play the server stores already sent content, a client requesting to play
with Scale values larger than 1 may catch up with the front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will then be unable to continue to provide the media. The server will then be unable to continue to provide
with content at Scale larger than 1 as content is only made available with content at Scale larger than 1 as content is only made available
by the server at Scale=1. Another case is when Scale < 1 and the by the server at Scale=1. Another case is when Scale < 1 and the
media retention is time-duration limited. In this case the delivery media retention is time-duration limited. In this case the delivery
point can reach the oldest media unit available, and further playback point can reach the oldest media unit available, and further playback
at this scale becomes impossible as there will be no media available. at this scale becomes impossible as there will be no media available.
To avoid having the client loose any media, the scale will need to be To avoid having the client lose any media, the scale will need to be
adjusted to the same rate which the media is removed from the storage adjusted to the same rate at which the media is removed from the
buffer, commonly scale = 1.0. storage buffer, commonly Scale = 1.0.
Another case is when the content itself consist of spliced pieces or Another case is when the content itself consists of spliced pieces or
is dynamically updated. In these cases the server may be required to is dynamically updated. In these cases the server may be required to
change from one supported scale value (different than Scale=1.0) to change from one supported scale value (different than Scale=1.0) to
another. In this case the server will pick the closest value and another. In this case the server will pick the closest value and
inform the client of what it has picked. In these case the media inform the client of what it has picked. In these case the media
properties will also be sent updating the supported Scale values. properties will also be sent updating the supported Scale values.
This enables a client to adjust the used Scale value. This enables a client to adjust the used Scale value.
To minimize impact on playback in any of the above cases the server To minimize impact on playback in any of the above cases the server
MUST modify the playback properties and set Scale to a supportable MUST modify the playback properties and set Scale to a supportable
value and continue delivery the media. When doing this modification value and continue delivery the media. When doing this modification
skipping to change at page 81, line 47 skipping to change at page 83, line 12
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.6. PAUSE 13.6. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done either with the interrupted (halted). A PAUSE request MUST be done either with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session MUST be responded with error 460 (Only an aggregated session MUST be responded to with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the resources after being paused for the duration specified with the
timeout parameter of the Session header in the SETUP message. timeout parameter of the Session header in the SETUP message.
Example: Example:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
skipping to change at page 83, line 14 skipping to change at page 84, line 14
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-30 Range: npt=10-30
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: npt=10-30 Range: npt=10-30
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
After 11 seconds, i.e. at 21 seconds into the presentation: After 11 seconds, i.e. at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Range: npt=21-30 Range: npt=21-30
Session: 12345678 Session: 12345678
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the READY state, the proper server response, if the player enters the Ready state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point. See examples include the Range header with the current pause point. See examples
below: below:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
skipping to change at page 84, line 40 skipping to change at page 85, line 40
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control request MAY be performed on either an aggregated or a media control
URI. However, some restrictions apply depending on the current URI. However, some restrictions apply depending on the current
state. The TEARDOWN request MUST contain a Session header indicating state. The TEARDOWN request MUST contain a Session header indicating
what session the request applies to. what session the request applies to.
A TEARDOWN using the aggregated control URI or the media URI in a A TEARDOWN using the aggregated control URI or the media URI in a
session under non-aggregated control (single media session) MAY be session under non-aggregated control (single media session) MAY be
done in any state (Ready, and Play). A successful request MUST done in any state (Ready and Play). A successful request MUST result
result in that media delivery is immediately halted and the session in that media delivery being immediately halted and the session state
state is destroyed. This MUST be indicated through the lack of a being destroyed. This MUST be indicated through the lack of a
Session header in the response. Session header in the response.
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
stream and associated resources from the session. This may result in stream and associated resources from the session. This may result in
that a session returns to non-aggregated control, due to that it only that a session returns to non-aggregated control, due to that it only
contains a single media after the requests completion. A session contains a single media after the requests completion. A session
that will exist after the processing of the TEARDOWN request MUST in that will exist after the processing of the TEARDOWN request MUST in
the response to that TEARDOWN request contain a Session header. Thus the response to that TEARDOWN request contain a Session header. Thus
the presence of the Session header indicates to the receiver of the the presence of the Session header indicates to the receiver of the
skipping to change at page 85, line 15 skipping to change at page 86, line 15
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer/1.0
13.7.2. Server to Client 13.7.2. Server to Client
The server can send TEARDOWN requests in the server to client The server can send TEARDOWN requests in the server to client
direction to indicate that the server has been forced to terminate direction to indicate that the server has been forced to terminate
the ongoing session. This may happen for several reasons, such as the ongoing session. This may happen for several reasons, such as
server maintenance without available backup, or that the session has server maintenance without available backup, or that the session has
been inactive for extended periods of time. The reason is provided been inactive for extended periods of time. The reason is provided
in the Terminate-Reason header (Section 16.50). in the Terminate-Reason header (Section 16.50).
skipping to change at page 85, line 44 skipping to change at page 86, line 44
it is 10 times the Session Timeout period. Consideration of the it is 10 times the Session Timeout period. Consideration of the
application of the server and its content should be performed when application of the server and its content should be performed when
configuring what is considered as extended periods of time. configuring what is considered as extended periods of time.
In case the server needs to stop providing service to the established In case the server needs to stop providing service to the established
sessions and their is no server to point at in a REDIRECT request sessions and their is no server to point at in a REDIRECT request
TEARDOWN shall be used to terminate the session. This method can TEARDOWN shall be used to terminate the session. This method can
also be used when non-recoverable internal errors have happened and also be used when non-recoverable internal errors have happened and
the server has no other option then to terminate the sessions. the server has no other option then to terminate the sessions.
The TEARDOWN request is normally done on the session aggregate The TEARDOWN request MUST be only done on the session aggregate
control URI and MUST include the following headers; Session and control URI (i.e., it is not allowed to terminate individual media
streams) and MUST include the following headers; Session and
Terminate-Reason headers. The request only applies to the session Terminate-Reason headers. The request only applies to the session
identified in the Session header. The server may include a message identified in the Session header. The server may include a message
to the client's user with the "user-msg" parameter. to the client's user with the "user-msg" parameter.
The TEARDOWN request may alternatively be done on the wild card URI * The TEARDOWN request may alternatively be done on the wild card URI *
and without any session header. The scope of such a request is and without any session header. The scope of such a request is
limited to the next-hop (i.e. the RTSP agent in direct communication limited to the next-hop (i.e. the RTSP agent in direct communication
with the server) and applies, as well, to the control connection with the server) and applies, as well, to the control connection
between the next-hop RTSP agent and the server. This request between the next-hop RTSP agent and the server. This request
indicates that all sessions and pending requests being managed via indicates that all sessions and pending requests being managed via
skipping to change at page 87, line 20 skipping to change at page 88, line 20
request may or may not been processed. Normally the presence of request may or may not been processed. Normally the presence of
filled out values in the header will be indication that the header filled out values in the header will be indication that the header
has been processed. However, for cases when this is difficult to has been processed. However, for cases when this is difficult to
determine, it is recommended to use a feature-tag and the Require determine, it is recommended to use a feature-tag and the Require
header. Due to this reason it is usually easier if any parameters to header. Due to this reason it is usually easier if any parameters to
be retrieved are sent in the body, rather than using any header. be retrieved are sent in the body, rather than using any header.
Parameters specified within the body of the message must all be Parameters specified within the body of the message must all be
understood by the request receiving agent. If one or more parameters understood by the request receiving agent. If one or more parameters
are not understood a 451 (Parameter Not Understood) MUST be sent are not understood a 451 (Parameter Not Understood) MUST be sent
including a body listing these parameters that wasn't understood. If including a body listing these parameters that weren't understood.
all parameters are understood their value is filled in and returned If all parameters are understood their values are filled in and
in the response message body. returned in the response message body.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
Content-Type: text/parameters Content-Type: text/parameters
skipping to change at page 88, line 4 skipping to change at page 89, line 4
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a message body. It is the method MAY also be used without a message body. It is the
RECOMMENDED method to use in request sent for the sole purpose of RECOMMENDED method to be used in arequest sent for the sole purpose
updating the keep-alive timer. If this request is successful, i.e. a of updating the keep-alive timer. If this request is successful,
200 OK response is received, then the keep-alive timer has been i.e. a 200 OK response is received, then the keep-alive timer has
updated. Any non-required header present in such a request may or been updated. Any non-required header present in such a request may
may not been processed. To allow a client to determine if any such or may not been processed. To allow a client to determine if any
header has been processed, it is necessary to use a feature tag and such header has been processed, it is necessary to use a feature tag
the Require header. Due to this reason it is RECOMMENDED that any and the Require header. Due to this reason it is RECOMMENDED that
parameters are sent in the body, rather than using any header. any parameters are sent in the body, rather than using any header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) MUST be used. In the case a parameter is (Parameter Not Understood) MUST be used. In the case a parameter is
not allowed to change, the error code is 458 (Parameter Is Read- not allowed to change, the error code is 458 (Parameter Is Read-
skipping to change at page 89, line 18 skipping to change at page 90, line 18
Session: iixT43KLc Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Session: iixT43KLc Session: iixT43KLc
Server: PhonyServer 1.0 Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
13.10. REDIRECT 13.10. REDIRECT
The REDIRECT method is issued by a server to inform a client that the The REDIRECT method is issued by a server to inform a client that the
service provided will be terminated and where a corresponding service service provided will be terminated and where a corresponding service
can be provided instead. This happens for different reasons. One is can be provided instead. This may happen for different reasons. One
that the server is being administrated such that it must stop is that the server is being administrated such that it must stop
providing service. Thus the client is required to connect to another providing service. Thus the client is required to connect to another
server location to access the resource indicated by the Request-URI. server location to access the resource indicated by the Request-URI.
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 16.50) to inform the client of the reason for the request. (Section 16.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow a server administrator to do a The intention here is to allow a server administrator to do a
controlled shutdown of the RTSP server. That requires sufficient controlled shutdown of the RTSP server. That requires sufficient
time to inform all entities having associated state with the server time to inform all entities having associated state with the server
and for them to perform a controlled migration from this server to a and for them to perform a controlled migration from this server to a
skipping to change at page 91, line 12 skipping to change at page 92, line 12
synchronized with the server, the server MUST include a Date header synchronized with the server, the server MUST include a Date header
in the request. The client should have before the redirection time- in the request. The client should have before the redirection time-
line terminated the session and close the control connection. The line terminated the session and close the control connection. The
server MAY simple cease to provide service when the deadline time has server MAY simple cease to provide service when the deadline time has
been reached, or it may issue TEARDOWN requests to the remaining been reached, or it may issue TEARDOWN requests to the remaining
sessions. sessions.
If the REDIRECT request times out following the rules in Section 10.4 If the REDIRECT request times out following the rules in Section 10.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuses to respond to a REDIRECT request. misbehaving clients that refuse to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header can be Note: The media resource indicated by the Location header can be
identical, slightly different or totally different. This is the identical, slightly different or totally different. This is the
skipping to change at page 93, line 17 skipping to change at page 94, line 17
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Date: Thu, 05 Jun 1997 18:57:18 GMT Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=0.2, Unmutable, Unlimited Media-Properties: Random-Access=0.2, Immutable, Unlimited
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0 C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: Thu, 05 Jun 1997 18:57:19 GMT Date: Thu, 05 Jun 1997 18:57:19 GMT
skipping to change at page 104, line 29 skipping to change at page 105, line 29
| | | | | | | | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R | | PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | | | | | | | |
| REDIRECT | S -> C | P,S | RDR | | | REDIRECT | S -> C | P,S | RDR | |
| | | | | | | | | | | |
| SETUP | C -> S | S | STP | | | SETUP | C -> S | S | STP | |
| | | | | | | | | | | |
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r | | SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | TRD | | | TEARDOWN | C -> S | P,S | TRD | |
| | | | | |
| | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section 5.2. This The general syntax for header fields is covered in Section 5.2. This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
skipping to change at page 118, line 35 skipping to change at page 119, line 35
request-headers from the new request to allow the origin server request-headers from the new request to allow the origin server
to authenticate the new request. to authenticate the new request.
3. If the response includes the "public" cache-control directive, it 3. If the response includes the "public" cache-control directive, it
MAY be returned in reply to any subsequent request. MAY be returned in reply to any subsequent request.
16.8. Bandwidth 16.8. Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change in kilobits per second. The bandwidth available to the client may
during an RTSP session, e.g., due to mobility, congestion, etc. change during an RTSP session, e.g., due to mobility, congestion,
etc.
Example: Example:
Bandwidth: 62360 Bandwidth: 62360
16.9. Blocksize 16.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
skipping to change at page 128, line 35 skipping to change at page 129, line 35
The client SHOULD NOT send the From header field without the user's The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or approval, as it might conflict with the user's privacy interests or
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
16.23. If-Match 16.23. If-Match
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, in both the case where the integrity of the presentation description, independent of how the
it is fetched via means external to RTSP (such as HTTP), or in the presentation description was received. The presentation description
case where the server implementation is guaranteeing the integrity of can be fetched via means external to RTSP (such as HTTP) or via the
the description between the time of the DESCRIBE message and the DESCRIBE message and the SETUP message. In the case of retrieving
SETUP message. By including the MTag given in or with the session the presentation description via RTSP, the server implementation is
description in a in a If-Match header part of the SETUP request, the guaranteeing the integrity of the description between the time of the
client ensures that resources set up are matching the description. A DESCRIBE message and the SETUP message. By including the MTag given
SETUP request with the If-Match header for which the MTag validation in or with the session description in a If-Match header part of the
check fails, MUST response using 412 (Precondition Failed). SETUP request, the client ensures that resources set up are matching
the description. A SETUP request with the If-Match header for which
the MTag validation check fails, MUST response using 412
(Precondition Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
16.24. If-Modified-Since 16.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
skipping to change at page 134, line 16 skipping to change at page 135, line 23
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by a previous request is to be executed in the context created by a previous
request(s). The primary usage of this header is to allow pipelining request(s). The primary usage of this header is to allow pipelining
of SETUP requests so that any additional SETUP request after the of SETUP requests so that any additional SETUP request after the
first one does not need to wait for the session ID to be sent back to first one does not need to wait for the session ID to be sent back to
the requesting agent. The header contains a unique identifier that the requesting agent. The header contains a unique identifier that
is scoped by the persistent connection used to send the requests. is scoped by the persistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding Upon receiving a request with the Pipelined-Requests the responding
agent MUST look up if there exist a binding between this Pipelined- agent MUST look up if there exists a binding between this Pipelined-
Requests identifier for the current persistent connection and an RTSP Requests identifier for the current persistent connection and an RTSP
session ID. If that exists then the received request is processed session ID. If that exists then the received request is processed
the same way as if it did contain the Session header with the looked the same way as if it contained the Session header with the found
up session ID. If there doesn't exist a mapping and no Session session ID. If there does not exist a mapping and no Session header
header is included in the request, the responding agent MUST create a is included in the request, the responding agent MUST create a
binding upon the successful completion of a session creating request, binding upon the successful completion of a session creating request,
i.e. SETUP. If the request failed to create an RTSP session no i.e. SETUP. A binding MUST NOT be created, if the request failed to
binding MUST be created. In case the request contains both a Session create an RTSP session. In case the request contains both a Session
header and the Pipelined-Requests header the Pipelined-Requests MUST header and the Pipelined-Requests header the Pipelined-Requests MUST
be ignored. be ignored.
Note: Based on the above definition at least the first request Note: Based on the above definition at least the first request
containing a new unique Pipelined-Requests will be required to be a containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may include the or request of any type using the RTSP session context may include the
Pipelined-Requests header. Pipelined-Requests header.
When responding to any request that contained the Pipelined-Requests When responding to any request that contained the Pipelined-Requests
header the server MUST include also the Session header when a binding header the server MUST also include the Session header when a binding
to a session context exist. A RTSP agent that knows the session ID to a session context exist. A RTSP agent that knows the session ID
SHOULD NOT use the Pipelined-Requests header in any request and only SHOULD NOT use the Pipelined-Requests header in any request and only
use the Session header. This as the Session identifier is persistent use the Session header. This as the Session identifier is persistent
across transport contexts, like TCP connections, which the Pipelined- across transport contexts, like TCP connections, which the Pipelined-
Requests identifier is not. Requests identifier is not.
It is the RTSP agent sending the request with a Pipelined-Requests The RTSP agent sending the request with a Pipelined-Requests header
header that has the responsibility for using a unique and previously has the responsibility for using a unique and previously unused
unused identifier within the transport context. Currently only TCP identifier within the transport context. Currently only a TCP
connection is defined as such transport context. A server MUST connection is defined as such transport context. A server MUST
delete the Pipelined-Requests identifier and its binding to a session delete the Pipelined-Requests identifier and its binding to a session
upon the termination of that session. RTSP agents are RECOMMENDED to upon the termination of that session. Despite the previous mandate,
despite the previous mandate to not reuse identifiers to allow for RTSP agents are RECOMMENDED to not reuse identifiers to allow for
better error handling and logging. better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
16.33. Proxy-Authenticate 16.33. Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
skipping to change at page 137, line 40 skipping to change at page 139, line 12
accurate response indicating the methods that can be used on the accurate response indicating the methods that can be used on the
target agent via the proxy chain. target agent via the proxy chain.
16.38. Range 16.38. Range
The Range header specifies a time range in PLAY (Section 13.4), PAUSE The Range header specifies a time range in PLAY (Section 13.4), PAUSE
(Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and
PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be
included in GET_PARAMETER requests from the client to the server with included in GET_PARAMETER requests from the client to the server with
only a Range format and no value to request the current media only a Range format and no value to request the current media
position, whether the session is in playing or ready state in the position, whether the session is in Play or Ready state in the
included format. The server SHALL, if supporting the range format, included format. The server SHALL, if supporting the range format,
respond with the current playing point or pause point as the start of respond with the current playing point or pause point as the start of
the range. If an explicit stop point was used in the previous PLAY the range. If an explicit stop point was used in the previous PLAY
request, then that value shall be included as stop point. Note that request, then that value shall be included as stop point. Note that
if the server is currently under any type of media playback if the server is currently under any type of media playback
manipulation affecting the interpretation of Range, like Scale, that manipulation affecting the interpretation of Range, like Scale, that
is also required to be included in any GET_PARAMETER response to is also required to be included in any GET_PARAMETER response to
provide complete information. provide complete information.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
skipping to change at page 142, line 21 skipping to change at page 143, line 33
affected. affected.
The RTP-Info MAY be included in SETUP responses to provide The RTP-Info MAY be included in SETUP responses to provide
synchronization information when changing transport parameters, see synchronization information when changing transport parameters, see
Section 13.3. The RTP-Info header and the Range header MAY be Section 13.3. The RTP-Info header and the Range header MAY be
included in a GET_PARAMETER request from client to server without any included in a GET_PARAMETER request from client to server without any
values to request the current playback point and corresponding. RTP values to request the current playback point and corresponding. RTP
synchronization information. When the RTP-Info header is included in synchronization information. When the RTP-Info header is included in
a Request also the Range header MUST be included (Note, Range header a Request also the Range header MUST be included (Note, Range header
only MAY be used). The server response SHALL include both the Range only MAY be used). The server response SHALL include both the Range
header and the RTP-Info header. If the session is in playing state, header and the RTP-Info header. If the session is in Play state,
then the value of the Range header SHALL be filled in with the then the value of the Range header SHALL be filled in with the
current playback point and with the corresponding RTP-Info values. current playback point and with the corresponding RTP-Info values.
If the server is another state, no values are included in the RTP- If the server is another state, no values are included in the RTP-
Info header. The header is included in PLAY_NOTIFY requests with the Info header. The header is included in PLAY_NOTIFY requests with the
Notify-Reason of end-of-stream to provide RTP information about the Notify-Reason of end-of-stream to provide RTP information about the
end of the stream. end of the stream.
The header can carry the following parameters: The header can carry the following parameters:
url: Indicates the stream URI which for which the following RTP url: Indicates the stream URI which for which the following RTP
skipping to change at page 145, line 19 skipping to change at page 146, line 37
will pick the first media samples or the first random access point will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may prior to the request range. Depending on use case, the client may
have a strong preference. To express this preference and provide the have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that client with information on how the server actually acted on that
preference the Seek-Style header is defined. preference the Seek-Style header is defined.
Seek-Style is a general header that MAY be included in any PLAY Seek-Style is a general header that MAY be included in any PLAY
request to indicate the client's preference for any media stream that request to indicate the client's preference for any media stream that
has random access properties. The server MUST always include the has random access properties. The server MUST always include the
header in any PLAY response for media with random access properties header in any PLAY response for media with random access properties
to indicate what policy was applied. A Server that receives a to indicate what policy was applied. A server that receives a
unknown Seek-Style policy MUST ignore it and select the server unknown Seek-Style policy MUST ignore it and select the server
default policy. A Client receiving an unknown policy MUST ignore it default policy. A client receiving an unknown policy MUST ignore it
and use the Range header and any media synchronization information as and use the Range header and any media synchronization information as
basis to figure out what the server did. basis to determine what the server did.
This specification defines the following seek policies that may be This specification defines the following seek policies that may be
requested: requested (see also Section Section 4.9.1):
RAP: Random Access Point (RAP) is the behavior of requesting the RAP: Random Access Point (RAP) is the behavior of requesting the
server to locate the closest previous random access point that server to locate the closest previous random access point that
exist in the media aggregate and deliver from that. By requesting exist in the media aggregate and deliver from that. By requesting
a RAP media quality will be the best possible as all media will be a RAP, media quality will be the best possible as all media will
delivered from a point where full media state can be established be delivered from a point where full media state can be
in the media decoder. established in the media decoder.
CoRAP: Conditional Random Access Point (CoRAP) is a variant of the CoRAP: Conditional Random Access Point (CoRAP) is a variant of the
above RAP behavior. It is conditioned on that there exist a above RAP behavior. This policy is primarily intended for cases
Random Access Point closer to the requested start point than the where there are larger distance between the random access points
in the media. CoRAP is conditioned on that there is a Random
Access Point closer to the requested start point than to the
current pause point. This policy assumes that the media state current pause point. This policy assumes that the media state
existing prior to the pause is usable if delivery is continued. existing prior to the pause is usable if delivery is continued.
If the client or server knows that this is not the fact the RAP If the client or server knows that this is not the fact the RAP
policy should be used. In other words in most cases when the policy should be used. In other words: in most cases when the
client requests a start point prior to the current pause point a client requests a start point prior to the current pause point, a
valid decoding dependency chain from the media delivered prior to valid decoding dependency chain from the media delivered prior to
the pause and to the requested media unit will not exist. This the pause and to the requested media unit will not exist. If the
policy is primarily intended for cases where there are larger
distance between the random access points in the media. If the
server searched to a random access point the server MUST return server searched to a random access point the server MUST return
the CoRAP policy in the Seek-Style header and adjust the Range the CoRAP policy in the Seek-Style header and adjust the Range
header to reflect the position of the picked RAP. In case the header to reflect the position of the picked RAP. In case the
random access point is further away and the server selects to random access point is further away and the server selects to
continue from the current pause point it MUST include the "Next" continue from the current pause point it MUST include the "Next"
policy in the Seek-Style header and adjust the Range header start policy in the Seek-Style header and adjust the Range header start
point to the current pause point. point to the current pause point.
First-Prior: The first-prior policy will start delivery with the First-Prior: The first-prior policy will start delivery with the
media unit that has a playout time first prior to the requested media unit that has a playout time first prior to the requested
skipping to change at page 148, line 39 skipping to change at page 150, line 10
specified in the form "lower bound - upper bound". The lower bound specified in the form "lower bound - upper bound". The lower bound
value may be smaller or equal to the upper bound. All speeds may not value may be smaller or equal to the upper bound. All speeds may not
be possible to support. Therefore the server MAY modify the be possible to support. Therefore the server MAY modify the
requested values to the closest supported. The actual supported requested values to the closest supported. The actual supported
speed MUST be included in the response. Note, however, that the use speed MUST be included in the response. Note, however, that the use
cases may vary and that Speed value ranges such as 0.7 - 0.8, cases may vary and that Speed value ranges such as 0.7 - 0.8,
0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage.
Example: Example:
Speed: 1.0 - 2.5 Speed: 1.0-2.5
Use of this header changes the bandwidth used for data delivery. It Use of this header changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where delivery of the is meant for use in specific circumstances where delivery of the
presentation at a higher or lower rate is desired. The main use presentation at a higher or lower rate is desired. The main use
cases are buffer operations or local scale operations. Implementors cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate. ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
skipping to change at page 149, line 30 skipping to change at page 150, line 48
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz Supported: bar, blech, baz
16.50. Terminate-Reason 16.50. Terminate-Reason
The Terminate-Reason request header allows the server when sending a The Terminate-Reason request header allows the server when sending a
REDIRECT or TERMINATE request to provide a reason for the session REDIRECT or TEARDOWN request to provide a reason for the session
termination and any additional information. This specification termination and any additional information. This specification
identifies three reasons for Redirections and may be extended in the identifies three reasons for Redirections and may be extended in the
future: future:
Server-Admin: The server needs to be shutdown for some Server-Admin: The server needs to be shutdown for some
administrative reason. administrative reason.
Session-Timeout: A client's session is kept alive for extended Session-Timeout: A client's session is kept alive for extended
periods of time and the server has determined that it needs to periods of time and the server has determined that it needs to
reclaim the resources associated with this session. reclaim the resources associated with this session.
skipping to change at page 150, line 21 skipping to change at page 151, line 37
request. The value of the timestamp is of significance only to the request. The value of the timestamp is of significance only to the
agent and may use any timescale. The responding agent MUST echo the agent and may use any timescale. The responding agent MUST echo the
exact same value and MAY, if it has accurate information about this, exact same value and MAY, if it has accurate information about this,
add a floating point number indicating the number of seconds that has add a floating point number indicating the number of seconds that has
elapsed since it has received the request. The timestamp can be used elapsed since it has received the request. The timestamp can be used
by the agent to compute the round-trip time to the responding agent by the agent to compute the round-trip time to the responding agent
so that it can adjust the timeout value for retransmissions when so that it can adjust the timeout value for retransmissions when
running over a unreliable protocol. It also resolves retransmission running over a unreliable protocol. It also resolves retransmission
ambiguities for unreliable transport of RTSP. ambiguities for unreliable transport of RTSP.
Note that the present specification provides only for reliable
transport of RTSP messages. The Timestamp general-header is
specified in case the protocol is extended in the future to use
unreliable transport.
16.52. Transport 16.52. Transport
The Transport request and response header indicates which transport The Transport request and response header indicates which transport
protocol is to be used and configures its parameters such as protocol is to be used and configures its parameters such as
destination address, compression, multicast time-to-live and destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
A Transport request header MAY contain a list of transport options A Transport request header MAY contain a list of transport options
acceptable to the client, in the form of multiple transport acceptable to the client, in the form of multiple transport
skipping to change at page 152, line 38 skipping to change at page 154, line 12
transmission needs to indicate such capability by including two transmission needs to indicate such capability by including two
full transport-specs with separate parameters for each. full transport-specs with separate parameters for each.
layers: The number of multicast layers to be used for this media layers: The number of multicast layers to be used for this media
stream. The layers are sent to consecutive addresses starting stream. The layers are sent to consecutive addresses starting
at the dest_addr address. If the parameter is not included, it at the dest_addr address. If the parameter is not included, it
defaults to a single layer. defaults to a single layer.
dest_addr: A general destination address parameter that can contain dest_addr: A general destination address parameter that can contain
one or more address specifications. Each combination of one or more address specifications. Each combination of
Protocol/Profile/Lower Transport needs to have the format and protocol/profile/lower transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. Note, only a single containing a host address and port. Note, only a single
destination parameter per transport spec is intended. The destination parameter per transport spec is intended. The
usage of multiple destination to distribute a single media to usage of multiple destination to distribute a single media to
multiple entities is unspecified. multiple entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
skipping to change at page 153, line 13 skipping to change at page 154, line 36
server MUST perform security checks (see Section 21.1) and server MUST perform security checks (see Section 21.1) and
SHOULD log such attempts before allowing the client to direct a SHOULD log such attempts before allowing the client to direct a
media stream to a recipient address not chosen by the server. media stream to a recipient address not chosen by the server.
Implementations cannot rely on TCP as reliable means of client Implementations cannot rely on TCP as reliable means of client
identification. If the server does not allow the host address identification. If the server does not allow the host address
part of the tuple to be set, it MUST return 463 (Destination part of the tuple to be set, it MUST return 463 (Destination
Prohibited). Prohibited).
The host address part of the tuple MAY be empty, for example The host address part of the tuple MAY be empty, for example
":58044", in cases when only destination port is desired to be ":58044", in cases when only destination port is desired to be
specified. Responses to request including the Transport header specified. Responses to requests including the Transport
with a dest_addr parameter SHOULD include the full destination header with a dest_addr parameter SHOULD include the full
address that is actually used by the server. The server MUST destination address that is actually used by the server. The
NOT remove address information present already in the request server MUST NOT remove address information present already in
when responding unless the protocol requires it. the request when responding unless the protocol requires it.
src_addr: A general source address parameter that can contain one or src_addr: A general source address parameter that can contain one or
more address specifications. Each combination of Protocol/ more address specifications. Each combination of protocol/
Profile/Lower Transport needs to have the format and profile/lower transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. containing a host address and port.
This parameter MUST be specified by the server if it transmits This parameter MUST be specified by the server if it transmits
media packets from another address than the one RTSP messages media packets from another address than the one RTSP messages
are sent to. This will allow the client to verify source are sent to. This will allow the client to verify source
address and give it a destination address for its RTCP feedback address and give it a destination address for its RTCP feedback
packets if RTP is used. The address or addresses indicated in packets if RTP is used. The address or addresses indicated in
the src_addr parameter SHOULD be used both for sending and the src_addr parameter SHOULD be used both for sending and
skipping to change at page 157, line 37 skipping to change at page 158, line 46
the responding RTSP agent. In the case where the feature was the responding RTSP agent. In the case where the feature was
specified via the Proxy-Require field (Section 16.35), if there is a specified via the Proxy-Require field (Section 16.35), if there is a
proxy on the path between the client and the server, the proxy MUST proxy on the path between the client and the server, the proxy MUST
send a response message with a status code of 551 (Option Not send a response message with a status code of 551 (Option Not
Supported). The request MUST NOT be forwarded. Supported). The request MUST NOT be forwarded.
See Section 16.41 for a usage example. See Section 16.41 for a usage example.
16.54. User-Agent 16.54. User-Agent
The User-Agent request-header field contains information about the The User-Agent general-header field contains information about the
user agent originating the request. This is for statistical user agent originating the request. This is for statistical
purposes, the tracing of protocol violations, and automated purposes, the tracing of protocol violations, and automated
recognition of user agents for the sake of tailoring responses to recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations. User agents SHOULD include avoid particular user agent limitations. User agents SHOULD include
this field with requests. The field can contain multiple product this field with requests. The field can contain multiple product
tokens and comments identifying the agent and any subproducts which tokens and comments identifying the agent and any subproducts which
form a significant part of the user agent. By convention, the form a significant part of the user agent. By convention, the
product tokens are listed in order of their significance for product tokens are listed in order of their significance for
identifying the application. identifying the application.
skipping to change at page 161, line 11 skipping to change at page 162, line 11
is likely to be combined with the access proxy. Anyway, the is likely to be combined with the access proxy. Anyway, the
functionality of this proxy is usually closely tied into functionality of this proxy is usually closely tied into
understand all aspects of the media transport. understand all aspects of the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that tracks their employees usage of the network. corporations that tracks their employees usage of the network.
This type of proxy can perform its function without inserting This type of proxy can perform its function without inserting
itself or any other node in the media transport. This proxy itself or any other node in the media transport. This proxy
type can also accept unknown methods as it doesn't interfere type can also accept unknown methods as it doesn't interfere
with the clients requests. with the clients' requests.
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificate chains with TLS as RTSP 2.0 allows the client to approve certificate chains
used for connection establishment from a proxy, see Section 19.3.2. used for connection establishment from a proxy, see Section 19.3.2.
However, that trust model may not be suitable for all type of However, that trust model may not be suitable for all type of
deployment, and instead secured sessions do by-pass of the proxies. deployment. In those cases, the secured sessions do by-pass of the
proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters etc may fail in a proxy that protocols or profiles, new parameters etc may fail in a proxy that
isn't maintained. Thus resulting in blocking further development of isn't maintained. This would impede RTSP's future development and
RTSP and its usage. usage.
17.1. Proxies and Protocol Extensions 17.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. Most type of proxies will need to implement any new RTSP extensions. Most types of proxies will need to implement
new method to operate correct in the presence of that extension. New any new method to operate correctly in the presence of that
headers will be possible to introduce without being blocked by extension. New headers can be introduced and will not be blocked by
proxies not yet updated. However, it is important to consider if older proxies. However, it is important to consider if this header
this header and its function is required to be understood by the and its function is required to be understood by the proxy or can be
proxy or can be forwarded. If the header needs to be understood a forwarded. If the header needs to be understood a feature-tag
feature-tag representing the functionality needs to be included in representing the functionality needs to be included in the Proxy-
the Proxy-Require header. Below are guidelines for analysis if the Require header. Below are guidelines for analysis if the header
header needs to be understood. The transport header and its needs to be understood. The transport header and its parameters also
parameters also shows that headers that are extensible and requires shows that headers that are extensible and require correct
correct interpretation in the proxy also requires handling rules. interpretation in the proxy also require handling rules.
When defining a new RTSP header it needs to be considered if RTSP Whether a proxy needs to understand a header is not easy to
proxies are required to understand them to achieve correct determine, as they serve a broad variety of functions. When
functionality. Determining this is not easy as the functionality for evaluating if a header needs to be understood, one can divide the
proxies are widely varied as can be understood from the above list of
functionality. When evaluating this, one can divide the
functionality into three main categories: functionality into three main categories:
Media modifying: The caching and translator proxies are modifying Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request the actual media and therefore needs to understand also request
directed to the server that affects how the media is rendered. directed to the server that affects how the media is rendered.
Thus, this type of proxies needs to also understand the server Thus, this type of proxies needs to also understand the server
side functionality. side functionality.
Transport modifying: The access and the security proxy both need to Transport modifying: The access and the security proxy both need to
understand how the transport is performed, either for opening understand how the transport is performed, either for opening
skipping to change at page 175, line 35 skipping to change at page 176, line 35
"192.0.2.5:4589" "192.0.2.5:4589"
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
Accept-Credentials: User Accept-Credentials: User
P->C: RTSP/2.0 470 Connection Authorization Required P->C: RTSP/2.0 470 Connection Authorization Required
CSeq: 2 CSeq: 2
Connection-Credentials: "rtsps://test.example.org"; Connection-Credentials: "rtsps://test.example.org";
MIIDNTCCAp... MIIDNTCCAp...
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2 CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589" "192.0.2.5:4589"
Accept-Credentials: User "rtsps://test.example.org";sha-256; Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4= dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0 P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2 CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589" "192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org";sha-256; Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4= dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
One implication of this process is that the connection for secured One implication of this process is that the connection for secured
RTSP messages may take significantly more round-trip times for the RTSP messages may take significantly more round-trip times for the
first message. An complete extra message exchange between the proxy first message. A complete extra message exchange between the proxy
connecting to the next hop and the client results because of the connecting to the next hop and the client results because of the
process for approval for each hop. However, after the first message process for approval for each hop. However, if each message contains
exchange the remaining message should not be delayed, if each message the chain of proxies that the requester accepts, the remaining
contains the chain of proxies that the requester accepts. The message exchange should not be delayed. The procedure of including
procedure of including the credentials in each request rather than the credentials in each request rather than building state in each
building state in each proxy, avoids the need for revocation proxy, avoids the need for revocation procedures.
procedures.
20. Syntax 20. Syntax
The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF)
as defined in RFC 5234 [RFC5234]. It uses the basic definitions as defined in RFC 5234 [RFC5234]. It uses the basic definitions
present in RFC 5234. present in RFC 5234.
Please note that ABNF strings, e.g. "Accept", are case insensitive Please note that ABNF strings, e.g. "Accept", are case insensitive
as specified in section 2.3 of RFC 5234. as specified in section 2.3 of RFC 5234.
skipping to change at page 179, line 25 skipping to change at page 180, line 25
LAQUOT = SWS "<" ; left angle quote LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
FLOAT = ["-"] 1*12DIGIT ["." 1*9DIGIT]
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT
20.2. RTSP Protocol Definition 20.2. RTSP Protocol Definition
20.2.1. Generic Protocol elements 20.2.1. Generic Protocol elements
RTSP-IRI = schemes ":" IRI-rest RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
skipping to change at page 182, line 29 skipping to change at page 183, line 29
npt-sec = 1*19DIGIT [ "." 1*9DIGIT ] npt-sec = 1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh = 1*19DIGIT ; any positive number npt-hh = 1*19DIGIT ; any positive number
npt-mm = 1*2DIGIT ; 0-59 npt-mm = 1*2DIGIT ; 0-59
npt-ss = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59
utc-range = "clock" ["=" utc-range-spec] utc-range = "clock" ["=" utc-range-spec]
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time ) utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z" utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT utc-date = 8DIGIT
utc-clock = 6DIGIT [ "." fraction ] utc-clock = 6DIGIT [ "." 1*9DIGIT ]
fraction = 1*9DIGIT
feature-tag = token feature-tag = token
session-id = 1*256( ALPHA / DIGIT / safe ) session-id = 1*256( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value extension-header = header-name HCOLON header-value
header-name = token header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
20.2.2. Message Syntax 20.2.2. Message Syntax
skipping to change at page 185, line 13 skipping to change at page 186, line 13
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) Reason-Phrase = 1*(TEXT-UTF8char / HT / SP)
general-header = Cache-Control general-header = Cache-Control
/ Connection / Connection
/ CSeq / CSeq
/ Date / Date
/ Media-Properties / Media-Properties
/ Media-Range / Media-Range
/ Pipelined-Requests / Pipelined-Requests
/ Proxy-Supported / Proxy-Supported
/ Seek-Style / Seek-Style
/ Server
/ Supported / Supported
/ Timestamp / Timestamp
/ User-Agent
/ Via / Via
/ extension-header / extension-header
request-header = Accept request-header = Accept
/ Accept-Credentials / Accept-Credentials
/ Accept-Encoding / Accept-Encoding
/ Accept-Language / Accept-Language
/ Authorization / Authorization
/ Bandwidth / Bandwidth
/ Blocksize / Blocksize
skipping to change at page 185, line 41 skipping to change at page 186, line 43
/ Range / Range
/ Referrer / Referrer
/ Request-Status / Request-Status
/ Require / Require
/ Scale / Scale
/ Session / Session
/ Speed / Speed
/ Supported / Supported
/ Terminate-Reason / Terminate-Reason
/ Transport / Transport
/ User-Agent
/ extension-header / extension-header
response-header = Accept-Credentials response-header = Accept-Credentials
/ Accept-Ranges / Accept-Ranges
/ Connection-Credentials / Connection-Credentials
/ MTag / MTag
/ Location / Location
/ Proxy-Authenticate / Proxy-Authenticate
/ Public / Public
/ Range / Range
/ Retry-After / Retry-After
/ RTP-Info / RTP-Info
/ Scale / Scale
/ Session / Session
/ Server
/ Speed / Speed
/ Transport / Transport
/ Unsupported / Unsupported
/ Vary / Vary
/ WWW-Authenticate / WWW-Authenticate
/ extension-header / extension-header
message-header = Allow message-header = Allow
/ Content-Base / Content-Base
/ Content-Encoding / Content-Encoding
skipping to change at page 187, line 17 skipping to change at page 188, line 16
cred-info-data = DQ RTSP-REQ-URI DQ SEMI hash-alg SEMI base64 cred-info-data = DQ RTSP-REQ-URI DQ SEMI hash-alg SEMI base64
hash-alg = "sha-256" / extension-alg hash-alg = "sha-256" / extension-alg
extension-alg = token extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ] [ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params] encoding = codings [SEMI accept-params]
codings = content-coding / "*" codings = content-coding / "*"
content-coding = token content-coding = token
Accept-Language = "Accept-Language" HCOLON Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ] language *(COMMA language)
language = language-range [SEMI accept-params] language = language-range [SEMI accept-params]
language-range = language-tag / "*" language-range = language-tag / "*"
language-tag = primary-tag *( "-" subtag ) language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA primary-tag = 1*8ALPHA
subtag = 1*8ALPHA subtag = 1*8ALPHA
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit)) acceptable-ranges = (range-unit *(COMMA range-unit))
range-unit = "NPT" / "SMPTE" / "UTC" / extension-format range-unit = "NPT" / "SMPTE" / "UTC" / extension-format
extension-format = token extension-format = token
Allow = "Allow" HCOLON Method *(COMMA Method) Allow = "Allow" HCOLON Method *(COMMA Method)
skipping to change at page 188, line 36 skipping to change at page 189, line 33
/ "must-revalidate" / "must-revalidate"
/ "proxy-revalidate" / "proxy-revalidate"
/ "max-age" EQUAL delta-seconds / "max-age" EQUAL delta-seconds
/ cache-extension / cache-extension
cache-extension = token [EQUAL (token / quoted-string)] cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*19DIGIT delta-seconds = 1*19DIGIT
Connection = "Connection" HCOLON connection-token Connection = "Connection" HCOLON connection-token
*(COMMA connection-token) *(COMMA connection-token)
connection-token = token connection-token = "close" / token
Connection-Credentials = "Connection-Credentials" HCOLON cred-chain Connection-Credentials = "Connection-Credentials" HCOLON cred-chain
cred-chain = DQ RTSP-REQ-URI DQ SEMI base64 cred-chain = DQ RTSP-REQ-URI DQ SEMI base64
Content-Base = "Content-Base" HCOLON RTSP-URI Content-Base = "Content-Base" HCOLON RTSP-URI
Content-Encoding = "Content-Encoding" HCOLON Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding) content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag) language-tag *(COMMA language-tag)
Content-Length = "Content-Length" HCOLON 1*19DIGIT Content-Length = "Content-Length" HCOLON 1*19DIGIT
skipping to change at page 193, line 14 skipping to change at page 194, line 14
Terminate-Reason = "Terminate-Reason" HCOLON TR-Info Terminate-Reason = "Terminate-Reason" HCOLON TR-Info
TR-Info = TR-Reason *(SEMI TR-Parameter) TR-Info = TR-Reason *(SEMI TR-Parameter)
TR-Reason = "Session-Timeout" TR-Reason = "Session-Timeout"
/ "Server-Admin" / "Server-Admin"
/ "Internal-Error" / "Internal-Error"
/ token / token
TR-Parameter = TR-time / TR-user-msg / generic-param TR-Parameter = TR-time / TR-user-msg / generic-param
TR-time = "time" EQUAL utc-time TR-time = "time" EQUAL utc-time
TR-user-msg = "user-msg" EQUAL quoted-string TR-user-msg = "user-msg" EQUAL quoted-string
Timestamp = "Timestamp" HCOLON timestamp-value LWS [delay] Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay]
timestamp-value = *19DIGIT [ "." *9DIGIT ] timestamp-value = *19DIGIT [ "." *9DIGIT ]
delay = *9DIGIT [ "." *9DIGIT ] delay = *9DIGIT [ "." *9DIGIT ]
Transport = "Transport" HCOLON transport-spec Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec) *(COMMA transport-spec)
transport-spec = transport-id *trns-parameter transport-spec = transport-id *trns-parameter
transport-id = trans-id-rtp / other-trans transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport] trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id ; no LWS is allowed inside transport-id
other-trans = token *("/" token) other-trans = token *("/" token)
skipping to change at page 195, line 15 skipping to change at page 196, line 15
User-Agent = "User-Agent" HCOLON ( product / comment ) User-Agent = "User-Agent" HCOLON ( product / comment )
*(LWS (product / comment)) *(LWS (product / comment))
Vary = "Vary" HCOLON ( "*" / field-name-list) Vary = "Vary" HCOLON ( "*" / field-name-list)
field-name-list = field-name *(COMMA field-name) field-name-list = field-name *(COMMA field-name)
field-name = token field-name = token
Via = "Via" HCOLON via-parm *(COMMA via-parm) Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr via-params = via-ttl / via-maddr
/ via-received / via-branch / via-received / via-extension
/ via-extension
via-ttl = "ttl" EQUAL ttl via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address) via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986> IPv4address = < As defined in RFC 3986>
IPv6address = < As defined in RFC 3986> IPv6address = < As defined in RFC 3986>
via-branch = "branch" EQUAL token
via-extension = generic-param via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot SLASH transport-prot
protocol-name = "RTSP" / token protocol-name = "RTSP" / token
protocol-version = token protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token other-transport = token
sent-by = host [ COLON port ] sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list
20.3. SDP extension Syntax 20.3. SDP extension Syntax
This section defines in ABNF the SDP extensions defined for RTSP. This section defines in ABNF the SDP extensions defined for RTSP.
See Appendix D for the definition of the extensions in text. See Appendix D for the definition of the extensions in text.
control-attribute = "a=control:" *SP RTSP-REQ-Ref control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF
a-range-def = "a=range:" ranges-spec CRLF a-range-def = "a=range:" ranges-spec CRLF
a-mtag-def = "a=mtag:" message-tag CRLF a-mtag-def = "a=mtag:" message-tag CRLF
21. Security Considerations 21. Security Considerations
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] apply and HTTP servers, the security considerations outlined in [H15] apply
also. also.
skipping to change at page 202, line 8 skipping to change at page 203, line 8
22.2. RTSP Methods 22.2. RTSP Methods
22.2.1. Description 22.2.1. Description
What a method is, is described in section Section 13. Extending the What a method is, is described in section Section 13. Extending the
protocol with new methods allow for totally new functionality. protocol with new methods allow for totally new functionality.
22.2.2. Registering New Methods with IANA 22.2.2. Registering New Methods with IANA
A new method MUST be registered through an IETF Standards Action. A new method MUST be registered through an IETF Standards Action.
The reason is that new methods may radically change the protocols The reason is that new methods may radically change the protocol's
behavior and purpose. behavior and purpose.
A specification for a new RTSP method MUST consist of the following A specification for a new RTSP method MUST consist of the following
items: items:
o A method name which follows the ABNF rules for methods. o A method name which follows the ABNF rules for methods.
o A clear specification on what action and response a request with o A clear specification what a request using the method does and
the method will result in. Which directions the method is used, what responses are expected. Which directions the method is used,
C->S or S->C or both. How the use of headers, if any, modifies C->S or S->C or both. How the use of headers, if any, modifies
the behavior and effect of the method. the behavior and effect of the method.
o A list or table specifying which of the registered headers that o A list or table specifying which of the registered headers that
are allowed to use with the method in request or/and response. are allowed to use with the method in request or/and response.
o Describe how the method relates to network proxies. o Describe how the method relates to network proxies.
22.2.3. Registered Entries 22.2.3. Registered Entries
skipping to change at page 226, line 22 skipping to change at page 227, line 22
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=93CB001E; Transport: RTP/AVP;unicast; ssrc=93CB001E;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001" src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=0.02, Unmutable, Unlimited Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678 Session: 12345678
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=A813FC13; Transport: RTP/AVP;unicast; ssrc=A813FC13;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003"; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT Accept-Range: NPT
Media-Properties: Random-Access=0.8, Unmutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=30- Range: npt=30-
Seek-Style: RAP Seek-Style: RAP
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
skipping to change at page 229, line 37 skipping to change at page 230, line 37
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001"; dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001"; src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Unmutable, Unlimited Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003; dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003"; src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13 ssrc=A813FC13
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT Accept-Range: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Unmutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-623.10 Range: npt=0-623.10
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
skipping to change at page 231, line 45 skipping to change at page 232, line 45
CSeq: 1 CSeq: 1
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001" src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public Cache-Control: public
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
Media-Properties: Random-Access=0.02, Unmutable, Unlimited Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059", dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
V->C: RTSP/2.0 200 OK V->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 23456789 Session: 23456789
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059"; dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
src_addr="198.51.100.5:5002"/"198.51.100.5:5003" src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Cache-Control: public Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
Media-Properties: Random-Access=1.2, Unmutable, Unlimited Media-Properties: Random-Access=1.2, Immutable, Unlimited
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 23456789 Session: 23456789
Range: smpte=0:10:00- Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK V->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Session: 23456789 Session: 23456789
skipping to change at page 235, line 23 skipping to change at page 236, line 23
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="198.51.100.5:6970"/"198.51.100.5:6971"; src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
mode="PLAY";ssrc=EAB98712 mode="PLAY";ssrc=EAB98712
CSeq: 2 CSeq: 2
Session: 2034820394 Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Acces=0.5, Unmutable, Unlimited Media-Properties: Random-Acces=0.5, Immutable, Unlimited
C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0 C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: 2034820394
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT Date: 23 Jan 1997 15:35:08 GMT
skipping to change at page 236, line 24 skipping to change at page 237, line 24
description, while the media server M maintains the full description. description, while the media server M maintains the full description.
C->W: GET /sessions.html HTTP/1.1 C->W: GET /sessions.html HTTP/1.1
Host: www.example.com Host: www.example.com
W->C: HTTP/1.1 200 OK W->C: HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
<html> <html>
... ...
<href "Streamed Live Music performance" <a href "rtsp://live.example.com/concert/audio">
src="rtsp://live.example.com/concert/audio"> Streamed Live Music performance </a>
... ...
</html> </html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
skipping to change at page 238, line 39 skipping to change at page 239, line 39
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057"; dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001" src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
Media-Properties: Random-Access=0.8, Unmutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
Appendix B. RTSP Protocol State Machine Appendix B. RTSP Protocol State Machine
The RTSP session state machine describes the behavior of the protocol The RTSP session state machine describes the behavior of the protocol
from RTSP session initialization through RTSP session termination. from RTSP session initialization through RTSP session termination.
The State machine is defined on a per session basis which is uniquely The State machine is defined on a per session basis which is uniquely
identified by the RTSP session identifier. The session may contain identified by the RTSP session identifier. The session may contain
one or more media streams depending on state. If a single media one or more media streams depending on state. If a single media
stream is part of the session it is in non-aggregated control. If stream is part of the session it is in non-aggregated control. If
two or more is part of the session it is in aggregated control. two or more is part of the session it is in aggregated control.
The below state machine is a informative description of the protocols The below state machine is a informative description of the protocols
behavior. In case of ambiguity with the earlier parts of this behavior. In case of ambiguity with the earlier parts of this
specification, the description in the earlier parts take precedence. specification, the description in the earlier parts take precedence.
B.1. States B.1. States
The state machine contains three states, described below. For each The state machine contains three states, described below. For each
state there exist a table which shows which requests and events that state there exist a table which shows which requests and events are
are allowed and if they will result in a state change. allowed and whether they will result in a state change.
Init: Initial state no session exist. Init: Initial state no session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e. sending media stream data in the Play: Session is playing, i.e. sending media stream data in the
direction S->C. direction S->C.
B.2. State variables B.2. State variables
This representation of the state machine needs more than its state to This representation of the state machine needs more than its state to
work. A small number of variables are also needed and is explained work. A small number of variables are also needed and is explained
skipping to change at page 240, line 47 skipping to change at page 241, line 47
be sent. If the response code is a 4xx the session state is be sent. If the response code is a 4xx the session state is
unchanged. A response code of 3rr will result in that the session is unchanged. A response code of 3rr will result in that the session is
ended and its state is changed to Init. A response code of 304 ended and its state is changed to Init. A response code of 304
results in no state change. However, there exist restrictions to results in no state change. However, there exist restrictions to
when a 3rr response may be used. A 5xx response does not result in when a 3rr response may be used. A 5xx response does not result in
any change of the session state, except if the error is not possible any change of the session state, except if the error is not possible
to recover from. A unrecoverable error results in the ending of the to recover from. A unrecoverable error results in the ending of the
session. As it in the general case can't be determined if it was a session. As it in the general case can't be determined if it was a
unrecoverable error or not the client will be required to test. In unrecoverable error or not the client will be required to test. In
the case that the next request after a 5xx is responded with 454 the case that the next request after a 5xx is responded with 454
(Session Not Found) the client knows that the session has ended. (Session Not Found) the client knows that the session has ended. For
any request message that cannot be responded to within the time
defined in Section 10.4, a 100 response must be sent.
The server will timeout the session after the period of time The server will timeout the session after the period of time
specified in the SETUP response, if no activity from the client is specified in the SETUP response, if no activity from the client is
detected. Therefore there exist a timeout event for all states detected. Therefore there exist a timeout event for all states
except Init. except Init.
In the case that NRM = 1 the presentation URI is equal to the media In the case that NRM = 1 the presentation URI is equal to the media
URI or a specified presentation URI. For NRM > 1 the presentation URI or a specified presentation URI. For NRM > 1 the presentation
URI needs to be other than any of the medias that are part of the URI needs to be other than any of the medias that are part of the
session. This applies to all states. session. This applies to all states.
skipping to change at page 242, line 49 skipping to change at page 244, line 4
| | | | | | | | | |
| Timeout | | Init | | | Timeout | | Init | |
| | | | | | | | | |
| RedP | | Init | TEARDOWN of | | RedP | | Init | TEARDOWN of |
| reached | | | session | | reached | | | session |
+-------------+------------------------+---------+------------------+ +-------------+------------------------+---------+------------------+
Table 15: State: Ready Table 15: State: Ready
In the Ready state, see Table 15, some of the actions are depending In the Ready state, see Table 15, some of the actions are depending
on the number of media streams (NRM) in the session, i.e. aggregated on the number of media streams (NRM) in the session, i.e., aggregated
or non-aggregated control. A setup request in the ready state can or non-aggregated control. A SETUP request in the Ready state can
either add one more media stream to the session or, if the media either add one more media stream to the session or, if the media
stream (same URI) already is part of the session, change the stream (same URI) already is part of the session, change the
transport parameters. TEARDOWN is depending on both the Request-URI transport parameters. TEARDOWN is depending on both the Request-URI
and the number of media stream within the session. If the Request- and the number of media stream within the session. If the Request-
URI is the presentations URI the whole session is torn down. If a URI is the presentations URI the whole session is torn down. If a
media URI is used in the TEARDOWN request and more than one media media URI is used in the TEARDOWN request and more than one media
exist in the session, the session will remain and a session header is exist in the session, the session will remain and a session header is
returned in the response. If only a single media stream remains in returned in the response. If only a single media stream remains in
the session when performing a TEARDOWN with a media URI the session the session when performing a TEARDOWN with a media URI the session
is removed. The number of media streams remaining after tearing down is removed. The number of media streams remaining after tearing down
skipping to change at page 245, line 6 skipping to change at page 246, line 6
| | | | removed | | | | | removed |
| | | | | | | | | |
| RedP reached | | Init | TEARDOWN of | | RedP reached | | Init | TEARDOWN of |
| | | | session | | | | | session |
| | | | | | | | | |
| Timeout | | Init | Stop Media | | Timeout | | Init | Stop Media |
| | | | playout | | | | | playout |
+----------------+-----------------------+--------+-----------------+ +----------------+-----------------------+--------+-----------------+
Table 16: State: Play Table 16: State: Play
The Play state table, see Table 16, is the largest. The table The Play state table, see Table 16, contains a number of requests
contains an number of requests that has presentation URI as a that needs a presentation URI (labeled as Prs URI) to work on (i.e.,
prerequisite on the Request-URI, this is due to the exclusion of non- the presentation URI has to be used as the Request-URI). This is due
aggregated stream control in sessions with more than one media to the exclusion of non-aggregated stream control in sessions with
stream. more than one media stream.
To avoid inconsistencies between the client and server, automatic To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request needs to be still remain in Play state. An explicit PAUSE request needs to be
sent to change the state to Ready. It may appear that there exist an sent to change the state to Ready. It may appear that there exist
automatic transitions in "RedP reached" and "PP reached", however, automatic transitions in "RedP reached" and "PP reached". However,
they are requested and acknowledge before they take place. The time they are requested and acknowledged before they take place. The time
at which the transition will happen is known by looking at the range at which the transition will happen is known by looking at the range
header. If the client sends request close in time to these header. If the client sends a request close in time to these
transitions it needs to be prepared for getting error message as the transitions it needs to be prepared for receiving error message, as
state may or may not have changed. the state may or may not have changed.
Appendix C. Media Transport Alternatives Appendix C. Media Transport Alternatives
This section defines how certain combinations of protocols, profiles This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
Transport header's source and destination address parameters Transport header's source and destination address parameters
"src_addr" and "dest_addr". "src_addr" and "dest_addr".
C.1. RTP C.1. RTP
skipping to change at page 254, line 5 skipping to change at page 255, line 5
a=control: trackID=1 a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
setup=active;connection=new setup=active;connection=new
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast; Transport: RTP/AVP/TCP;unicast;
dest_addr=":9"/":9"; dest_addr=":9"/":9";
src_addr="198.51.100.5:53478"/"198.51.100.54091:"; src_addr="198.51.100.5:53478"/"198.51.100:54091";
setup=passive;connection=new;ssrc=93CB001E setup=passive;connection=new;ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=0.8, Unmutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: TCP Connection Establishment x2 C->M: TCP Connection Establishment x2
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=30- Range: npt=30-
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=30-623.10 Range: npt=30-623.10
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C.3. Handling Media Clock Time Jumps in the RTP Media Layer C.3. Handling Media Clock Time Jumps in the RTP Media Layer
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer [RFC3550]. Two cases occur, the first is when a new PLAY media layer [RFC3550]. Two cases occur, the first is when a new PLAY
request replaces an old ongoing request and the new request results request replaces an old ongoing request and the new request results
in a jump in the media. This should produce in the RTP layer a in a jump in the media. This should produce in the RTP layer a
continuous media stream. A client may also directly following a continuous media stream. A client may also directly following a
completed PLAY request perform a new PLAY request. This will result completed PLAY request perform a new PLAY request. This will result
skipping to change at page 278, line 9 skipping to change at page 279, line 9
maintained: maintained:
o [CSeq] See Section 16.19 o [CSeq] See Section 16.19
o [Timestamp] See Section 16.51 o [Timestamp] See Section 16.51
Appendix H. Backwards Compatibility Considerations Appendix H. Backwards Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 with clients or servers being implemented according to RFC 2326
[RFC2326]. Note that there exist no requirement to implement RTSP [RFC2326]. Note that there exists no requirement to implement RTSP
1.0, in fact we recommend against it as it is difficult to do in an 1.0, in fact we recommend against it as it is difficult to do in an
interoperable way. interoperable way.
A server implementing RTSP/2.0 MUST include a RTSP-Version of A server implementing RTSP/2.0 MUST include a RTSP-Version of
RTSP/2.0 in all responses to requests containing RTSP-Version RTSP/2.0 in all responses to requests containing RTSP-Version
RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond
with a RTSP/1.0 response if it chooses to support RFC 2326. If the with a RTSP/1.0 response if it chooses to support RFC 2326. If the
server chooses not to support RFC 2326, it MUST respond with a 505 server chooses not to support RFC 2326, it MUST respond with a 505
(RTSP Version not supported) status code. A server MUST NOT respond (RTSP Version not supported) status code. A server MUST NOT respond
to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0
response. response.
Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP-
Version of 2.0 to determine whether a server supports RTSP/2.0. If Version of 2.0 to determine whether a server supports RTSP/2.0. If
the server responds with either a RTSP-Version of 1.0 or a status the server responds with either a RTSP-Version of 1.0 or a status
code of 505 (RTSP Version not supported), the client will have to use code of 505 (RTSP Version not supported), the client will have to use
RTSP/1.0 requests if it chooses to support RFC 2326. RTSP/1.0 requests if it chooses to support RFC 2326.
H.1. Play Request in Play mode H.1. Play Request in Play State
The behavior in the server when a Play is received in Play mode has The behavior in the server when a Play is received in Play state has
changed (Section 13.4). In RFC 2326, the new PLAY request would be changed (Section 13.4). In RFC 2326, the new PLAY request would be
queued until the current Play completed. Any new PLAY request now queued until the current Play completed. Any new PLAY request now
take effect immediately replacing the previous request. take effect immediately replacing the previous request.
H.2. Using Persistent Connections H.2. Using Persistent Connections
Some server implementations of RFC 2326 maintain a one-to-one Some server implementations of RFC 2326 maintain a one-to-one
relationship between a connection and an RTSP session. Such relationship between a connection and an RTSP session. Such
implementations require clients to use a persistent connection to implementations require clients to use a persistent connection to
communicate with the server and when a client closes its connection, communicate with the server and when a client closes its connection,
skippi