draft-ietf-mmusic-rfc2326bis-38.txt   draft-ietf-mmusic-rfc2326bis-39.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: April 13, 2014 R. Lanphier Expires: July 21, 2014 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
October 10, 2013 January 17, 2014
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-38 draft-ietf-mmusic-rfc2326bis-39
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-layer
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 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2014. This Internet-Draft will expire on July 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 7 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Presentation Description . . . . . . . . . . . . . . . . 13 2.1. Presentation Description . . . . . . . . . . . . . . . . 11
2.2. Session Establishment . . . . . . . . . . . . . . . . . 14 2.2. Session Establishment . . . . . . . . . . . . . . . . . . 12
2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 13
2.4. Session Parameter Manipulations . . . . . . . . . . . . 17 2.4. Session Parameter Manipulations . . . . . . . . . . . . . 15
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 18 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 16
2.6. Session Maintenance and Termination . . . . . . . . . . 20 2.6. Session Maintenance and Termination . . . . . . . . . . . 19
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 21
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 21
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 21
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 30 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . . 27
4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 30 4.4. Media Time Formats . . . . . . . . . . . . . . . . . . . 27
4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . 30 4.4.1. SMPTE Relative Timestamps . . . . . . . . . . . . . . 28
4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 31 4.4.2. Normal Play Time . . . . . . . . . . . . . . . . . . 28
4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . 32 4.4.3. Absolute Time . . . . . . . . . . . . . . . . . . . . 30
4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 33 4.5. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 30
4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . 33 4.6. Message Body Tags . . . . . . . . . . . . . . . . . . . . 31
4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 34 4.7. Media Properties . . . . . . . . . . . . . . . . . . . . 31
4.7.1. Random Access and Seeking . . . . . . . . . . . . . 34 4.7.1. Random Access and Seeking . . . . . . . . . . . . . . 32
4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . 35 4.7.2. Retention . . . . . . . . . . . . . . . . . . . . . . 33
4.7.3. Content Modifications . . . . . . . . . . . . . . . 35 4.7.3. Content Modifications . . . . . . . . . . . . . . . . 33
4.7.4. Supported Scale Factors . . . . . . . . . . . . . . 36 4.7.4. Supported Scale Factors . . . . . . . . . . . . . . . 33
4.7.5. Mapping to the Attributes . . . . . . . . . . . . . 36 4.7.5. Mapping to the Attributes . . . . . . . . . . . . . . 34
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 37 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 37 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 34
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 38 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 35
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 38 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 39 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 40 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 36
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 42 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 44 7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 40
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 46 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 42
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 46 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 42
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 50 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 51 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 51 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 47
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 52 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 48
9.3. Message Body Format Negotiation . . . . . . . . . . . . 53 9.3. Message Body Format Negotiation . . . . . . . . . . . . . 48
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 54 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 49
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 54 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 50
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 55 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 58 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 59 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 60 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 61 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 57
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 62 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 64 11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 60
11.1. Feature Tag: play.basic . . . . . . . . . . . . . . . . 65 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 67 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 68 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 63
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 69 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 64
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 70 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 72 13.3.1. Changing Transport Parameters . . . . . . . . . . . 69
13.3.1. Changing Transport Parameters . . . . . . . . . . . 75 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 76 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 70
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 76 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 75
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 81 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 76
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 82 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 79
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 84 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 79
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 85 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 79
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 85 13.4.7. Playing Live with Recording . . . . . . . . . . . . 80
13.4.7. Playing Live with Recording . . . . . . . . . . . . 86 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 81
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 86 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 81
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 87 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 82
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 88 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 84
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 90 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 85
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 91 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 86
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 92 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 89
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 95 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 89
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 95 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 90
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 96 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 97 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 93
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 99 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 95
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 101 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 97
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 104 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 101
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 107 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 102
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 108 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 16.1. Validation Model . . . . . . . . . . . . . . . . . . . 103
16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 109 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 104
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 111 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 104
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 111 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 104
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 111 16.1.4. Rules for When to Use Message Body Tags and Last-
16.1.4. Rules for When to Use Message Body Tags and Modified Dates . . . . . . . . . . . . . . . . . . . 107
Last-Modified Dates . . . . . . . . . . . . . . . . 113 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 108
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 115 16.2. Invalidation After Updates or Deletions . . . . . . . . 108
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 109
16.2. Invalidation After Updates or Deletions . . . . . . . . 115 17.1. Informational 1xx . . . . . . . . . . . . . . . . . . . 109
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 117 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 109
17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 117 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 110
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 117 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 110
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 117 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 110
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 117 17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 111
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 117 17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 111
17.3.1. 300 . . . . . . . . . . . . . . . . . . . . . . . . 118 17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 111
17.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 118 17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 111
17.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 118 17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 111
17.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 119 17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 112
17.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 119 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 112
17.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 119 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 112
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 119 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 112
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 119 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 113
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 120 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 113
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 120 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 113
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 120 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 113
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 120 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 113
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 120 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 114
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 121 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 114
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 121 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 114
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 121 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 114
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 121 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 114
17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 122 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 115
17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 122 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 115
17.4.13. 413 Request Message Body Too Large . . . . . . . . . 122 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 115
17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 122 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 115
17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 122 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 115
17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 123 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 116
17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 123 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 116
17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 123 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 116
17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 123 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 116
17.4.20. 455 Method Not Valid in This State . . . . . . . . . 123 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 116
17.4.21. 456 Header Field Not Valid for Resource . . . . . . 123 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 116
17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 123 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 116
17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 124 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 116
17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 124 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 117
17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 124 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 117
17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 124 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 117
17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 124 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 117
17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 124 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 117
17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 124 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 117
17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 125 17.4.32. 470 Connection Authorization Required . . . . . . . 118
17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 125 17.4.33. 471 Connection Credentials not accepted . . . . . . 118
17.4.32. 470 Connection Authorization Required . . . . . . . 125 17.4.34. 472 Failure to establish secure connection . . . . . 118
17.4.33. 471 Connection Credentials not accepted . . . . . . 125 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 118
17.4.34. 472 Failure to establish secure connection . . . . . 125 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 118
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 118
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 125 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 118
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 126 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 119
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 126 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 119
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 126 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 119
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 126 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 119
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 126 17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 119
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 127 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 120
17.5.7. 551 Option not supported . . . . . . . . . . . . . . 127 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 131
17.5.8. 553 Proxy Unavailable . . . . . . . . . . . . . . . 127 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 131
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 128 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 132
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 138 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 133
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 139 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 134
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 140 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 134
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 140 18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 135
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 141 18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 135
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 142 18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 136
18.7. Authentication-Info . . . . . . . . . . . . . . . . . . 142 18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 136
18.8. Authorization . . . . . . . . . . . . . . . . . . . . . 142 18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 137
18.9. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 143 18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 139
18.10. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 144 18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 140
18.11. Cache-Control . . . . . . . . . . . . . . . . . . . . . 144 18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 141
18.12. Connection . . . . . . . . . . . . . . . . . . . . . . . 147 18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 141
18.13. Connection-Credentials . . . . . . . . . . . . . . . . . 147 18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 142
18.14. Content-Base . . . . . . . . . . . . . . . . . . . . . . 148 18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 143
18.15. Content-Encoding . . . . . . . . . . . . . . . . . . . . 149 18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 143
18.16. Content-Language . . . . . . . . . . . . . . . . . . . . 149 18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 144
18.17. Content-Length . . . . . . . . . . . . . . . . . . . . . 150 18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 144
18.18. Content-Location . . . . . . . . . . . . . . . . . . . . 150 18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 146
18.19. Content-Type . . . . . . . . . . . . . . . . . . . . . . 151 18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 147
18.20. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 152 18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 148
18.21. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 153 18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 148
18.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 154 18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 149
18.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 155 18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 149
18.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 156 18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 150
18.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 156 18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 150
18.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 156 18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 151
18.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 157 18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 153
18.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 158 18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 158 18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 154
18.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 160 18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 154
18.31. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 161 18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 155
18.32. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 161 18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 155
18.33. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 161 18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 156
18.34. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 162 18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 156
18.35. Proxy-Authentication-Info . . . . . . . . . . . . . . . 163 18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 156
18.36. Proxy-Authorization . . . . . . . . . . . . . . . . . . 163 18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 157
18.37. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 163 18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 158
18.38. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 164 18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 160
18.39. Public . . . . . . . . . . . . . . . . . . . . . . . . . 164 18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 160
18.40. Range . . . . . . . . . . . . . . . . . . . . . . . . . 165 18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 161
18.41. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 167 18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 162
18.42. Request-Status . . . . . . . . . . . . . . . . . . . . . 168 18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 162
18.43. Require . . . . . . . . . . . . . . . . . . . . . . . . 168 18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 164
18.44. Retry-After . . . . . . . . . . . . . . . . . . . . . . 169 18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 165
18.45. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 169 18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 167
18.46. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 171 18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 167
18.47. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 172 18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 168
18.48. Server . . . . . . . . . . . . . . . . . . . . . . . . . 174 18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 169
18.49. Session . . . . . . . . . . . . . . . . . . . . . . . . 174 18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 170
18.50. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 176 18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 170
18.51. Supported . . . . . . . . . . . . . . . . . . . . . . . 177 18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 171
18.52. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 177 18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 178
18.53. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 178 18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 178
18.54. Transport . . . . . . . . . . . . . . . . . . . . . . . 178 18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 179
18.55. Unsupported . . . . . . . . . . . . . . . . . . . . . . 186 18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 179
18.56. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 186 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 180
18.57. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 186 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 180
18.58. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 187 19.1.1. Digest Authentication . . . . . . . . . . . . . . . 181
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 188 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 182
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 188 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 183
19.1.1. Digest Authentication . . . . . . . . . . . . . . . 189 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 184
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 189 19.3.2. User approved TLS procedure . . . . . . . . . . . . 185
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 190 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 192 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 187
19.3.2. User approved TLS procedure . . . . . . . . . . . . 193 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 189
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 190
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 195 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 192
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 197 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 196
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 197 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 205
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 200 21. Security Considerations . . . . . . . . . . . . . . . . . . . 205
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 204 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 206
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 213 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 209
21. Security Considerations . . . . . . . . . . . . . . . . . . . 214 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 210
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 214 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 211
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 217 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 212
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 218 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 213
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 219 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 214
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 221 22.1.2. Registering New Feature-tags with IANA . . . . . . . 214
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 222 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 214
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 222 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 215
22.1.2. Registering New Feature-tags with IANA . . . . . . . 222 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 215
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 222 22.2.2. Registering New Methods with IANA . . . . . . . . . 215
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 223 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 216
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 223 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 216
22.2.2. Registering New Methods with IANA . . . . . . . . . 223 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 216
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 223 22.3.2. Registering New Status Codes with IANA . . . . . . . 216
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 217
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 224 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 217
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 224 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 217
22.3.2. Registering New Status Codes with IANA . . . . . . . 224 22.4.2. Registering New Headers with IANA . . . . . . . . . 217
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 224 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 217
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 224 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 219
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 225 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 219
22.4.2. Registering New Headers with IANA . . . . . . . . . 225 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 219
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 225 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 220
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 227 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 221
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 227 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 221
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 227 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 221
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 228 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 221
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 228 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 222
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 229 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 222
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 229 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 222
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 229 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 222
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 229 22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 223
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 229 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 223
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 230 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 223
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 230 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 223
22.9. Range Header Formats . . . . . . . . . . . . . . . . . . 230 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 223
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 230 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 224
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 231 22.10.2. Terminate-Reason Header Parameters . . . . . . . . 224
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 231 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 225
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 231 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 225
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 231 22.11.2. Registration Rules . . . . . . . . . . . . . . . . 225
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 232 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 225
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 232 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 225
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 232 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 226
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 232 22.12.2. Registration Rules . . . . . . . . . . . . . . . . 226
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 233 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 226
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 233 22.13. Transport Header Registries . . . . . . . . . . . . . . 227
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 233 22.13.1. Transport Protocol Identifier . . . . . . . . . . . 227
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 233 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 228
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 233 22.13.3. Transport Parameters . . . . . . . . . . . . . . . 229
22.13. Transport Header Registries . . . . . . . . . . . . . . 234 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 230
22.13.1. Transport Protocol Identifier . . . . . . . . . . . 234 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 230
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 236 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . 231
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 236 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . 232
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 237 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 233
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 237 22.16. Media Type Registration for text/parameters . . . . . . 234
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 238 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 235
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 240 23.1. Normative References . . . . . . . . . . . . . . . . . . 235
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 240 23.2. Informative References . . . . . . . . . . . . . . . . . 239
22.16. Media Type Registration for text/parameters . . . . . . 241 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 241
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 243 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 241
23.1. Normative References . . . . . . . . . . . . . . . . . . 243 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 245
23.2. Informative References . . . . . . . . . . . . . . . . . 246 A.3. Secured Media Session for on Demand Content . . . . . . . 247
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 250
A.5. Single Stream Container Files . . . . . . . . . . . . . . 254
A.6. Live Media Presentation Using Multicast . . . . . . . . . 256
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 257
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 258
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 259
B.2. State variables . . . . . . . . . . . . . . . . . . . . . 259
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 259
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 260
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 264
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 265
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 265
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 266
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 267
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 269
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 269
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 249 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 271
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 249 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 271
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 253 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 272
A.3. Secured Media Session for on Demand Content . . . . . . 255 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 276
A.4. Media on Demand (Unicast) . . . . . . . . . . . . . . . 258 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 280
A.5. Single Stream Container Files . . . . . . . . . . . . . 262 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 282
A.6. Live Media Presentation Using Multicast . . . . . . . . 264 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 282
A.7. Capability Negotiation . . . . . . . . . . . . . . . . . 265 C.7. Maintaining NPT synchronization with RTP timestamps . . . 282
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 267 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 282
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 267 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 282
B.2. State variables . . . . . . . . . . . . . . . . . . . . 267 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 268 Session . . . . . . . . . . . . . . . . . . . . . . . . . 283
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 268 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 283
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 275 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 284
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 275 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 284
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 275 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 284
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 275 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 286
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 277 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 286
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 277 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 286
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 280 D.1.5. Directionality of media stream . . . . . . . . . . . 287
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 280 D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 287
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 282 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 288
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 282 D.1.8. Connection Information . . . . . . . . . . . . . . . 288
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 282 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 289
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 286 D.2. Aggregate Control Not Available . . . . . . . . . . . . . 289
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 290 D.3. Aggregate Control Available . . . . . . . . . . . . . . . 290
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 292 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 291
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 292 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 292
C.7. Maintaining NPT synchronization with RTP timestamps . . 292 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 292
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 292 E.1. On-demand Playback of Stored Content . . . . . . . . . . 292
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 292 E.2. Unicast Distribution of Live Content . . . . . . . . . . 294
C.10. Usage of SSRCs and the RTCP BYE Message During an E.3. On-demand Playback using Multicast . . . . . . . . . . . 294
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 292 E.4. Inviting an RTSP server into a conference . . . . . . . . 295
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 293 E.5. Live Content using Multicast . . . . . . . . . . . . . . 296
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 294 Appendix F. Text format for Parameters . . . . . . . . . . . . . 296
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 294 Appendix G. Requirements for Unreliable Transport of RTSP . . . 297
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 294 Appendix H. Backwards Compatibility Considerations . . . . . . . 298
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 295 H.1. Play Request in Play State . . . . . . . . . . . . . . . 299
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 296 H.2. Using Persistent Connections . . . . . . . . . . . . . . 299
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 296 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 299
D.1.5. Directionality of media stream . . . . . . . . . . . 296 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 299
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 297 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 300
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 298 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 307
D.1.8. Connection Information . . . . . . . . . . . . . . . 298 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 308
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 299 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 308
D.2. Aggregate Control Not Available . . . . . . . . . . . . 299 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 308
D.3. Aggregate Control Available . . . . . . . . . . . . . . 300
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 301
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 301
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 302
E.1. On-demand Playback of Stored Content . . . . . . . . . . 302
E.2. Unicast Distribution of Live Content . . . . . . . . . . 303
E.3. On-demand Playback using Multicast . . . . . . . . . . . 304
E.4. Inviting an RTSP server into a conference . . . . . . . 304
E.5. Live Content using Multicast . . . . . . . . . . . . . . 305
Appendix F. Text format for Parameters . . . . . . . . . . . . . 307
Appendix G. Requirements for Unreliable Transport of RTSP . . . 308
Appendix H. Backwards Compatibility Considerations . . . . . . . 310
H.1. Play Request in Play State . . . . . . . . . . . . . . . 310
H.2. Using Persistent Connections . . . . . . . . . . . . . . 310
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 311
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 311
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 312
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 319
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 319
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 321
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 322
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-layer 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, similar to the "network remote control" for multimedia servers.
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 by Clients can request information about streaming media from servers 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. 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 DVD players remote control or media completely. The requested media can consist of multiple audio and
players. The requested media can consist of multiple audio and video video streams that are delivered as time-synchronized streams from
streams that are delivered as time-synchronized streams from servers servers to clients.
to clients.
RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and obsoletes that
specification. This protocol is based on RTSP 1.0 but is not specification. This protocol is based on RTSP 1.0 but is not
backwards compatible other than in the basic version negotiation backwards compatible other than in the basic version negotiation
mechanism. The changes are documented in Appendix I. There are many mechanism. The changes are documented in Appendix I. There are many
reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0 but
some of the main ones are: some of the main ones are:
o Most headers that needed to be extensible did not define the o Most headers that needed to be extensible did not define the
allowed syntax, preventing safe deployment of extensions; allowed syntax, preventing safe deployment of extensions;
o The changed behavior of the PLAY method when received in Play o The changed behavior of the PLAY method when received in Play
state; state;
o Changed behavior of the extensibility model and its mechanism; o Changed behavior of the extensibility model and its mechanism;
o The change of syntax for some headers. o The change of syntax for some headers.
In summary, there are so many small details that changing version In summary, there are so many small details that changing version
became necessary to enable clarification and consistent behavior. became necessary to enable clarification and consistent behavior.
Anyone implementing RTSP for a new usage where they have no installed
based of RTSP 1.0 should only implement RTSP 2.0 to avoid having to
deal with RTSP 1.0 inconsistencies.
This document is structured as follows. It begins with an overview This document is structured as follows. It begins with an overview
of the protocol operations and its functions in an informal way. of the protocol operations and its functions in an informal way.
Then a set of definitions of terms used and document conventions is Then a set of definitions of terms used and document conventions is
introduced. It is followed by the actual RTSP 2.0 core protocol introduced. It is followed by the actual RTSP 2.0 core protocol
specification. The appendixes describe and define some specification. The appendixes describe and define some
functionalities that are not part of the core RTSP specification, but functionalities that are not part of the core RTSP specification, but
which are still important to enable some usages. Among them, the RTP which are still important to enable some usages. Among them, the RTP
usage is defined in Appendix C, the Session Description Protocol usage is defined in Appendix C, the Session Description Protocol
(SDP) usage with RTSP is defined in Appendix D, and the text/ (SDP) usage with RTSP is defined in Appendix D, and the text/
skipping to change at page 14, line 30 skipping to change at page 12, line 38
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 (See Section 4.2). resources and aggregates under common control (See Section 4.2).
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for Presentation Description for Presentation 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, which media delivery protocol is used
is used and their particular resource identifiers. The RTSP session and the resource identifiers of the media streams. The RTSP session
is a common context between the client and the server that consists is a common context between the client and the server that consists
of one or more media resources that are to be under common media of one or more media resources that are to be under common media
delivery control. delivery control.
The client creates an RTSP session by sending a 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 "Transport" header
client also includes all the transport parameters necessary to enable (Section 18.54) of the SETUP request, the client also includes all
the media delivery protocol to function in the "Transport" header the transport parameters necessary to enable the media delivery
(Section 18.54). This includes parameters that are pre-established protocol to function. This includes parameters that are pre-
by the presentation description but necessary for any middlebox to established by the presentation description but necessary for any
correctly handle the media delivery protocols. The Transport header middlebox to correctly handle the media delivery protocols. The
in a request may contain multiple alternatives for media delivery in Transport header in a request may contain multiple alternatives for
a prioritized list, which the server can select from. These media delivery in a prioritized list, which the server can select
alternatives are typically based on information in the presentation from. These alternatives are typically based on information in the
description. presentation 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 18.49). The SETUP in the response in the Session header (Section 18.49). The SETUP
response includes a Transport header that specifies which of the response includes a Transport header that specifies which of the
alternatives has 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. Even if a RTSP session contains
referenced by the aggregate control URI, even if the RTSP session only a single media, the RTSP session can be referenced by the
only contains a single media. aggregate control URI.
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 a client- first for the completion of any of them. The client uses a client-
selected identifier in the Pipelined-Requests header (Section 18.33) selected identifier in the Pipelined-Requests header (Section 18.33)
to instruct the server to bind multiple requests together as if they to instruct the server to bind multiple requests together as if they
included the session identifier. included the session identifier.
The SETUP response also provides additional information about the The SETUP response also provides additional information about the
skipping to change at page 15, line 51 skipping to change at page 14, line 12
method (Section 13.6). PLAY also allows for choosing the starting method (Section 13.6). PLAY also allows for choosing the starting
media position from which the server should deliver the media. The media position from which the server should deliver the media. The
positioning is done by using the Range header (Section 18.40) that positioning is done by using the Range header (Section 18.40) that
supports several different time formats: Normal Play Time (NPT) supports several different time formats: Normal Play Time (NPT)
(Section 4.4.2), Society of Motion Picture and Television Engineers (Section 4.4.2), Society of Motion Picture and Television Engineers
(SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3). (SMPTE) Timestamps (Section 4.4.1) and absolute time (Section 4.4.3).
The Range header does further allow the client to specify a position The Range header does further allow the client to specify a position
where delivery should end, thus allowing a specific interval to be where delivery should end, thus allowing a specific interval to be
delivered. delivered.
The support for positioning/searching within a content depends on the The support for positioning/searching within a media content depends
content's media properties. Content exists in a number of different on the content's media properties. Content exists in a number of
types, such as: on-demand, live, and live with simultaneous different 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 18.29). These are expressed using Media-Properties header (Section 18.29). 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 be during the lifetime of the session. While on-demand content will be
provided in full from the beginning, a live stream being recorded provided in full from the beginning, a live stream being recorded
skipping to change at page 17, line 44 skipping to change at page 16, line 4
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 use headers a message body of the appropriate format. One can also use headers
to 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 (Section 18.45) and Range (Section 18.40). combination of RTP-Info (Section 18.45) and Range (Section 18.40).
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 the headers, or parameters and their formats, that can be used. of the 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
(Section 4.5). (Section 4.5).
2.5. Media Delivery 2.5. Media Delivery
The delivery of media to the RTSP client is done with a protocol This document specifies how media is delivered with RTP [RFC3550]
outside of RTSP and this protocol is determined during the session over UDP [RFC0768], TCP [RFC0793] or the RTSP connection. Additional
establishment. This document specifies how media is delivered with protocols may be specified in the future based on demand.
RTP [RFC3550] over UDP [RFC0768], TCP [RFC0793] or the RTSP
connection. Additional 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 response contains information information to function well. The PLAY response contains information
to enable reliable and timely delivery of how a client should to enable reliable and timely delivery of how a client should
synchronize different sources in the different RTP sessions. It also synchronize different sources in the different RTP sessions. It also
provides a mapping between RTP timestamps and the content time scale. provides a mapping between RTP timestamps and the content time scale.
When the server wants to notify the client about the completion of When the server wants to notify the client about the completion of
the media delivery, it sends a PLAY_NOTIFY request to the client. the media delivery, it sends a PLAY_NOTIFY request to the client.
The PLAY_NOTIFY request includes information about the stream end, The PLAY_NOTIFY request includes information about the stream end,
including the last RTP sequence number for each stream, thus enabling including the last RTP sequence number for each stream, thus enabling
skipping to change at page 18, line 51 skipping to change at page 17, line 5
Scale (Section 18.46) is used for fast forward or slow motion control Scale (Section 18.46) is used for fast forward or slow motion control
as it changes the amount of content timescale that should be played as it changes the amount of content timescale that should be played
back per time unit. Scale > 1.0, means fast forward, e.g., Scale=2.0 back per time 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 results in 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 playback. Scale = 1.0 is the default value that is used if no Scale
is specified, i.e., playback at the content's original rate. Scale is specified, i.e., playback at the content's original rate. Scale
values 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 would be 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.
The nature of these media manipulations and when they are needed is The nature of these media manipulations and when they are needed is
highly media-type dependent. Let's consider an example with two highly media-type dependent. Let's consider an example with two
common media types audio and video. common media types audio and 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
skipping to change at page 21, line 25 skipping to change at page 19, line 30
header. header.
The session context is normally terminated by the client sending a The session context is normally terminated by the client sending a
TEARDOWN request (Section 13.7) to the server referencing the TEARDOWN request (Section 13.7) to the server referencing the
aggregated control URI. An individual media resource can be removed aggregated control URI. An individual media resource can be removed
from a session context by a TEARDOWN request referencing that from a session context by a TEARDOWN request referencing that
particular media resource. If all media resources are removed from a particular media resource. If all media resources are removed from a
session context, the session context is terminated. session context, 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 recommended to release the session context server; however, a client is recommended to release the session
when an extended period of time without media delivery activity has context when an extended period of time without media delivery
passed. The client can re-establish the session context if required activity has passed. The client can re-establish the session context
later. What constitutes an extended period of time is dependent on if required later. What constitutes an extended period of time is
the server and its usage. It is recommended that the client dependent on the client, server and their usage. It is recommended
terminates the session before ten times the session timeout value has that the client terminates the session before ten times the session
passed. A server may terminate the session after one session timeout timeout value has passed. A server may terminate the session after
period without any client activity beyond keep-alive. When a server one session timeout period without any client activity beyond keep-
terminates the session context, it does that by sending a TEARDOWN alive. When a server terminates the session context, it does that by
request indicating the reason. sending a TEARDOWN 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 maintenance. This is done by using the REDIRECT method
(Section 13.10). The Terminate-Reason header (Section 18.52) is used (Section 13.10). The Terminate-Reason header (Section 18.52) is used
to indicate when and why. The Location header indicates where it to indicate when and why. The Location header indicates where it
should connect if there is an alternative server available. When the should connect if there is an alternative server available. When the
deadline expires, the server simply stops providing the service. To deadline expires, the server simply stops providing the service. To
achieve a clean closure, the client needs to initiate session achieve a clean closure, the client needs to initiate session
termination prior to the deadline. In case the server has no other termination prior to the deadline. In case the server has no other
skipping to change at page 23, line 12 skipping to change at page 21, line 12
Certain types of protocol manipulations can be done through parameter Certain types of protocol manipulations can be done through parameter
formats using SET_PARAMETER and GET_PARAMETER. formats using SET_PARAMETER and GET_PARAMETER.
3. Document Conventions 3. Document Conventions
3.1. Notational Conventions 3.1. Notational Conventions
Since a few of the definitions are identical to HTTP/1.1, this Since a few of the definitions are identical to HTTP/1.1, this
specification only points to the section where they are defined specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification ([RFC2616]). to Section X.Y of the HTTP/1.1 specification ([RFC2616]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail prose and the Augmented Backus-Naur form (ABNF) described in detail
in [RFC5234]. in [RFC5234].
Indented paragraphs are used to provide informative background and Indented paragraphs are used to provide informative background and
motivation. This is intended to give readers who were not involved motivation. This is intended to give readers who were not involved
with the formulation of the specification an understanding of why with the formulation of the specification an understanding of why
things are the way they are in RTSP. things are the way they are in RTSP.
skipping to change at page 24, line 22 skipping to change at page 22, line 22
source and sink; that is, the sink needs to reproduce the timing source and sink; that is, the sink needs to reproduce the timing
relationship that existed at the source. The most common examples relationship that existed at the source. The most common examples
of continuous media are audio and motion video. Continuous media of continuous media are audio and motion video. Continuous media
can be real-time (interactive or conversational), where there is a can be real-time (interactive or conversational), where there is a
"tight" timing relationship between source and sink, or streaming "tight" timing relationship between source and sink, or streaming
where the relationship is less strict. where the relationship is less strict.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality,
i.e., a feature. i.e., a feature.
IRI: Internationalized Resource Identifier, is the same as a URI, IRI: Internationalized Resource Identifier, is similar to a URI, but
with the exception that it allows characters from the whole allows characters from the whole Universal Character Set (Unicode/
Universal Character Set (Unicode/ISO 10646), rather than the US- ISO 10646), rather than the US-ASCII only. See [RFC3987] for more
ASCII only. See [RFC3987] for more information. information.
Live: Normally used to describe a presentation or session with media Live: Normally used to describe a presentation or session with media
coming from an ongoing event. This generally results in the coming from an ongoing event. This generally results in the
session having an unbound or only loosely defined duration, and session having an unbound or only loosely defined duration, and
sometimes no seek operations are possible. sometimes no seek operations are possible.
Media initialization: Datatype/codec specific initialization. This Media initialization: Datatype/codec specific initialization. This
includes such things as clock rates, color tables, etc. Any includes such things as clock rates, color tables, etc. Any
transport-independent information which is required by a client transport-independent information which is required by a client
for playback of a media stream occurs in the media initialization for playback of a media stream occurs in the media initialization
skipping to change at page 28, line 35 skipping to change at page 26, line 14
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 [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 are case sensitive, with the exception of those The "scheme" and "host" parts of all URIs [RFC3986] and IRIs
parts that [RFC3986] and [RFC3987] define as case-insensitive; for [RFC3987] are case-insensitive. All other parts of RTSP URIs and
example, the scheme and host part. IRIs are case- sensitive, and MUST NOT be case-mapped.
The fragment identifier is used as defined in sections 3.5 and 4.3 of The fragment identifier is used as defined in sections 3.5 and 4.3 of
[RFC3986], i.e., the fragment is to be stripped from the IRI by the [RFC3986], i.e., the fragment is to be stripped from the IRI by the
requester and not included in the request URI. The user agent needs requester and not included in the request URI. The user agent needs
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
skipping to change at page 30, line 12 skipping to change at page 27, line 35
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be used This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of length 8-128 characters. A Session identifiers are strings of length 8-128 characters. A
session identifier MUST be chosen cryptographically random (see session identifier MUST be generated cryptographically random (see
[RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy, [RFC4086]). It is RECOMMENDED that it contains 128 bits of entropy,
i.e., approximately 22 characters from a high quality generator (see i.e., approximately 22 characters from a high quality generator (see
Section 21). However, note that the session identifier does not Section 21). However, note that the session identifier does not
provide any security against session hijacking unless it is kept provide any security against session hijacking unless it is kept
confidential by the client, server and trusted proxies. confidential by the client, server and trusted proxies.
4.4. Media Time Formats 4.4. Media Time Formats
RTSP currently supports three different media time formats defined RTSP currently supports three different media time formats defined
below. Additional time formats may be specified in the future. below. Additional time formats may be specified in the future.
skipping to change at page 31, line 40 skipping to change at page 29, line 16
forward (high positive scale ratio), decrements when in scan reverse forward (high positive scale ratio), decrements when in scan reverse
(negative scale ratio) and is fixed in pause mode. NPT is (negative scale ratio) and is fixed in pause mode. NPT is
(logically) equivalent to SMPTE time codes." (logically) equivalent to SMPTE time codes."
Examples: Examples:
npt=123.45-125 npt=123.45-125
npt=12:05:35.3- npt=12:05:35.3-
npt=now- npt=now-
The syntax is based on ISO 8601 [ISO.8601.2000]. Two different The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the
notations are allowed. The npt-hhmmss notation are using a ISO 8601 time elapsed since presentation start, with two different notations
extended complete representation of the time of the day format allowed:
(Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators
between hours, minutes and seconds (hh:mm:ss). With the exception o The npt-hhmmss notation uses an ISO 8601 extended complete
that it expresses duration since presentation start rather than time representation of the time of the day format (Section 5.3.1.1 of
since midnight and the hour counter is not limited to 0-24 hours, [ISO.8601.2000] ) using colon (":") as separators between hours,
instead up to nineteen (19) digits of hours are allowed. ISO 8601 minutes and seconds (hh:mm:ss). The hour counter is not limited
time format requires all digits to be used for each format, and all to 0-24 hours; up to nineteen (19) digits of hours are allowed.
format required needs to be included, e.g. if one use a hh:mm:ss
format, then that requires two digits for hours, two digits for o In accordance with the requirements of the ISO 8601 time format,
minutes and two digits for second, a time value such as 7 minutes and the hours, minutes, and seconds MUST all be present, with two
0 seconds, is expressed as 00:07:00. The npt-sec notation is digits used for minutes and for seconds, and with a least two
expressing the duration since presentation start in seconds, using digits for hours. An NPT of 7 minutes and 0 seconds is
one to nineteen (19) digits. Both notations allows decimal fractions represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and
of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with 6 seconds is represented as "392:00:06".
the limitation of at maximum of 9 digits and only allowing "." (full
stop) as separator. Due to RTSP 1.0 and the fact that the highest o RTSP 1.0 allowed NPT in the npt-hhmmss notation without any
values are expanded beyond two digits, all implementations MUST allow leading zeros, to ensure that implementations doesn't fail if any
the highest value to be single digit and SHALL NOT send leading zeros implementation follows the RTSP 1.0 format, all implementations
for hours in the npt-hhmmss notation and leading zeros for seconds in are REQUIRED to support receiving NPT values, hours, minutes or
the npt-sec notation. The hours and the seconds in the npt-hhmmss seconds, without leading zeros.
notation SHALL be sent using leading zeros, but receivers SHALL
accept values without leading zeros. o The npt-sec notation expresses the time in seconds, using between
one and nineteen (19) digits.
Both notations allow decimal fractions of seconds as specified in
Section 5.3.1.3 of [ISO.8601.2000], using at most 9 digits, and
allowing only "." (full stop) as the decimal separator.
The npt-sec notation is optimized for automatic generation, the npt- The npt-sec notation is optimized for automatic generation, the npt-
hhmmss notation for consumption by human readers. The "now" constant hhmmss notation for consumption by human readers. The "now" constant
allows clients to request to receive the live feed rather than the allows clients to request to receive the live feed rather than the
stored or time-delayed version. This is needed since neither stored or time-delayed version. This is needed since neither
absolute time nor zero time are appropriate for this case. absolute time nor zero time are appropriate for this case.
4.4.3. Absolute Time 4.4.3. Absolute Time
Absolute time is expressed following a specific types of ISO 8601 Absolute time is expressed following a specific types of ISO 8601
skipping to change at page 36, line 10 skipping to change at page 33, line 43
Time-Progressing: As time progresses new content will become Time-Progressing: As time 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
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also sliding window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.7.4. Supported Scale Factors 4.7.4. Supported Scale Factors
Content often supports only a limited set or range of scales when Content often supports only a limited set or range of scales when
delivering the media.. To enable the client to know what values or delivering the media. To enable the client to know what values or
ranges of scale operations that the whole content or the current ranges of scale operations that the whole content or the current
position supports, a media properties attribute for this is defined position supports, a media properties attribute for this is defined
which contains a list with the values and/or ranges that are which contains a list with the values and/or ranges that are
supported. The attribute is named "Scales". It may be updated at supported. The attribute is named "Scales". The "Scales" attribute
any point in the content due to content consisting of spliced pieces may be updated at any point in the content due to content consisting
or content being dynamically updated by out-of-band mechanisms. of spliced pieces or content being dynamically updated by out-of-band
mechanisms.
4.7.5. Mapping to the Attributes 4.7.5. Mapping to the Attributes
This section shows examples of how one would map the above usages to This section shows examples 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=5.0, Content Modifications: Example of On-demand: Random Access: Random-Access=5.0, Content
Immutable, Retention: Unlimited or Time-Limited. Modifications: Immutable, Retention: Unlimited or Time-Limited.
Dynamic On-demand: Random Access: Random-Access=3.0, Content Example of Dynamic On-demand: Random Access: Random-Access=3.0,
Modifications: Dynamic, Retention: Unlimited or Time-Limited. Content Modifications: Dynamic, Retention: Unlimited or Time-
Limited.
Live: Random Access: No-seeking, Content Modifications: Time- Example of Live: Random Access: No-seeking, Content Modifications:
Progressing, Retention: Time-Duration=0.0 Time-Progressing, Retention: Time-Duration=0.0
Live with Recording: Random Access: Random-Access=3.0, Content Example of Live with Recording: Random Access: Random-Access=3.0,
Modifications: Time-Progressing, Retention: Time-Duration=7200.0 Content Modifications: Time-Progressing, Retention: Time-
Duration=7200.0
5. RTSP Message 5. RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF. UTF-8 encoding RFC 3629 [RFC3629]. Lines MUST be terminated by CRLF.
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 character set switching, but is The ISO 10646 character set avoids character set switching, but is
invisible to the application as long as US-ASCII is being used. This invisible to the application as long as US-ASCII is being used. This
is also the encoding used for RTCP [RFC3550]. is also the encoding used for RTCP [RFC3550].
Requests contain methods, the object the method is operating upon and A request contains a method, the object the method is operating upon,
parameters to further describe the method. Methods are idempotent and parameters to further describe the method. Methods are
unless otherwise noted. Methods are also designed to require little idempotent unless otherwise noted. Methods are also designed to
or no state maintenance at the media server. require little 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 are either requests from client to server, or server to
client, and responses in the reverse direction. Request (Section 7) client, and responses in the reverse direction. Request (Section 7)
and Response (Section 8) messages use a format based on the generic and Response (Section 8) messages use a format based on the generic
message format of RFC 5322 [RFC5322] for transferring bodies (the message format of RFC 5322 [RFC5322] for transferring bodies (the
payload of the message). Both types of messages consist of a start- payload of the message). Both types of messages consist of a start-
line, zero or more header fields (also known as "headers"), an empty line, zero or more header fields (also known as "headers"), an empty
line (i.e., a line with nothing preceding the CRLF) indicating the line (i.e., a line with nothing preceding the CRLF) indicating the
end of the headers, and possibly the data of the message body. The end of the headers, and possibly the data of the message body. The
below ABNF [RFC5234] is for information and the formal message below ABNF [RFC5234] is for information and the formal message
specification is present in Section 20.2.2. specification is present in Section 20.2.2.
skipping to change at page 47, line 8 skipping to change at page 43, line 8
3rr: Redirection - Further action needs to be taken in order to 3rr: Redirection - Further action needs to be taken in order to
complete the request (3rr rather than 3xx is used as 304 is complete the request (3rr rather than 3xx is used as 304 is
excluded, see Section 17.3) excluded, see Section 17.3)
4xx: Client Error - The request contains bad syntax or cannot be 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid 5xx: Server Error - The server failed to fulfill an apparently valid
request request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for RTSP/
RTSP/2.0, and an example set of corresponding Reason-Phrases, are 2.0, and an example set of corresponding Reason-Phrases, are
presented in Table 4. The reason phrases listed here are only presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 affecting the protocol. Note that RTSP adopts most HTTP/1.1
[RFC2616] status codes and adds RTSP-specific status codes starting [RFC2616] status codes and adds RTSP-specific status codes starting
at x50 to avoid conflicts with future HTTP status codes that are at x50 to avoid conflicts with future HTTP status codes that are
desirable to import into RTSP. All these codes are RTSP specific and desirable to import into RTSP. All these codes are RTSP specific and
RTSP has its own registry separate from HTTP for status codes. RTSP has its own registry separate from HTTP for status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
skipping to change at page 47, line 41 skipping to change at page 43, line 41
returned with the response, since that message body is likely to returned with the response, since that message body is likely to
include human-readable information which will explain the unusual include human-readable information which will explain the unusual
status. status.
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
| Code | Reason | Method | | Code | Reason | Method |
+------+---------------------------------+--------------------------+ +------+---------------------------------+--------------------------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | | | | | |
| | | |
| 200 | OK | all | | 200 | OK | all |
| | | | | | | |
| | | | | | | |
| | | |
| 301 | Moved Permanently | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 303 | reserved | n/a | | 303 | reserved | n/a |
| | | | | | | |
| 304 | Not Modified | all | | 304 | Not Modified | all |
| | | | | | | |
| 305 | Use Proxy | all | | 305 | Use Proxy | all |
| | | |
| | | |
| | | |
| 400 | Bad Request | all | | 400 | Bad Request | all |
| | | | | | | |
| 401 | Unauthorized | all | | 401 | Unauthorized | all |
| | | | | | | |
| 402 | Payment Required | all | | 402 | Payment Required | all |
| | | | | | | |
| 403 | Forbidden | all | | 403 | Forbidden | all |
| | | | | | | |
| 404 | Not Found | all | | 404 | Not Found | all |
| | | | | | | |
skipping to change at page 49, line 29 skipping to change at page 45, line 33
| 470 | Connection Authorization | all | | 470 | Connection Authorization | all |
| | Required | | | | Required | |
| | | | | | | |
| 471 | Connection Credentials not | all | | 471 | Connection Credentials not | all |
| | accepted | | | | accepted | |
| | | | | | | |
| 472 | Failure to establish secure | all | | 472 | Failure to establish secure | all |
| | connection | | | | connection | |
| | | | | | | |
| | | | | | | |
| | | |
| 500 | Internal Server Error | all | | 500 | Internal Server Error | all |
| | | | | | | |
| 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 |
| | | | | | | |
skipping to change at page 50, line 42 skipping to change at page 46, line 42
| | | | | |
| WWW-Authenticate | Section 18.58 | | WWW-Authenticate | Section 18.58 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header 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. A 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 can be given the semantics of response-header if all parties
in the communication recognize them to be a response-header. in the communication recognize them to be a response-header.
Unrecognized headers in responses are treated as message-body headers Unrecognized headers in responses MUST be ignored.
and hence MUST be ignored.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body, if not Some Request and Response messages include 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 the content data itself (see also The message body consists of the content data itself (see also
Section 5.3). Section 5.3).
The SET_PARAMETER and GET_PARAMETER requests and responses, and the The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification MAY have a message DESCRIBE response as defined by this specification can have a message
body; the purpose of the message body is defined in each case. All body; the purpose of the message body is defined in each case. All
4xx and 5xx responses MAY also have a message body to carry 4xx and 5xx responses MAY also have a message body to carry
additional response information. Generally a message body MAY be additional response information. Generally a message body MAY be
attached to any RTSP 2.0 request or response, but the content of the attached to any RTSP 2.0 request or response, but the content of the
message body MAY be ignored by the receiver. Extensions to this message body MAY be ignored by the receiver. Extensions to this
specification can specify the purpose and content of message bodies, specification can specify the purpose and content of message bodies,
including requiring their inclusion. including requiring their inclusion.
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
skipping to change at page 52, line 45 skipping to change at page 48, line 17
9.2. Message Body 9.2. Message Body
An RTSP message with a message body MUST include the Content-Type and An RTSP message with a 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
header fields Content-Type and Content-Encoding. header fields Content-Type and Content-Encoding.
Content-Type specifies the media type of the underlying data. Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is compression, that are a property of the requested resource. The
no default encoding. default encoding is 'identity', i.e. no transformation of the message
body.
The Content-Length of a message is the length of the content, The Content-Length of a message is the length of the content,
measured in octets. measured in octets.
9.3. Message Body Format Negotiation 9.3. Message Body Format Negotiation
The content format of the message body is provided using the Content- The content format of the message body is provided using the Content-
Type header (Section 18.19). To enable the responder of a request to Type header (Section 18.19). To enable the responder of a request to
determine which media type it should use, the requestor may include determine which media type it should use, the requestor may include
the Accept header (Section 18.1) in a request to identify supported the Accept header (Section 18.1) in a request to identify supported
skipping to change at page 54, line 9 skipping to change at page 48, line 50
The formats supported and their negotiation is done individually on a The formats supported and their negotiation is done individually on a
per method and direction (request or response body) direction. per method and direction (request or response body) direction.
Requirements on supporting particular media types for use as message Requirements on supporting particular media types for use as message
bodies in requests and response SHALL also be specified on per method bodies in requests and response SHALL also be specified on per method
and direction basis. and direction basis.
10. Connections 10. Connections
RTSP Messages are transferred between RTSP agents and proxies using a RTSP Messages are transferred between RTSP agents and proxies using a
transport connection. This transport connection uses TCP or TCP/TLS. transport connection. This transport connection uses TCP or TCP/TLS.
This transport connection is referred to as the connection or This transport connection is referred to as the 'connection' or 'RTSP
possibly RTSP connection within this document. connection' within this document.
RTSP requests can be transmitted using the two different connection RTSP requests can be transmitted using the two different connection
scenarios listed below: scenarios listed below:
o persistent - a transport connection is used for several request/ o persistent - a transport connection is used for several request/
response transactions; response transactions;
o transient - a transport connection is used for a single request/ o transient - a transport connection is used for each single request
response transaction. /response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests MUST NOT be sent to multicast groups since no RTSP requests MUST NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
skipping to change at page 56, line 16 skipping to change at page 51, line 9
a persistent connection for the initial SETUP and PLAY message a persistent connection for the initial SETUP and PLAY message
exchanges in a session and then close the connection. Later, when exchanges in a session and then close the connection. Later, when
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 MAY use one connection to handle multiple RTSP sessions An RTSP agent MAY use one connection to handle multiple RTSP sessions
on the same server. The RTSP agent SHALL NOT use more than one on the same server. The RTSP agent SHALL NOT use more than one
connection per RTSP session at any given point. connection per RTSP session at any given point.
Using a single connection for multiple RTSP session saves Having only one connection in use at any time avoids confusion on
which connection any server to client requests shall be sent on.
Using a single connection for multiple RTSP session also saves
complexity by enabling the server to maintain less state about its complexity by enabling the server to maintain less state about its
connection resources on the server. Not using more than one connection resources on the server. Not using more than one
connection at a time for a particular RTSP session avoids wasting connection at a time for a particular RTSP session avoids wasting
connection resources and allows the server to track only the most connection resources and allows the server to track only the most
recently used client to server connection for each RTSP session as recently used client to server connection for each RTSP session as
being the currently valid server to client connection. being the currently valid server to client connection.
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 attempts 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
SHALL discard the request directly. SHALL discard the request.
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.
Queuing of server to client requests has been considered. However Queuing of server to client requests has been considered. However
a security issue exists as to how it might be possible to a security issue exists as to how it might be possible to
authorize a client establishing a new connection as being a authorize a client establishing a new connection as being a
skipping to change at page 59, line 41 skipping to change at page 54, line 37
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requester) SHOULD wait for a Similarly, the sender of a request (requester) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 (Continue) response as soon as than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
possible. It SHOULD continue sending a 100 response every 5 seconds possible. It SHOULD continue sending a 100 response every 5 seconds
thereafter until it is ready to send the final response to the thereafter until it is ready to send the final response to the
requester. After sending a 100 response, the receiver MUST send a requester. After sending a 100 response, the responder MUST send a
final response indicating the success or failure of the request. final response indicating the success or failure of the request.
A requester SHOULD wait at least 10 seconds for a response before A requester SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requester SHOULD continue waiting After receiving a 100 response, the requester SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requester MAY assume that the responder receiving any response, the requester MAY assume that the responder
is unresponsive and abort the connection by closing the TCP is unresponsive and abort the connection by closing the TCP
connection. connection.
In cases multiple RTSP sessions share the same transport connection, In cases multiple RTSP sessions share the same transport connection,
abandoning a request and closing the connection may have significant abandoning a request and closing the connection may have significant
impact on those other sessions. First of all, other RTSP requests impact on those other sessions. First of all, other RTSP requests
may have become queued up due to the request taking long time. may have become queued up due to the request taking long time to
Secondly also those sessions loose the possibility to receive server process. Secondly also those sessions loose the possibility to
to client requests. To mitigate that situation the RTSP agent SHOULD receive server to client requests. To mitigate that situation the
establish a new connection and send any queued up and non-responded RTSP client or server SHOULD establish a new connection and send any
requests on this new connection. Secondly, to ensure that the RTSP queued up and non-responded requests on this new connection.
server knows which connection that is valid for a particular RTSP Secondly, to ensure that the RTSP server knows which connection that
session, the RTSP agent SHOULD send a keep-alive request, if no other is valid for a particular RTSP session, the RTSP agent SHOULD send a
request will be sent immediately for that RTSP session, for each RTSP keep-alive request, if no other request will be sent immediately for
session on the old connection. The keep-alive request will normally that RTSP session, for each RTSP session on the old connection. The
be a GET_PARAMETER with a session header to inform the server that keep-alive request will normally be a SET_PARAMETER with a session
this agent cares about this RTSP session. header to inform the server that this agent cares about this RTSP
session.
A requester SHOULD wait longer than 10 seconds for a response if it A requester SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requester is capable of determining the round trip responder. The requester is capable of determining the round trip
time (RTT) of the request/response cycle using the Timestamp header time (RTT) of the request/response cycle using the Timestamp header
(Section 18.53) in any RTSP request. (Section 18.53) in any RTSP request.
10 seconds was chosen for the following reasons. It gives TCP 10 seconds was chosen for the following reasons. It gives TCP
time to perform a couple of retransmissions, even if operating on time to perform a couple of retransmissions, even if operating on
default values. It is short enough that users may not abandon the default values. It is short enough that users may not abandon the
process themselves. However, it should be noted that 10 seconds process themselves. However, it should be noted that 10 seconds
can be aggressive on certain type of networks. The 5 seconds can be aggressive on certain type of networks. The 5 seconds
value for 1xx messages is half the timeout giving a reasonable value for 1xx messages is half the timeout giving a reasonable
chance of successful delivery before timeout happens on the chance of successful delivery before timeout happens on the
requester side. requester side.
10.5. Showing Liveness 10.5. Showing Liveness
The mechanisms for showing liveness of the client is, any RTSP RTSP requires the client to periodically show its liveness to the
request with a Session header, if RTP & RTCP is used an RTCP message, server or the server may terminate any session state. Several
or through any other used media protocol capable of indicating different protocol mechanism includes in their usage a liveness proof
from the client. These mechanisms are; RTSP requests with a Session
header to the server; if RTP & RTCP is used for media data transport
and the transport is established the RTCP message proves liveness; or
through any other used media transport protocol capable of indicating
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 take some time to arrive
reliable protocols, such as TCP, the message may take some time to safely at the receiver, due to packet loss and TCP retransmissions.
arrive safely at the receiver. To show liveness between RTSP To show liveness between RTSP requests being issued to accomplish
requests being issued to accomplish other things, the following other things, the following mechanisms can be used, in descending
mechanisms can be used, in descending order of preference: 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 will RTCP is used to report transport statistics, it will
necessarily also function as a keep-alive. The server can necessarily also function as a keep-alive. The server can
determine the client by network address and port together with determine the client by network address and port together with
the fact that the client is reporting on the server's RTP the fact that the client is reporting on the server's RTP
sender sources (SSRCs). A downside of using RTCP is that it sender sources (SSRCs). A downside of using RTCP is that it
only gives statistical guarantees of reaching the server. only gives statistical guarantees of reaching the server.
However, the probability of a false client timeout is so low However, the probability of a false client timeout is so low
that it can be ignored in most cases. For example, assume a that it can be ignored in most cases. For example, assume a
skipping to change at page 61, line 23 skipping to change at page 56, line 23
Sessions with shorter timeouts, or much higher packet loss, or Sessions with shorter timeouts, or much higher packet loss, or
small RTCP bandwidths SHOULD also implement one or more of the small RTCP bandwidths SHOULD also implement one or more of the
mechanisms below. mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body SET_PARAMETER: When using SET_PARAMETER for keep-alive, a body
SHOULD NOT be included. This method is the RECOMMENDED RTSP SHOULD NOT be included. This method is the RECOMMENDED RTSP
method to use for a request intended only to perform keep- method to use for a request intended only to perform keep-
alive. Support of SET_PARAMETER is mandatory for RTSP Servers alive. Support of SET_PARAMETER is mandatory for RTSP Servers
to ensure clients can use this method. to ensure clients can use this method.
GET_PARAMETER: When using GET_PARAMETER for keep-alive, no body GET_PARAMETER: When using GET_PARAMETER for keep-alive, a body
SHOULD be included. Dependent on implementation support in SHOULD NOT be included. Dependent on implementation support in
server. Use OPTIONS method to determine if there are method server. Use OPTIONS method to determine if there are method
support or simply try. support or simply try.
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 results in bigger perform more unnecessary processing and results 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.
skipping to change at page 63, line 29 skipping to change at page 58, line 29
handle the request, the RTSP agent has to wait before it can send any handle the request, the RTSP agent has to wait before it can send any
new requests to the RTSP server. Any additional request to a new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds. timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or That timer MUST be doubled for each additional failure to connect or
receive response until the value exceeds 30 minutes when the timers receive response until the value exceeds 30 minutes when the timers
mean value may be set to 30 minutes. It is REQUIRED to not set the mean value may be set to 30 minutes. It is REQUIRED to not set the
same value in the timer for each scheduling, but instead to add a same value in the timer for each scheduling, but instead to add a
variation to the mean value, resulting in picking a random value variation to the mean value, resulting in picking a random value
within the range of 0.5 to 1.5 of the mean value. within the range from 0.5 to 1.5 of the mean value.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
skipping to change at page 65, line 44 skipping to change at page 60, line 24
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 features where not supported. Require header where one or more features 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.
11.1. Feature Tag: play.basic 11.1. Feature Tag: play.basic
The play.basic feature tag represents an RTSP implementation offering An implementation supporting all normative parts of this
all the normative RTSP protocol features specified in this specification for the setup and control of playback of media uses the
specification. This specification is both a RTSP core specification feature tag "play.basic" to indicate this support. The appendices
as well providing mechanisms for the setup and control of playback of (starting with letters), are not part of the functionality include in
media. Thus following all normative parts in the main sections (the the feature tag unless the appendix is explicitly specified in a main
ones with numbers), but omitting the appendices (starting with section as being a required appendix.
letters), unless explicitly specified in a main section as being a
required appendix.
Note: This feature tag does not mandate any media delivery Note: This feature tag does not mandate any media delivery
protocol, such as RTP. protocol, such as RTP.
In RTSP 1.0 there was a minimal implementation section. However, In RTSP 1.0 there was a minimal implementation section. However,
that was not consistent with the rest of the specification. So that was not consistent with the rest of the specification. So
rather than making an attempt to explicitly enumerate the features rather than making an attempt to explicitly enumerate the features
for play.basic this specification has to be taken as a whole and for play.basic this specification has to be taken as a whole and
the necessary features normatively defined as being required are the necessary features normatively defined as being required are
included. included.
skipping to change at page 68, line 47 skipping to change at page 62, line 38
| 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 | P | 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. Further it indicates if (P: presentation, S: stream) they operate on. Further it indicates
a server or a client implementation are required (mandatory), if a server or a client implementation are required (mandatory),
recommended or if it is optional to implement the method. recommended or if it is optional to implement the method.
Note on Table 7: GET_PARAMETER is optional. For example, a fully Note on Table 7: GET_PARAMETER is optional. For example, a fully
functional server can be built to deliver media without any functional server can be built to deliver media without any
parameters. However, SET_PARAMETER is required, i.e., mandatory parameters. However, SET_PARAMETER is required, i.e., mandatory
to implement for the server, this is due to its usage for keep- to implement for the server, this is due to its usage for keep-
alive. PAUSE is required because it is the only way of leaving alive. PAUSE is required because it is the only way of leaving
the Play state without terminating the whole session. the Play state without terminating the 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
skipping to change at page 72, line 34 skipping to change at page 66, line 27
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.
The SETUP request for a URI specifies the transport mechanism to be The SETUP request for a 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(s). SETUP can be used in parameters of already set up media stream(s). SETUP can be used in
all three states; Init, and Ready, for both purposes and in PLAY to all 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. The usage of SETUP method in the
usage for the SETUP method which is not specified in this memo: Play state to add a media resource to the session is unspecified
adding a media to a session. Using SETUP to add media to an existing (Section 3.1).
session, when the session is in Play state, is unspecified.
The Transport header, see Section 18.54, specifies the media The Transport header, see Section 18.54, 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 of possible configurations that are offered select a limited number of possible configurations that are offered
to the server to choose from. All transport related parameters SHALL to the server to choose from. All transport related parameters SHALL
skipping to change at page 77, line 46 skipping to change at page 71, line 47
below that the Range header also must be included in the response and below that the Range header also must be included in the response and
that it will carry the pause point in the media, in the case of the that it will carry the pause point in the media, in the case of the
session being in Ready State. Note that this also applies if the session being in Ready State. Note that this also applies if the
pause point or requested start point is at the beginning of the media pause point or requested start point is at the beginning of the media
and a Scale header (Section 18.46) is included with a negative value and a Scale header (Section 18.46) is included with a negative value
(playing backwards). (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 18.47) use. This is done by including the Seek-Style header (Section 18.47)
in the PLAY request. The Seek-Style applied will effect the content in the PLAY request. The Seek-Style applied will affect 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.
skipping to change at page 80, line 24 skipping to change at page 74, line 24
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 change to After playing the desired range, the presentation does NOT change to
the Ready state, media delivery simply stops. A PAUSE request MUST the Ready state, media delivery simply stops. If it is necessary to
be issued to make the stream enter the Ready state. A PLAY request put the stream into the Ready state, a PAUSE request MUST be issued
while the stream is still in the Play state is legal, and can be to do that. A PLAY request while the stream is still in the Play
issued without an intervening PAUSE request. Such a request MUST state is legal, and can be issued without an intervening PAUSE
replace the current PLAY action with the new one requested, i.e., request. Such a request MUST replace the current PLAY action with
being handled in the same way as if as the request was received in the new one requested, i.e., being handled in the same way as if as
Ready state. In the case that the range in Range header has an the request was received in Ready state. In the case that the range
implicit start time ("-endtime"), the server MUST continue to play in Range header has an implicit start time ("-endtime"), the server
from where it currently was until the specified end point. This is MUST continue to play from where it currently was until the specified
useful to change the end to at another point than in the previous end point. This is useful to change the end to at another point than
request. 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-
skipping to change at page 83, line 46 skipping to change at page 77, line 48
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 A common use of a PLAY request while in Play state is changing the
scale of the media, i.e., entering or leaving fast forward or fast scale of the media, i.e., entering or leaving fast forward or fast
rewind. The client can issue an updating PLAY request that is either rewind. The client can issue an updating PLAY request that is either
a continuation or a complete replacement, as discussed above this a continuation or a complete replacement, as discussed above this
section. We give an example of a client that is requesting a fast section. Below is an example of a client that is requesting a fast
forward (scale=2) without giving a stop point and then change from forward (scale=2) without giving a stop point and then change from
fast forward to regular playout (scale = 1). In the second PLAY fast forward to regular playout (scale = 1). In the second PLAY
request the time is set explicitly to be where ever the server request the time is set explicitly to be where ever the server
currently plays out (npt=now-) and the server responds with the currently plays out (npt=now-) and the server responds with the
actual playback point where the new scale actually takes effect actual playback point where the new scale actually takes effect
(npt=2:17:27.144-). (npt=02:17:27.144-).
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034 CSeq: 2034
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 2.0 Scale: 2.0
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: 2034 CSeq: 2034
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=2:17:21.394- Range: npt=02:17:21.394-
Seek-Style: Next Seek-Style: Next
Scale: 2.0
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
[playing in fast forward and now returning to scale = 1] [playing in fast forward and now returning to scale = 1]
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035 CSeq: 2035
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 1.0 Scale: 1.0
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: 2035 CSeq: 2035
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=2:17:27.144- Range: npt=02:17:27.144-
Seek-Style: Next Seek-Style: Next
Scale: 1.0
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
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 18.29): header in the SETUP response by (see also Section 18.29):
skipping to change at page 88, line 13 skipping to change at page 82, line 22
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 18.32) specifies the reason why The Notify-Reason header (see Section 18.32) 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 (see Section 22.8). In case the reasons can be added in the future (see Section 22.8). In case the
client does not understand the reason for the notification it MUST client does not understand the reason for the notification it MUST
respond with a 465 (Notification Reason Unknown) (Section 17.4.30) respond with a 465 (Notification Reason Unknown) (Section 17.4.30)
error code. Servers can send PLAY_NOTIFY with these types: error code. Servers can send PLAY_NOTIFY with these types:
o end-of-stream (see Section 13.5.1); o end-of-stream (see Section 13.5.1);
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).
skipping to change at page 91, line 15 skipping to change at page 85, line 15
A PLAY_NOTIFY request with Notify-Reason header set to media- A PLAY_NOTIFY request with Notify-Reason header set to media-
properties-update MUST NOT carry a message body. properties-update MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: media-properties-update Notify-Reason: media-properties-update
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394 Media-Range: npt=00:00:00-01:37:21.394
Range: npt=1:15:49.873- Range: npt=01:15:49.873-
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate of media time per The server may be forced to change the rate of media time per
playback time when a client requests delivery using a Scale playback time when a client requests delivery using a Scale
skipping to change at page 92, line 33 skipping to change at page 86, line 33
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
MUST NOT carry a message body. MUST NOT carry a message body.
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854 CSeq: 854
Notify-Reason: scale-change Notify-Reason: scale-change
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Media-Properties: Time-Progressing, Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0 Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=0-1:37:21.394 Media-Range: npt=00:00:00-01:37:21.394
Range: npt=1:37:21.394- Range: npt=01:37:21.394-
Scale: 1 Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio" RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545, ssrc=0D12F123:rtptime=2345962545,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
skipping to change at page 95, line 33 skipping to change at page 89, line 33
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
13.7. TEARDOWN 13.7. TEARDOWN
13.7.1. Client to Server 13.7.1. Client to Server
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 can 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. The TEARDOWN request MUST NOT what session the request applies to. The TEARDOWN request MUST NOT
include a Terminate-Reason header. include a Terminate-Reason header.
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 result done in any state (Ready and Play). A successful request MUST result
in that media delivery being immediately halted and the session state in that media delivery being immediately halted and the session state
being 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 can 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
a session returning to non-aggregated control, because it only a session returning to non-aggregated control, because it only
contains a single media after the request's completion. A session contains a single media after the request's 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
response if the session is still extant or has been removed. response if the session is still extant or has been removed.
Example: Example:
skipping to change at page 98, line 28 skipping to change at page 92, line 28
This to ensure that at least one known format for parameters is This to ensure that at least one known format for parameters is
implemented and thus prevent parameter format negotiation failure. implemented and thus prevent parameter format negotiation failure.
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 weren't understood. including a body listing these parameters that weren't understood.
If all parameters are understood their values are filled in and If all parameters are understood their values are filled in and
returned in the response message body. returned in the response message body.
The method MAY also be used without a message body or any header that The method can also be used without a message body or any header that
requests parameters for keep-alive purpose. The keep-alive timer has requests parameters for keep-alive purpose. The keep-alive timer has
been updated for any request that is successful, i.e., a 200 OK been updated for any request that is successful, i.e., a 200 OK
response is received. Any non-required header present in such a response is received. Any non-required header present in such a
request may or may not have been processed. Normally the presence of request may or may not have 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. For this reason it is usually easier if any parameters to be header. For this reason it is usually easier if any parameters to be
retrieved are sent in the body, rather than using any header. retrieved are sent in the body, rather than using any header.
skipping to change at page 100, line 15 skipping to change at page 94, line 15
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. When a parameter is not (Parameter Not Understood) MUST be used. When a parameter is not
allowed to change, the error code is 458 (Parameter Is Read-Only). allowed to change, the error code is 458 (Parameter Is Read-Only).
The response body MUST contain only the parameters that have errors. The response body MUST contain only the parameters that have errors.
Otherwise no body MUST be returned. The response body MUST use the Otherwise, a body MUST NOT be returned. The response body MUST use
media type of the request for the response. the media type of the request for the response.
Note: transport parameters for the media stream MUST only be set with Note: transport parameters for the media stream MUST only be set with
the SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for the Restricting setting transport parameters to SETUP is for the
benefit of firewalls. benefit of firewalls.
The parameters are split in a fine-grained fashion so that there The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic sense to allow the setting of several parameters if an atomic
skipping to change at page 103, line 9 skipping to change at page 97, line 9
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 receive media for the resource identified by the Request- continue to receive media for the resource identified by the Request-
URI will have to establish a new session with the designated host. URI will have to establish a new session with the designated host.
If the URI given in the Location header is a valid resource URI, a If the URI given in the Location header is a valid resource URI, a
client SHOULD issue a DESCRIBE request for the URI. 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
reason why a new DESCRIBE request SHOULD be issued. reason why a new DESCRIBE request SHOULD be issued.
If the Location header contains only a host address, the client MAY If the Location header contains only a host address, the client may
assume that the media on the new server is identical to the media on assume that the media on the new server is identical to the media on
the old server, i.e., all media configuration information from the the old server, i.e., all media configuration information from the
old session is still valid except for the host address. However, the old session is still valid except for the host address. However, the
usage of conditional SETUP using MTag identifiers is RECOMMENDED as a usage of conditional SETUP using MTag identifiers is RECOMMENDED as a
means to verify the assumption. means to verify the assumption.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0 S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
skipping to change at page 106, line 47 skipping to change at page 100, line 30
performs the necessary translation, usually addresses. This performs the necessary translation, usually addresses. This
type of proxy is required to redirect the media to itself or a type of proxy is required to redirect the media to itself or a
controlled gateway that performs the translation before the controlled gateway that performs the translation before the
media can reach the client. media can reach the client.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy requests that the firewalled network, the security proxy requests that the
necessary pinholes in the firewall are opened when a client in necessary pinholes in the firewall are opened when a client in
the protected network wants to access media streams on the the protected network wants to access media streams on the
external side. This proxy can also limit the client's access external side. This proxy can perform its function without
to certain types of content. This proxy can perform its redirecting the media between the server and client. However,
function without redirecting the media between the server and in deployments with private address spaces this proxy is likely
client. However, in deployments with private address spaces to be combined with the access proxy. Anyway, the
this proxy is likely to be combined with the access proxy. functionality of this proxy is usually closely tied into
Anyway, the functionality of this proxy is usually closely tied understanding all aspects of the media transport.
into understanding 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 track their employees usage of the network. corporations that track 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 types of proxies can also be used when using secured All types of proxies can also be used when using secured
skipping to change at page 109, line 49 skipping to change at page 103, line 24
a client. Just as an HTTP cache has to store the content type, a client. Just as an HTTP cache has to store the content type,
content language, and so on for the objects it caches, a media cache content language, and so on for the objects it caches, a media cache
has to store the presentation description. Typically, a cache has to store the presentation description. Typically, a cache
eliminates all transport-references (e.g., multicast information) eliminates all transport-references (e.g., multicast information)
from the presentation description, since these are independent of the from the presentation description, since these are independent of the
data delivery from the cache to the client. Information on the data delivery from the cache to the client. Information on the
encodings remains the same. If the cache is able to translate the encodings remains the same. If the cache is able to translate the
cached media data, it would create a new presentation description cached media data, it would create a new presentation description
with all the encoding possibilities it can offer. with all the encoding possibilities it can offer.
16.1. Validation Model 16.1. Validation Model
When a cache has a stale entry that it would like to use as a When a cache has a stale entry that it would like to use as a
response to a client's request, it first has to check with the origin response to a client's request, it first has to check with the origin
server (or possibly an intermediate cache with a fresh response) to server (or possibly an intermediate cache with a fresh response) to
see if its cached entry is still usable. We call this "validating" see if its cached entry is still usable. This is called "validating"
the cache entry. Since we do not want to have to pay the overhead of the cache entry. To avoid having to pay the overhead of
retransmitting the full response if the cached entry is good, and we retransmitting the full response if the cached entry is good, and at
do not want to pay the overhead of an extra round trip if the cached the same time avoiding to pay the overhead of an extra round trip if
entry is invalid, the RTSP protocol supports the use of conditional the cached entry is invalid, the RTSP protocol supports the use of
methods. conditional methods.
The key protocol features for supporting conditional methods are The key protocol features for supporting conditional methods are
those concerned with "cache validators." When an origin server those concerned with "cache validators." When an origin server
generates a full response, it attaches some sort of validator to it, generates a full response, it attaches some sort of validator to it,
which is kept with the cache entry. When a client (user agent or which is kept with the cache entry. When a client (user agent or
proxy cache) makes a conditional request for a resource for which it proxy cache) makes a conditional request for a resource for which it
has a cache entry, it includes the associated validator in the has a cache entry, it includes the associated validator in the
request. request.
The server then checks that validator against the current validator The server then checks that validator against the current validator
for the requested resource, and, if they match (see Section 16.1.3), for the requested resource, and, if they match (see Section 16.1.3),
it responds with a special status code (usually, 304 (Not Modified)) it responds with a special status code (usually, 304 (Not Modified))
and no message body. Otherwise, it returns a full response and no message body. Otherwise, it returns a full response
(including message body). Thus, we avoid transmitting the full (including message body). Thus, avoiding transmitting the full
response if the validator matches, and we avoid an extra round trip response if the validator matches, and avoiding an extra round trip
if it does not match. if it does not match.
In RTSP, a conditional request looks exactly the same as a normal In RTSP, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special request for the same resource, except that it carries a special
header (which includes the validator) that implicitly turns the header (which includes the validator) that implicitly turns the
method (usually DESCRIBE or SETUP) into a conditional. method (usually DESCRIBE or SETUP) into a conditional.
The protocol includes both positive and negative senses of cache- The protocol includes both positive and negative senses of cache-
validating conditions. That is, it is possible to request either validating conditions. That is, it is possible to request either
that a method be performed if and only if a validator matches or if that a method be performed if and only if a validator matches or if
skipping to change at page 111, line 31 skipping to change at page 105, line 5
Message body tags are described in Section 4.6 Message body tags are described in Section 4.6
16.1.3. Weak and Strong Validators 16.1.3. Weak and Strong Validators
Since both origin servers and caches will compare two validators to Since both origin servers and caches will compare two validators to
decide if they represent the same or different entities, one normally decide if they represent the same or different entities, one normally
would expect that if the message body (i.e., the presentation would expect that if the message body (i.e., the presentation
description) or any associated message body headers changes in any description) or any associated message body headers changes in any
way, then the associated validator would change as well. If this is way, then the associated validator would change as well. If this is
true, then we call this validator a "strong validator." We call true, then this validator is a "strong validator." The Message body
message body (i.e., the presentation description) or any associated (i.e., the presentation description) or any associated message body
message body headers an entity for a better understanding. headers is named an entity for a better understanding.
However, there might be cases when a server prefers to change the However, there might be cases when a server prefers to change the
validator only on semantically significant changes, and not when validator only on semantically significant changes, and not when
insignificant aspects of the entity change. A validator that does insignificant aspects of the entity change. A validator that does
not always change when the resource changes is a "weak validator." not always change when the resource changes is a "weak validator."
Message body tags are normally "strong validators," but the protocol Message body tags are normally "strong validators," but the protocol
provides a mechanism to tag a message body tag as "weak." One can provides a mechanism to tag a message body tag as "weak." One can
think of a strong validator as one that changes whenever the bits of think of a strong validator as one that changes whenever the bits of
an entity changes, while a weak value changes whenever the meaning of an entity changes, while a weak value changes whenever the meaning of
skipping to change at page 113, line 49 skipping to change at page 107, line 17
implementation MAY use a value larger than 60 seconds, if it is implementation MAY use a value larger than 60 seconds, if it is
believed that 60 seconds is too short. believed that 60 seconds is too short.
If a client wishes to perform a sub-range retrieval on a value for If a client wishes to perform a sub-range retrieval on a value for
which it has only a Last-Modified time and no opaque validator, it which it has only a Last-Modified time and no opaque validator, it
MAY do this only if the Last-Modified time is strong in the sense MAY do this only if the Last-Modified time is strong in the sense
described here. described here.
16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates 16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates
We adopt a set of rules and recommendations for origin servers, This document adopt a set of rules and recommendations for origin
clients, and caches regarding when various validator types ought to servers, clients, and caches regarding when various validator types
be used, and for what purposes. ought to be used, and for what purposes.
RTSP origin servers: RTSP origin servers:
o SHOULD send a message body tag validator unless it is not feasible o SHOULD send a message body tag validator unless it is not feasible
to generate one. to generate one.
o MAY send a weak message body tag instead of a strong message body o MAY send a weak message body tag instead of a strong message body
tag, if performance considerations support the use of weak message tag, if performance considerations support the use of weak message
body tags, or if it is unfeasible to send a strong message body body tags, or if it is unfeasible to send a strong message body
tag. tag.
skipping to change at page 117, line 12 skipping to change at page 109, line 37
understand SHOULD invalidate any entities referred to by the Request- understand SHOULD invalidate any entities referred to by the Request-
URI. URI.
17. Status Code Definitions 17. Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. See Table 4 in Where applicable, HTTP status [H10] codes are reused. See Table 4 in
Section 8.1 for a listing of which status codes may be returned by Section 8.1 for a listing of which status codes may be returned by
which requests. All error messages, 4xx and 5xx MAY return a body which requests. All error messages, 4xx and 5xx MAY return a body
containing further information about the error. containing further information about the error.
17.1. Success 1xx 17.1. Informational 1xx
17.1.1. 100 Continue 17.1.1. 100 Continue
The client SHOULD continue with its request. This interim response The client SHOULD continue with its request. This interim response
is used to inform the client that the initial part of the request has is used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The been received and has not yet been rejected by the server. The
client SHOULD continue by sending the remainder of the request or, if client SHOULD continue by sending the remainder of the request or, if
the request has already been completed, ignore this response. The the request has already been completed, ignore this response. The
server MUST send a final response after the request has been server MUST send a final response after the request has been
completed. completed.
skipping to change at page 117, line 48 skipping to change at page 110, line 29
as it is not used for redirection and instead the "3rr" notation is as it is not used for redirection and instead the "3rr" notation is
used. The 304 response code appears here, rather than a 2xx response used. The 304 response code appears here, rather than a 2xx response
code which would have been appropriate, this as 304 has been used code which would have been appropriate, this as 304 has been used
also in RTSP 1.0 [RFC2326]. also in RTSP 1.0 [RFC2326].
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the client. Mechanisms to determine topological proximity are beyond the
scope of this specification. scope of this specification.
A 3rr code MAY be used to respond to any request. It is RECOMMENDED A 3rr code MAY be used to respond to any request. The Location
that they are used if necessary before a session is established, header MUST be included in any 3rr response. It is RECOMMENDED that
i.e., in response to DESCRIBE or SETUP. However, in cases where a they are used if necessary before a session is established, i.e., in
server is not able to send a REDIRECT request to the client, the response to DESCRIBE or SETUP. However, in cases where a server is
server MAY need to resort to using 3rr responses to inform a client not able to send a REDIRECT request to the client, the server MAY
with an established session about the need for redirecting the need to resort to using 3rr responses to inform a client with an
session. If a 3rr response is received for a request in relation to established session about the need for redirecting the session. If a
an established session, the client SHOULD send a TEARDOWN request for 3rr response is received for a request in relation to an established
the session, and MAY reestablish the session using the resource session, the client SHOULD send a TEARDOWN request for the session,
indicated by the Location. and MAY reestablish the session using the resource indicated by the
Location.
If the Location header is used in a response it MUST contain an If the Location header is used in a response it MUST contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI MUST NOT only contain the host name. to, the URI MUST NOT only contain the host name.
In the event that an unknown 3rr status code is received, the agent
SHOULD behave as if a 302 response code had been received
(Section 17.3.3).
17.3.1. 300 17.3.1. 300
This response code is not used in RTSP 2.0. In the event that an This response code is not used in RTSP 2.0.
unknown 3rr status code is received, the agent SHOULD behave as if a
302 response code had been received (Section 17.3.3).
17.3.2. 301 Moved Permanently 17.3.2. 301 Moved Permanently
The requested resource is moved permanently and resides now at the The requested resource is moved permanently and resides now at the
URI given by the Location header. The user client SHOULD redirect URI given by the Location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
17.3.3. 302 Found 17.3.3. 302 Found
The requested resource resides temporarily at the URI given by the The requested resource resides temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. This response is intended to be used for many types
response. This response is intended to be used for many types of of temporary redirects; e.g., load balancing. It is RECOMMENDED that
temporary redirects; e.g., load balancing. It is RECOMMENDED that
the server set the reason phrase to something more meaningful than the server set the reason phrase to something more meaningful than
"Found" in these cases. The user client SHOULD redirect "Found" in these cases. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. message-body.
This example shows a client being redirected to a different server: This example shows a client being redirected to a different server:
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
skipping to change at page 128, line 34 skipping to change at page 120, line 48
| 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 | | | | 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: All error messages for statuses 4xx and 5xx are r=response. Note: All error messages for statuses 4xx and 5xx are
allowed to carry a body allowed to carry 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
meaning, and usage. The syntax definition for header fields are meaning, and usage. The syntax definition for header fields are
present in Section 20.2.3. Throughout this section, we use [HX.Y] to present in Section 20.2.3. Throughout this section, [HX.Y] is used
reference Section X.Y of the current HTTP/1.1 specification RFC 2616 to reference Section X.Y of the HTTP/1.1 specification RFC 2616
[RFC2616]. Examples of each header field are given. [RFC2616]. Examples of each header field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Table 9, Table 10, Table 11, and processing is summarized in Table 9, Table 10, Table 11, and
Table 12. Table 12.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
skipping to change at page 130, line 37 skipping to change at page 122, line 47
the Client/Server MUST ignore the header field in the response. the Client/Server MUST ignore the header field in the response.
An RTSP agent MUST ignore extension headers that are not understood. An RTSP agent MUST ignore extension headers that are not understood.
The From and Location header fields contain a URI. If the URI The From and Location header fields contain a URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double contains a comma, or semicolon, the URI MUST be enclosed in double
quotes ("). Any URI parameters are contained within these quotes. quotes ("). Any URI parameters are contained within these quotes.
If the URI is not enclosed in double quote, any semicolon-delimited If the URI is not enclosed in double quote, any semicolon-delimited
parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +-------------------+------+------+----+----+-----+-----+-----+-----+
| Header | Where | Pro | DE | OPT | STP | PLY | PSE | TRD | | Header | Wher | Prox | DE | OP | STP | PLY | PSE | TRD |
| | | xy | S | | | | | | | | e | y | S | T | | | | |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +-------------------+------+------+----+----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - | | Accept | R | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Credentia | R | rm | o | o | o | o | o | o | | Accept- | R | rm | o | o | o | o | o | o |
| ls | | | | | | | | | | Credentials | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Accept-Encoding | R | r | o | - | - | - | - | - | | Accept-Encoding | R | r | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Language | R | r | o | - | - | - | - | - | | Accept-Language | R | r | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | G | r | - | - | m | - | - | - | | Accept-Ranges | G | r | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | 456 | r | - | - | - | m | - | - | | Accept-Ranges | 456 | r | - | - | - | m | - | - |
| Allow | r | am | c | c | c | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Allow | r | am | c | c | c | - | - | - |
| Allow | 405 | am | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Allow | 405 | am | m | m | m | m | m | m |
| Authentication-I | r | | o | o | o | o | o | o/- | | | | | | | | | | |
| nfo | | | | | | | | | | Authentication- | r | | o | o | o | o | o | o/- |
| | | | | | | | | | | Info | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Authorization | R | | o | o | o | o | o | o |
| Bandwidth | R | | o | o | o | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Bandwidth | R | | o | o | o | o | - | - |
| Blocksize | R | | o | - | o | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Blocksize | R | | o | - | o | o | - | - |
| Cache-Control | G | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Cache-Control | G | r | o | - | o | - | - | - |
| Connection | G | ad | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Connection | G | ad | o | o | o | o | o | o |
| Connection-Crede | 470,4 | ar | o | o | o | o | o | o | | | | | | | | | | |
| ntials | 07 | | | | | | | | | Connection- | 470, | ar | o | o | o | o | o | o |
| | | | | | | | | | | Credentials | 407 | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Base | r | | o | - | - | - | - | - |
| Content-Base | 4xx,5 | | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Base | 4xx, | | o | o | o | o | o | o |
| | | | | | | | | | | | 5xx | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Encoding | R | r | - | - | - | - | - | - |
| Content-Encoding | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Encoding | r | r | o | - | - | - | - | - |
| Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Encoding | 4xx, | r | o | o | o | o | o | o |
| | | | | | | | | | | | 5xx | | | | | | | |
| Content-Language | R | r | - | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Language | R | r | - | - | - | - | - | - |
| Content-Language | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Language | r | r | o | - | - | - | - | - |
| Content-Language | 4xx,5 | r | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Language | 4xx, | r | o | o | o | o | o | o |
| | | | | | | | | | | | 5xx | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | 4xx,5 | r | * | * | * | * | * | * | | | | | | | | | | |
| | xx | | | | | | | | | Content-Length | 4xx, | r | * | * | * | * | * | * |
| | | | | | | | | | | | 5xx | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | 4xx,5 | r | o | o | o | o | o | o | | | | | | | | | | |
| | xx | | | | | | | | | Content-Location | 4xx, | r | o | o | o | o | o | o |
| Content-Type | r | r | * | - | - | - | - | - | | | 5xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Content-Type | 4xx,5 | ar | * | * | * | * | * | * | | Content-Type | r | r | * | - | - | - | - | - |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Type | 4xx, | ar | * | * | * | * | * | * |
| CSeq | Gc | rm | m | m | m | m | m | m | | | 5xx | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Date | G | am | o/ | o/* | o/* | o/* | o/* | o/* | | CSeq | Gc | rm | m | m | m | m | m | m |
| | | | * | | | | | | | | | | | | | | | |
| | | | | | | | | | | Date | G | am | o/ | o/ | o/* | o/* | o/* | o/* |
| Expires | r | r | o | - | o | - | - | - | | | | | * | * | | | | |
| | | | | | | | | | | | | | | | | | | |
| From | R | r | o | o | o | o | o | o | | Expires | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| If-Match | R | r | - | - | o | - | - | - | | From | R | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| If-Modified-Sinc | R | r | o | - | o | - | - | - | | If-Match | R | r | - | - | o | - | - | - |
| e | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | If-Modified-Since | R | r | o | - | o | - | - | - |
| If-None-Match | R | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | If-None-Match | R | r | o | - | o | - | - | - |
| Last-Modified | r | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Last-Modified | r | r | o | - | o | - | - | - |
| Location | 3rr | | o | o | o | o | o | o | | | | | | | | | | |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ | Location | 3rr | | o | o | o | o | o | o |
+-------------------+------+------+----+----+-----+-----+-----+-----+
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD | | Header | Where | Pro | DE | OP | ST | PLY | PSE | TRD |
| | | xy | S | T | P | | | | | | | xy | S | T | P | | | |
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
| Media- | G | | - | - | m | m | m | - | | Media- | G | | - | - | m | m | m | - |
| Properties | | | | | | | | | | Properties | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Media-Range | G | | - | - | m | m | m | - | | Media-Range | G | | - | - | m | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| MTag | r | r | o | - | o | - | - | - | | MTag | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Pipelined-Reques | G | amd | - | o | o | o | o | o | | Pipelined- | G | amd | - | o | o | o | o | o |
| ts | | r | | | | | | | | Requests | | r | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy-Authentica | r | amd | o | o | o | o | o | o/- | | Proxy- | r | amd | o | o | o | o | o | o/- |
| tion-Info | | r | | | | | | | | Authentication- | | r | | | | | | |
| Info | | | | | | | | |
| | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o | | Proxy- | R | rd | o | o | o | o | o | o |
| Authorization | | | | | | | | | | Authorization | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Require | R | ar | o | o | o | o | o | o | | Proxy- Require | R | ar | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Require | r | r | c | c | c | c | c | c | | Proxy- Require | r | r | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Supported | R | amr | c | c | c | c | c | c | | Proxy- Supported | R | amr | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Proxy- Supported | r | | c | c | c | c | c | c | | Proxy- Supported | r | | c | c | c | c | c | c |
skipping to change at page 134, line 39 skipping to change at page 127, line 5
| | | | | | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m | | Via | c | dr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m | | WWW- | 401 | | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
+------------------+---------+-----+----+----+----+-----+-----+-----+ +------------------+---------+-----+----+----+----+-----+-----+-----+
Table 10: Overview of RTSP header fields (M-W) related to methods Table 10: Overview of RTSP header fields (M-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
+-------------------------+---------+-------+-----+-----+-----+-----+ +---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+-------------------------+---------+-------+-----+-----+-----+-----+ +---------------------------+-------+-------+-----+-----+-----+-----+
| Accept | R | arm | o | o | - | - | | Accept | R | arm | o | o | - | - |
| | | | | | | | | | | | | | | |
| Accept-Credentials | R | rm | o | o | o | - | | Accept-Credentials | R | rm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Encoding | R | r | o | o | o | - | | Accept-Encoding | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Language | R | r | o | o | o | - | | Accept-Language | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Accept-Ranges | G | rm | o | - | - | - | | Accept-Ranges | G | rm | o | - | - | - |
| | | | | | | | | | | | | | | |
| Allow | 405 | amr | m | m | m | - | | Allow | 405 | amr | m | m | m | - |
| | | | | | | | | | | | | | | |
| Authentication-Info | r | | o/- | o/- | - | - | | Authentication-Info | r | | o/- | o/- | - | - |
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Cache-Control | G | r | o | o | - | - | | Cache-Control | G | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | G | | o | o | o | o | | Connection | G | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o | - | | Connection-Credentials | 470, | ar | o | o | o | - |
| | | | | | | | | | 407 | | | | | |
| Content-Base | R | | o | o | - | - | | | | | | | | |
| | | | | | | | | Content-Base | R | | o | o | - | - |
| Content-Base | r | | o | o | - | - | | | | | | | | |
| | | | | | | | | Content-Base | r | | o | o | - | - |
| Content-Base | 4xx,5xx | | o | o | o | o | | | | | | | | |
| | | | | | | | | Content-Base | 4xx, | | o | o | o | o |
| Content-Encoding | R | r | o | o | - | - | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Encoding | r | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Encoding | 4xx,5xx | r | o | o | o | o | | Content-Encoding | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Content-Language | R | r | o | o | - | - | | Content-Encoding | 4xx, | r | o | o | o | o |
| | | | | | | | | | 5xx | | | | | |
| Content-Language | r | r | o | o | - | - | | | | | | | | |
| | | | | | | | | Content-Language | R | r | o | o | - | - |
| Content-Language | 4xx,5xx | r | o | o | o | o | | | | | | | | |
| | | | | | | | | Content-Language | r | r | o | o | - | - |
| Content-Length | R | r | * | * | - | - | | | | | | | | |
| | | | | | | | | Content-Language | 4xx, | r | o | o | o | o |
| Content-Length | r | r | * | * | - | - | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| Content-Length | 4xx,5xx | r | * | * | * | * | | Content-Length | R | r | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Location | R | | o | o | - | - | | Content-Length | r | r | * | * | - | - |
| | | | | | | | | | | | | | | |
| Content-Location | r | | o | o | - | - | | Content-Length | 4xx, | r | * | * | * | * |
| | | | | | | | | | 5xx | | | | | |
| Content-Location | 4xx,5xx | | o | o | o | o | | | | | | | | |
| | | | | | | | | Content-Location | R | | o | o | - | - |
| Content-Type | R | | * | * | - | - | | | | | | | | |
| | | | | | | | | Content-Location | r | | o | o | - | - |
| Content-Type | r | | * | * | - | - | | | | | | | | |
| | | | | | | | | Content-Location | 4xx, | | o | o | o | o |
| Content-Type | 4xx,5xx | | * | * | * | * | | | 5xx | | | | | |
| | | | | | | | | | | | | | | |
| CSeq | R,c | mr | m | m | m | m | | Content-Type | R | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Date | R | a | o | o | m | o | | Content-Type | r | | * | * | - | - |
| | | | | | | | | | | | | | | |
| Date | r | am | o | o | o | o | | Content-Type | 4xx, | | * | * | * | * |
| | | | | | | | | | 5xx | | | | | |
| Expires | r | r | - | - | - | - | | | | | | | | |
| | | | | | | | | CSeq | R,c | mr | m | m | m | m |
| From | R | r | o | o | o | - | | | | | | | | |
| | | | | | | | | Date | R | a | o | o | m | o |
| If-Match | R | r | - | - | - | - | | | | | | | | |
| | | | | | | | | Date | r | am | o | o | o | o |
| If-Modified-Since | R | am | o | - | - | - | | | | | | | | |
| | | | | | | | | Expires | r | r | - | - | - | - |
| If-None-Match | R | am | o | - | - | - | | | | | | | | |
| | | | | | | | | From | R | r | o | o | o | - |
| Last-Modified | R | r | - | - | - | - | | | | | | | | |
| | | | | | | | | If-Match | R | r | - | - | - | - |
| Last-Modified | r | r | o | - | - | - | | | | | | | | |
| | | | | | | | | If-Modified-Since | R | am | o | - | - | - |
| Location | 3rr | | o | o | o | - | | | | | | | | |
| | | | | | | | | If-None-Match | R | am | o | - | - | - |
| Location | R | | - | - | m | - | | | | | | | | |
| | | | | | | | | Last-Modified | R | r | - | - | - | - |
| Media-Properties | R | amr | o | - | - | c | | | | | | | | |
| | | | | | | | | Last-Modified | r | r | o | - | - | - |
| Media-Properties | r | mr | c | - | - | - | | | | | | | | |
| | | | | | | | | Location | 3rr | | o | o | o | - |
| Media-Range | R | | o | - | - | c | | | | | | | | |
| | | | | | | | | Location | R | | - | - | m | - |
| Media-Range | r | | c | - | - | - | | | | | | | | |
| | | | | | | | | Media-Properties | R | amr | o | - | - | c |
| MTag | r | r | o | - | - | - | | | | | | | | |
| | | | | | | | | Media-Properties | r | mr | c | - | - | - |
| Notify-Reason | R | | - | - | - | m | | | | | | | | |
| | | | | | | | | Media-Range | R | | o | - | - | c |
| Pipelined-Requests | R | amdr | o | o | - | - | | | | | | | | |
| | | | | | | | | Media-Range | r | | c | - | - | - |
| Proxy-Authenticate | 407 | amdr | m | m | m | - | | | | | | | | |
| | | | | | | | | MTag | r | r | o | - | - | - |
| Proxy-Authentication-In | r | amdr | o/- | o/- | - | - | | | | | | | | |
| fo | | | | | | | | Notify-Reason | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
| Proxy-Authorization | R | amdr | o | o | o | - | | Pipelined-Requests | R | amdr | o | o | - | - |
| Proxy-Require | R | ar | o | o | o | - | | | | | | | | |
| | | | | | | | | Proxy-Authenticate | 407 | amdr | m | m | m | - |
| Proxy-Supported | R | amr | c | c | c | - | | | | | | | | |
| | | | | | | | | Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - |
| Proxy-Supported | r | | c | c | c | - | | | | | | | | |
| | | | | | | | | Proxy-Authorization | R | amdr | o | o | o | - |
| Public | 501 | admr | m | m | m | - | | | | | | | | |
+-------------------------+---------+-------+-----+-----+-----+-----+ | Proxy-Require | R | ar | o | o | o | - |
| | | | | | | |
| Proxy-Supported | R | amr | c | c | c | - |
| | | | | | | |
| Proxy-Supported | r | | c | c | c | - |
| | | | | | | |
| Public | 501 | admr | m | m | m | - |
+---------------------------+-------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY.
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Range | R | | o | - | o | m | | Range | R | | o | - | o | m |
| | | | | | | | | | | | | | | |
| Referrer | R | | o | o | o | - | | Referrer | R | | o | o | o | - |
skipping to change at page 138, line 4 skipping to change at page 130, line 24
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m | | Session | R | r | o | o | o | m |
| | | | | | | | | | | | | | | |
| Session | r | r | c | c | o | m | | Session | r | r | c | c | o | m |
| | | | | | | | | | | | | | | |
| Speed | G | | - | - | - | - | | Speed | G | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Supported | R | adrm | o | o | o | - | | Supported | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | r | adrm | c | c | c | - |
| | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Timestamp | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Timestamp | c | adrm | m | m | m | - |
| | | | | | | | | | | | | | | |
| Transport | G | mr | - | - | - | - | | Transport | G | mr | - | - | - | - |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
skipping to change at page 138, line 26 skipping to change at page 130, line 47
| User-Agent | r | r | m* | m* | m* | m* | | User-Agent | r | r | m* | m* | m* | m* |
| | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | - | | Via | R | amr | o | o | o | - |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Via | c | dr | m | m | m | - |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | WWW-Authenticate | 401 | | m | m | m | - |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY. GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY.
18.1. Accept 18.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description and parameter media types [RFC6838] which presentation description and parameter media types [RFC6838] which
are acceptable for the response to DESCRIBE and GET_PARAMETER are acceptable for the response to DESCRIBE and GET_PARAMETER
requests. requests.
See Section 20.2.3 for the syntax. See Section 20.2.3 for the syntax.
skipping to change at page 143, line 10 skipping to change at page 135, line 37
Authorization request-header field with the request. The Authorization request-header field with the request. The
Authorization field value consists of credentials containing the Authorization field value consists of credentials containing the
authentication information of the user agent for the realm of the authentication information of the user agent for the realm of the
resource being requested. This header MUST only be used in client to resource being requested. This header MUST only be used in client to
server requests. server requests.
If a request is authenticated and a realm specified, the same If a request is authenticated and a realm specified, the same
credentials SHOULD be valid for all other requests within this realm credentials SHOULD be valid for all other requests within this realm
(assuming that the authentication scheme itself does not require (assuming that the authentication scheme itself does not require
otherwise, such as credentials that vary according to a challenge otherwise, such as credentials that vary according to a challenge
value or using synchronized clocks). value or using synchronized clocks). Each client to server request
MUST be individually authorized by including the Authorization header
with the information.
When a shared cache (see Section 16) receives a request containing an When a shared cache (see Section 16) receives a request containing an
Authorization field, it MUST NOT return the corresponding response as Authorization field, it MUST NOT return the corresponding response as
a reply to any other request, unless one of the following specific a reply to any other request, unless one of the following specific
exceptions holds: exceptions holds:
1. If the response includes the "max-age" cache-control directive, 1. If the response includes the "max-age" cache-control directive,
the cache MAY use that response in replying to a subsequent the cache MAY use that response in replying to a subsequent
request. But (if the specified maximum age has passed) a proxy request. But (if the specified maximum age has passed) a proxy
cache MUST first revalidate it with the origin server, using the cache MUST first revalidate it with the origin server, using the
skipping to change at page 149, line 25 skipping to change at page 142, line 6
the identity of its underlying media type. the identity of its underlying media type.
The content-coding is a characteristic of the message body identified The content-coding is a characteristic of the message body identified
by the Request-URI. Typically, the message body is stored with this by the Request-URI. Typically, the message body is stored with this
encoding and is only decoded before rendering or analogous usage. encoding and is only decoded before rendering or analogous usage.
However, an RTSP proxy MAY modify the content-coding if the new However, an RTSP proxy MAY modify the content-coding if the new
coding is known to be acceptable to the recipient, unless the "no- coding is known to be acceptable to the recipient, unless the "no-
transform" cache-control directive is present in the message. transform" cache-control directive is present in the message.
If the content-coding of a message body is not "identity", then the If the content-coding of a message body is not "identity", then the
response MUST include a Content-Encoding Message-body header that message MUST include a Content-Encoding Message-body header that
lists the non-identity content-coding(s) used. lists the non-identity content-coding(s) used.
If the content-coding of a message body in a request message is not If the content-coding of a message body in a request message is not
acceptable to the origin server, the server SHOULD respond with a acceptable to the origin server, the server SHOULD respond with a
status code of 415 (Unsupported Media Type). status code of 415 (Unsupported Media Type).
If multiple encodings have been applied to a message body, the If multiple encodings have been applied to a message body, the
content codings MUST be listed in the order in which they were content codings MUST be listed in the order in which they were
applied, first to last from left to right. Additional information applied, first to last from left to right. Additional information
about the encoding parameters MAY be provided by other header fields about the encoding parameters MAY be provided by other header fields
skipping to change at page 151, line 8 skipping to change at page 143, line 36
locations by which they might be individually accessed, the server locations by which they might be individually accessed, the server
SHOULD provide a Content-Location for the particular variant which is SHOULD provide a Content-Location for the particular variant which is
returned. returned.
As example, if an RTSP client performs a DESCRIBE request on a given As example, if an RTSP client performs a DESCRIBE request on a given
resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace", resource, e.g., "rtsp://a.example.com/movie/Plan9FromOuterSpace",
then the server may use additional information, such as the User- then the server may use additional information, such as the User-
Agent header, to determine the capabilities of the agent. The server Agent header, to determine the capabilities of the agent. The server
will then return a media description tailored to that class of RTSP will then return a media description tailored to that class of RTSP
agents. To indicate which specific description the agent receives agents. To indicate which specific description the agent receives
the resource identifier the resource identifier ("rtsp://a.example.com/movie/
("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is Plan9FromOuterSpace/FullHD.sdp") is provided in Content-Location,
provided in Content-Location, while the description is still a valid while the description is still a valid response for the generic
response for the generic resource identifier. Thus enabling both resource identifier. Thus enabling both debugging and cache
debugging and cache operation as discussed below. operation as discussed below.
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular variant at the time of the request. corresponding to this particular variant at the time of the request.
Future requests MAY specify the Content-Location URI as the request Future requests MAY specify the Content-Location URI as the request
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
variant. This is useful if the RTSP agent desires to verify if the variant. This is useful if the RTSP agent desires to verify if the
resource variant is current through a conditional request. resource variant is current through a conditional request.
A cache cannot assume that a message body with a Content-Location A cache cannot assume that a message body with a Content-Location
skipping to change at page 152, line 15 skipping to change at page 144, line 42
presentation descriptions and parameter-value types. presentation descriptions and parameter-value types.
18.20. CSeq 18.20. CSeq
The CSeq general-header field specifies the sequence number (integer) The CSeq general-header field specifies the sequence number (integer)
for an RTSP request-response pair. This field MUST be present in all for an RTSP request-response pair. This field MUST be present in all
requests and responses. RTSP agents maintain a sequence number requests and responses. RTSP agents maintain a sequence number
series for each responder to which they have an open message series for each responder to which they have an open message
transport channel. For each new RTSP request an agent originates on transport channel. For each new RTSP request an agent originates on
a particular RTSP message transport the CSeq value MUST be a particular RTSP message transport the CSeq value MUST be
incremented by one. The initial sequence number MAY be any number, incremented by one. The initial sequence number can be any number,
however, it is RECOMMENDED to start at 0. Each sequence number however, it is RECOMMENDED to start at 0. Each sequence number
series is unique between each requester and responder, i.e., the series is unique between each requester and responder, i.e., the
client has one series for its requests to a server and the server has client has one series for its requests to a server and the server has
another when sending requests to the client. Each requester and another when sending requests to the client. Each requester and
responder is identified by its socket address (IP address and port responder is identified by its socket address (IP address and port
number), i.e., per direction of a TCP connection. Any retransmitted number), i.e., per direction of a TCP connection. Any retransmitted
request MUST contain the same sequence number as the original, i.e., request MUST contain the same sequence number as the original, i.e.,
the sequence number is not incremented for retransmissions of the the sequence number is not incremented for retransmissions of the
same request. The RTSP agent receiving requests MUST process the same request. The RTSP agent receiving requests MUST process the
requests arriving on a particular transport in the order of the requests arriving on a particular transport in the order of the
skipping to change at page 154, line 38 skipping to change at page 147, line 16
moment just before the message body is generated. In practice, the moment just before the message body is generated. In practice, the
date can be generated at any time during the message origination date can be generated at any time during the message origination
without affecting its semantic value. without affecting its semantic value.
Note: The RTSP 2.0 date format is defined to be the RFC 5322 full Note: The RTSP 2.0 date format is defined to be the RFC 5322 full
date format. This format is more flexible than the RFC 1123 date date format. This format is more flexible than the RFC 1123 date
format used by RTSP 1.0. Thus implementations should use single format used by RTSP 1.0. Thus implementations should use single
spaces as recommended by RFC 5322 as separators and support spaces as recommended by RFC 5322 as separators and support
receiving the obsolete format. receiving the obsolete format.
[[RFC Editor please remove this note: Prior to version 37 of the Further Note that the syntax allow for a comment to be added at
draft, rfc2326bis envisaged sticking with the RFC 1123 format.]] the end of the date.
[RFC Editor please remove this note in brackets: Prior to version
37 of the draft, rfc2326bis envisaged sticking with the RFC 1123
format.]
18.22. Expires 18.22. Expires
The Expires message-body header field gives a date and time after The Expires message-body header field gives a date and time after
which the description or media-stream should be considered stale. which the description or media-stream should be considered stale.
The interpretation depends on the method: The interpretation depends on the method:
DESCRIBE response: The Expires header indicates a date and time DESCRIBE response: The Expires header indicates a date and time
after which the presentation description (body) SHOULD be after which the presentation description (body) SHOULD be
considered stale. considered stale.
skipping to change at page 155, line 21 skipping to change at page 147, line 49
copy of the message body). See Section 16 for further discussion of copy of the message body). See Section 16 for further discussion of
the expiration model. the expiration model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The format is an absolute date and time as defined by RTSP-date. An The format is an absolute date and time as defined by RTSP-date. An
example of its use is example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Wed, 23 Jan 2013 15:36:52 +0000
RTSP/2.0 clients and caches MUST treat other invalid date formats, RTSP/2.0 clients and caches MUST treat other invalid date formats,
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent. RTSP
RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in /2.0 servers SHOULD NOT send Expires dates more than one year in the
the future. future.
18.23. From 18.23. From
The From request-header field, if given, SHOULD contain an Internet The From request-header field, if given, SHOULD contain an Internet
e-mail address for the human user who controls the requesting user e-mail address for the human user who controls the requesting user
agent. The address SHOULD be machine-usable, as defined by "mailbox" agent. The address SHOULD be machine-usable, as defined by "mailbox"
in [RFC1123]. in [RFC1123].
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
skipping to change at page 167, line 49 skipping to change at page 160, line 36
keyboard. keyboard.
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment relative to the Request-URI. The URI MUST NOT include a fragment
identifier. identifier.
Because the source of a link might be private information or might Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the recommended that the user be able to select whether or not the
Referrer field is sent. For example, a streaming client could have a Referrer field is sent. For example, a streaming client could have a
toggle switch for openly/anonymously, which would respectively toggle switch for openly/anonymously, which would respectively enable
enable/disable the sending of Referrer and From information. /disable the sending of Referrer and From information.
Clients SHOULD NOT include a Referrer header field in a (non-secure) Clients SHOULD NOT include a Referrer header field in a (non-secure)
RTSP request if the referring page was transferred with a secure RTSP request if the referring page was transferred with a secure
protocol. protocol.
18.42. Request-Status 18.42. Request-Status
This request-header is used to indicate the end result for requests This request-header is used to indicate the end result for requests
that take time to complete, such as PLAY (Section 13.4). It is sent that take time to complete, such as PLAY (Section 13.4). It is sent
in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report
skipping to change at page 182, line 16 skipping to change at page 175, line 5
receiving of the media stream's data packets. The main reasons receiving of the media stream's data packets. The main reasons
are threefold: First, indicating the port and source address(s) are threefold: First, indicating the port and source address(s)
lets the receiver know where from the packets is expected to lets the receiver know where from the packets is expected to
originate. Secondly, traversal of NATs is greatly simplified originate. Secondly, traversal of NATs is greatly simplified
when traffic is flowing symmetrically over a NAT binding. when traffic is flowing symmetrically over a NAT binding.
Thirdly, certain NAT traversal mechanisms, needs to know to Thirdly, certain NAT traversal mechanisms, needs to know to
which address and port to send so called "binding packets" from which address and port to send so called "binding packets" from
the receiver to the sender, thus creating an address binding in the receiver to the sender, thus creating an address binding in
the NAT that the sender to receiver packet flow can use. the NAT that the sender to receiver packet flow can use.
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport than However, since this is more a feature of transport than
media initialization, the authoritative source for this media initialization, the authoritative source for this
information should be in the SETUP response. information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Currently defined valid values are "PLAY". If this session. Currently defined valid values are "PLAY". If
not provided, the default is "PLAY". The "RECORD" value was not provided, the default is "PLAY". The "RECORD" value was
defined in RFC 2326 and is in this specification unspecified defined in RFC 2326 and is in this specification unspecified
but reserved. RECORD and other values may be specified in the but reserved. RECORD and other values may be specified in the
future. future.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
skipping to change at page 182, line 44 skipping to change at page 175, line 33
interleaved=4-5 in cases where the transport choice for the interleaved=4-5 in cases where the transport choice for the
media stream requires it, e.g., for RTP with RTCP. The channel media stream requires it, e.g., for RTP with RTCP. The channel
number given in the request is only a guidance from the client number given in the request is only a guidance from the client
to the server on what channel number(s) to use. The server MAY to the server on what channel number(s) to use. The server MAY
set any valid channel number in the response. The declared set any valid channel number in the response. The declared
channel(s) are bi-directional, so both end-parties MAY send channel(s) are bi-directional, so both end-parties MAY send
data on the given channel. One example of such usage is the data on the given channel. One example of such usage is the
second channel used for RTCP, where both server and client send second channel used for RTCP, where both server and client send
RTCP packets on the same channel. RTCP packets on the same channel.
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way that
that it is done with UDP, i.e., one channel for RTP and it is done with UDP, i.e., one channel for RTP and the other
the other for RTCP. for RTCP.
MIKEY: This parameter is used in conjunction with transport MIKEY: This parameter is used in conjunction with transport
specifications that can utilize MIKEY [RFC3830] for security specifications that can utilize MIKEY [RFC3830] for security
context establishment. So far only the SRTP based RTP profiles context establishment. So far only the SRTP based RTP profiles
SAVP and SAVPF can utilize MIKEY and this is defined in SAVP and SAVPF can utilize MIKEY and this is defined in
Appendix C.1.4.1. This parameter can be included both in Appendix C.1.4.1. This parameter can be included both in
request and response messages. The binary MIKEY message SHALL request and response messages. The binary MIKEY message SHALL
be BASE64 [RFC4648] encoded before being included in the value be BASE64 [RFC4648] encoded before being included in the value
part of the parameter, where the encoding adheres to the part of the parameter, where the encoding adheres to the
definition in Section 4 of RFC 4648 and where the padding bits definition in Section 4 of RFC 4648 and where the padding bits
skipping to change at page 184, line 14 skipping to change at page 176, line 50
not, two different transport header specifications must be not, two different transport header specifications must be
included. included.
The parameters setup and connection defined below MAY only be used if The parameters setup and connection defined below MAY only be used if
the media transport protocol of the lower-level transport is the media transport protocol of the lower-level transport is
connection-oriented (such as TCP). However, these parameters MUST connection-oriented (such as TCP). However, these parameters MUST
NOT be used when interleaving data over the RTSP connection. NOT be used when interleaving data over the RTSP connection.
setup: Clients use the setup parameter on the Transport line in a setup: Clients use the setup parameter on the Transport line in a
SETUP request, to indicate the roles it wishes to play in a TCP SETUP request, to indicate the roles it wishes to play in a TCP
connection. This parameter is adapted from [RFC4145]. We connection. This parameter is adapted from [RFC4145]. The use
discuss the use of this parameter in RTP/AVP/TCP non- of this parameter in RTP/AVP/TCP non-interleaved transport is
interleaved transport in Appendix C.2.2; the discussion below discussed in Appendix C.2.2; the discussion below is limited to
is limited to syntactic issues. Clients may specify the syntactic issues. Clients may specify the following values for
following values for the setup parameter: the setup parameter:
active: The client will initiate an outgoing connection. active: The client will initiate an outgoing connection.
passive: The client will accept an incoming connection. passive: The client will accept an incoming connection.
actpass: The client is willing to accept an incoming actpass: The client is willing to accept an incoming
connection or to initiate an outgoing connection. connection or to initiate an outgoing connection.
If a client does not specify a setup value, the "active" value If a client does not specify a setup value, the "active" value
is assumed. is assumed.
In response to a client SETUP request where the setup parameter In response to a client SETUP request where the setup parameter
is set to "active", a server's 2xx reply MUST assign the setup is set to "active", a server's 2xx reply MUST assign the setup
parameter to "passive" on the Transport header line. parameter to "passive" on the Transport header line.
In response to a client SETUP request where the setup parameter In response to a client SETUP request where the setup parameter
is set to "passive", a server's 2xx reply MUST assign the setup is set to "passive", a server's 2xx reply MUST assign the setup
skipping to change at page 185, line 41 skipping to change at page 178, line 27
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;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY" "192.0.2.5:3457";mode="PLAY"
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
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: Fri, 20 Dec 2013 10:20:32 +0000
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/ "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY" "192.0.2.224:6257";mode="PLAY"
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=0.6, Dynamic, Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900 Time-Limited=20081128T165900
18.55. Unsupported 18.55. Unsupported
skipping to change at page 192, line 10 skipping to change at page 184, line 16
all deployments will return the chain of certificates used to all deployments will return the chain of certificates used to
authenticate any intermediate proxies as well as the server. An authenticate any intermediate proxies as well as the server. An
operator of such a deployment may want to hide its topology from the operator of such a deployment may want to hide its topology from the
client. It should be noted well that the client does not have any client. It should be noted well that the client does not have any
insight into the proxy's operation. Even if the proxy is trusted, it insight into the proxy's operation. Even if the proxy is trusted, it
can still return an incomplete chain of certificates. can still return an incomplete chain of certificates.
A proxy MUST use TLS for the next hop if the RTSP request includes a A proxy MUST use TLS for the next hop if the RTSP request includes a
"rtsps" URI. TLS MAY be applied on intermediate links (e.g., between "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between
client and proxy, or between proxy and proxy), even if the resource client and proxy, or between proxy and proxy), even if the resource
and the end server are not required to use it. The proxy MUST, when and the end server are not required to use it. The chain of proxies
initiating the next hop TLS connection, use the incoming TLS used by a client to reach a server and their TLS sessions MUST have
connections cipher suite list, only modified by removing any cipher commensurate security. Therefore a proxy MUST, when initiating the
suites that the proxy does not support. In case a proxy fails to next hop TLS connection, use the incoming TLS connections cipher
establish a TLS connection due to cipher suite mismatch between proxy suite list, only modified by removing any cipher suites that the
and next hop proxy or server, this is indicated using error code 472 proxy does not support. In case a proxy fails to establish a TLS
(Failure to establish secure connection). connection due to cipher suite mismatch between proxy and next hop
proxy or server, this is indicated using error code 472 (Failure to
establish secure connection).
19.3.1. Accept-Credentials 19.3.1. Accept-Credentials
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
includes the Accept-Credentials header to dictate how the proxy includes the Accept-Credentials header to dictate how the proxy
treats the server/next proxy certificate. There are currently three treats the server/next proxy certificate. There are currently three
methods defined: methods defined:
Any: which means that the proxy (or proxies) MUST accept whatever Any: which means that the proxy (or proxies) MUST accept whatever
skipping to change at page 193, line 49 skipping to change at page 186, line 10
o The proxy responds to the RTSP request with a 470 or 407 response o The proxy responds to the RTSP request with a 470 or 407 response
code. The 407 response code MAY be used when the proxy requires code. The 407 response code MAY be used when the proxy requires
both user and connection authorization from user or client. In both user and connection authorization from user or client. In
this message the proxy MUST include a Connection-Credentials this message the proxy MUST include a Connection-Credentials
header, see Section 18.13 with the next hop's identity and header, see Section 18.13 with the next hop's identity and
certificate. certificate.
The client MUST upon receiving a 470 or 407 response with Connection- The client MUST upon receiving a 470 or 407 response with Connection-
Credentials header take the decision on whether to accept the Credentials header take the decision on whether to accept the
certificate or not (if it cannot do so, the user SHOULD be certificate or not (if it cannot do so, the user SHOULD be
consulted). If the certificate is accepted, the client has to again consulted). Using IP addresses in the next hop URI and certificates
send the RTSP request. In that request the client has to include the rather than domain names makes it very difficult for a user to
Accept-Credentials header including the hash over the DER encoded determine if it should approve the next hop or not. Proxies are
certificate for all trusted proxies in the chain. RECOMMENDED to use domain names to identify themselves in URIs and in
the certificates. If the certificate is accepted, the client has to
again send the RTSP request. In that request the client has to
include the Accept-Credentials header including the hash over the DER
encoded certificate for all trusted proxies in the chain.
Example: Example:
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: 2
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-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
Accept-Credentials: User Accept-Credentials: User
skipping to change at page 197, line 18 skipping to change at page 189, line 36
COMMA = SWS "," SWS ; comma COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon COLON = SWS ":" SWS ; colon
MINUS = SWS "-" SWS ; minus/dash MINUS = SWS "-" SWS ; minus/dash
LDQUOT = SWS DQUOTE ; open double quotation mark LDQUOT = SWS DQUOTE ; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark RDQUOT = DQUOTE SWS ; close double quotation mark
RAQUOT = ">" SWS ; right angle quote RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<" ; left angle quote LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = <As defined in RFC 3629> UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629> UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629> UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629> UTF8-4 = <As defined in RFC 3629>
UTF8-CONT = %x80-BF UTF8-tail = <As defined in RFC 3629>
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT] POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT 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 ] IRI-rest = ihier-part [ "?" iquery ]
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 ] irelative-ref = irelative-part [ "?" iquery ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute / ipath-absolute
/ ipath-noscheme / ipath-noscheme
/ ipath-empty / ipath-empty
skipping to change at page 200, line 18 skipping to change at page 192, line 18
/ ( "-" smpte-time ) / ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop" smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension / "smpte-25" / smpte-type-extension
; other timecodes may be added ; other timecodes may be added
smpte-type-extension = "smpte" token smpte-type-extension = "smpte" token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
[ ":" 1*2DIGIT [ "." 1*2DIGIT ] ] [ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]
npt-range = "npt" [EQUAL npt-range-spec] npt-range = "npt" [EQUAL npt-range-spec]
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time ) npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp
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 = 2*19DIGIT ; any positive number
npt-mm = 1*2DIGIT ; 0-59 npt-mm = 2*2DIGIT ; 0-59
npt-ss = 1*2DIGIT ; 0-59 npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp
[ "." 1*9DIGIT ] # Compatibility format
npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59
utc-range = "clock" [EQUAL utc-range-spec] utc-range = "clock" [EQUAL 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 [ "." 1*9DIGIT ] utc-clock = 6DIGIT [ "." 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 / LWS)
20.2.2. Message Syntax 20.2.2. Message Syntax
RTSP-message = Request / Response ; RTSP/2.0 messages RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line Request = Request-Line
*((general-header *((general-header
/ request-header / request-header
/ message-body-header) CRLF) / message-body-header) CRLF)
CRLF CRLF
[ message-body-data ] [ message-body-data ]
skipping to change at page 204, line 45 skipping to change at page 196, line 45
/ ( m-type SLASH m-subtype ) / ( m-type SLASH m-subtype )
) *( SEMI m-parameter ) ) *( SEMI m-parameter )
accept-params = "q" EQUAL qvalue *(SEMI generic-param ) accept-params = "q" EQUAL qvalue *(SEMI generic-param )
qvalue = ( "0" [ "." *3DIGIT ] ) qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] ) / ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info]) cred-decision = ("User" [LWS cred-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ (token [LWS 1*header-value]) / (token [LWS 1*header-value])
; For future extensions ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data) cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg
SEMI base64 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 = "identity" / token content-coding = "identity" / 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
skipping to change at page 214, line 15 skipping to change at page 205, line 48
21. Security Considerations 21. Security Considerations
The security considerations and threats around RTSP and its usage can The security considerations and threats around RTSP and its usage can
be divided into considerations around the signaling protocol itself be divided into considerations around the signaling protocol itself
and the issues related to the media stream delivery. However, when and the issues related to the media stream delivery. However, when
it comes to mitigations of security threats, a threat depending on it comes to mitigations of security threats, a threat depending on
the media stream delivery may in fact be mitigated by a mechanism in the media stream delivery may in fact be mitigated by a mechanism in
the signaling protocol. the signaling protocol.
There are several chapters and an appendix in this document that There are several chapters and an appendix in this document that
define security solutions for the protocol. We will reference them define security solutions for the protocol. These sections will be
when discussing the threats below. But the reader should take referenced when discussing the threats below. But the reader should
special notice of the Security Framework (Section 19) and the take special notice of the Security Framework (Section 19) and the
specification of how to use SRTP and its key-mangement specification of how to use SRTP and its key-mangement
(Appendix C.1.4) to achieve certain aspects of the media security. (Appendix C.1.4) to achieve certain aspects of the media security.
21.1. Signaling Protocol Threats 21.1. Signaling Protocol Threats
This section focuses on issues related to the signaling protocol. This section focuses on issues related to the signaling protocol.
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 214, line 44 skipping to change at page 206, line 30
can be constrained by law in certain countries. RTSP servers can be constrained by law in certain countries. RTSP servers
will presumably have similar logging mechanisms to HTTP, and will presumably have similar logging mechanisms to HTTP, and
thus should be equally guarded in protecting the contents of thus should be equally guarded in protecting the contents of
those logs, thus protecting the privacy of the users of the those logs, thus protecting the privacy of the users of the
servers. People using the RTSP protocol to provide media are servers. People using the RTSP protocol to provide media are
responsible for ensuring that logging material is not responsible for ensuring that logging material is not
distributed without the permission of any individuals that are distributed without the permission of any individuals that are
identifiable by the published results. identifiable by the published results.
Transfer of Sensitive Information: There is no reason to believe Transfer of Sensitive Information: There is no reason to believe
that information transferred or controlled via RTSP may be any that information transferred in RTSP message, such as the URI
less sensitive than that normally transmitted via HTTP. and the content of headers, especially the Server, Via,
Therefore, all of the precautions regarding the protection of Referrer and From headers, may be any less sensitive than when
data privacy and user privacy apply to implementors of RTSP used in HTTP. Therefore, all of the precautions regarding the
clients, servers, and proxies. See [H15.1.2] for further protection of data privacy and user privacy apply to
details. implementors of RTSP clients, servers, and proxies. See
[H15.1.2] for further details.
The RTSP methods defined in this document is primarily used to
establish and control the delivery of the media data
represented by the URI, thus the RTSP message bodies are
generally less sensitive than the ones in HTTP. Where HTTP
bodies could contain for example your medical records, in RTSP
the sensitive video of your medical operation would be in the
media stream over the media transport protocol, not in the RTSP
message. Still one have to take note of what potential
sensitive informative are included in the RTSP protocol. The
protection of the media data is separate, can be applied
directly between client and server, and is dependent on the
media transport protocol in use. See Section 21.2 for further
discussion. This possibility for separation of security
between media resource content and the signalling protocol
mitigates the risk of exposing the media content when using
hop-by-hop security for RTSP signaling using proxies
(Section 19.3).
Attacks Based On File and Path Names: Though RTSP URIs are opaque Attacks Based On File and Path Names: Though RTSP URIs are opaque
handles that do not necessarily have file system semantics, it handles that do not necessarily have file system semantics, it
is anticipated that many implementations will translate is anticipated that many implementations will translate
portions of the Request-URIs directly to file system calls. In portions of the Request-URIs directly to file system calls. In
such cases, file systems SHOULD follow the precautions outlined such cases, file systems SHOULD follow the precautions outlined
in [H15.2], such as checking for ".." in path components. in [H15.2], such as checking for ".." in path components.
Personal Information: RTSP clients are often privy to the same Personal Information: RTSP clients are often privy to the same
information that HTTP clients are (user name, location, etc.) information that HTTP clients are (user name, location, etc.)
and thus should be equally sensitive. See [H15.1] for further and thus should be equally sensitive. See [H15.1] for further
recommendations. recommendations.
Privacy Issues Connected to Accept Headers: Since may of the same Privacy Issues Connected to Accept Headers: Since similar usages of
"Accept" headers exist in RTSP as in HTTP, the same caveats the "Accept" headers exist in RTSP as in HTTP, the same caveats
outlined in [H15.1.4] with regards to their use should be outlined in [H15.1.4] with regards to their use should be
followed. followed.
DNS Spoofing: Presumably, given the longer connection times DNS Spoofing: Presumably, given the longer connection times
typically associated to RTSP sessions relative to HTTP typically associated to RTSP sessions relative to HTTP
sessions, RTSP client DNS optimizations should be less sessions, RTSP client DNS optimizations should be less
prevalent. Nonetheless, the recommendations provided in prevalent. Nonetheless, the recommendations provided in
[H15.3] are still relevant to any implementation which attempts [H15.3] are still relevant to any implementation which attempts
to rely on a DNS-to-IP mapping to hold beyond a single use of to rely on a DNS-to-IP mapping to hold beyond a single use of
the mapping. the mapping.
Location Headers and Spoofing: If a single server supports multiple Location Headers and Spoofing: If a single server supports multiple
organizations that do not trust each another, then it MUST organizations that do not trust each another, then it MUST
check the values of Location and Content-Location header fields check the values of the Content-Location header fields in
in responses that are generated under control of said responses that are generated under control of said
organizations to make sure that they do not attempt to organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
([H15.4]) ([H15.4])
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [RFC2616], as of this writing) and also of the previous RFC (RFC 2616 [RFC2616], as of this writing) and also of the previous RFC
2068 [RFC2068], future HTTP specifications may provide additional 2068 [RFC2068], future HTTP specifications may provide additional
guidance on security issues. guidance on security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
skipping to change at page 216, line 30 skipping to change at page 208, line 34
policy. policy.
TLS through proxies: If one uses the possibility to connect TLS in TLS through proxies: If one uses the possibility to connect TLS in
multiple legs (Section 19.3) one really needs to be aware of multiple legs (Section 19.3) one really needs to be aware of
the trust model. That procedure requires full faith and trust the trust model. That procedure requires full faith and trust
in all proxies, which will be identified, that one allows to in all proxies, which will be identified, that one allows to
connect through. They are men in the middle and have access to connect through. They are men in the middle and have access to
all that goes on over the TLS connection. Thus it is important all that goes on over the TLS connection. Thus it is important
to consider if that trust model is acceptable in the actual to consider if that trust model is acceptable in the actual
application. Further discussion of the actual trust model is application. Further discussion of the actual trust model is
in Section 19.3. in Section 19.3. It is important to note what difference in
security properties, if any, that may exist with the used media
transport protocol and its security mechanism. Using SRTP and
the MIKEY based key-establishment defined in Appendix C.1.4.1,
enables to media key-establishment to done end-to-end without
revealing the keys to the proxies.
Resource Exhaustion: As RTSP is a stateful protocol and establishes Resource Exhaustion: As RTSP is a stateful protocol and establishes
resource usage on the server there is a clear possibility to resource usage on the server there is a clear possibility to
attack the server by trying to overbook these resources to attack the server by trying to overbook these resources to
perform a denial of service attack. This attack can be both perform a denial of service attack. This attack can be both
against ongoing sessions and to prevent others from against ongoing sessions and to prevent others from
establishing sessions. RTSP agents will need to have establishing sessions. RTSP agents will need to have
mechanisms to prevent single peers from consuming extensive mechanisms to prevent single peers from consuming extensive
amounts of resources. The methods for guarding against this amounts of resources. The methods for guarding against this
are varied and depends on the agent's role and capabilities and are varied and depends on the agent's role and capabilities and
skipping to change at page 218, line 20 skipping to change at page 210, line 25
provides mechanisms to verify the source authentication, integrity provides mechanisms to verify the source authentication, integrity
and prevent replay attacks on the media stream. and prevent replay attacks on the media stream.
Scope of Multicast: If RTSP is used to control the transmission of Scope of Multicast: If RTSP is used to control the transmission of
media onto a multicast network the scope of the delivery must be media onto a multicast network the scope of the delivery must be
considered. RTSP supports the TTL Transport header parameter to considered. RTSP supports the TTL Transport header parameter to
indicate this scope for IPv4. IPv6 has a different mechanism for indicate this scope for IPv4. IPv6 has a different mechanism for
scope boundary. However, such scope control has risks, as it may scope boundary. However, such scope control has risks, as it may
be set too large and distribute media beyond the intended scope. be set too large and distribute media beyond the intended scope.
Below (Section 21.2.2) we do a protocol specific analysis of security Below (Section 21.2.2) a protocol specific analysis of security
considerations for RTP based media transport. In that section we considerations for RTP based media transport is done. In that
also make clear the requirements on implementing security functions section it is also made clear the requirements on implementing
for RTSP agents supporting media delivery over RTP. security functions for RTSP agents supporting media delivery over
RTP.
21.2.1. Remote Denial of Service Attack 21.2.1. Remote Denial of Service Attack
The attacker may initiate traffic flows to one or more IP addresses The attacker may initiate traffic flows to one or more IP addresses
by specifying them as the destination in SETUP requests. While the by specifying them as the destination in SETUP requests. While the
attacker's IP address may be known in this case, this is not always attacker's IP address may be known in this case, this is not always
useful in prevention of more attacks or ascertaining the attacker's useful in prevention of more attacks or ascertaining the attacker's
identity. Thus, an RTSP server MUST only allow client-specified identity. Thus, an RTSP server MUST only allow client-specified
destinations for RTSP-initiated traffic flows if the server has destinations for RTSP-initiated traffic flows if the server has
ensured that the specified destination address accepts receiving ensured that the specified destination address accepts receiving
skipping to change at page 221, line 34 skipping to change at page 213, line 27
Come, First Served", "Expert Review, "Specification Required", and Come, First Served", "Expert Review, "Specification Required", and
"Standards Action". "Standards Action".
RFC-Editor Note: Please replace all occurrences of RFCXXXX with RFC-Editor Note: Please replace all occurrences of RFCXXXX with
the RFC number this specification receives when published. the RFC number this specification receives when published.
In case a registry requires a contact person, the authors, with In case a registry requires a contact person, the authors, with
Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are Magnus Westerlund (magnus.westerlund@ericsson.com) as primary, are
the contact persons for any entries created by this document. the contact persons for any entries created by this document.
A registration request to IANA MUST contain the following IANA will request the following information for any registration
information: request:
o A name of the item to register according to the rules specified by o A name of the item to register according to the rules specified by
the intended registry. the intended registry.
o Indication of who has change control over the feature (for o Indication of who has change control over the feature (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium, a particular company or group of companies, bodies, a consortium, a particular company or group of companies,
or an individual); or an individual);
o A reference to a further description, if available, for example o A reference to a further description, if available, for example
skipping to change at page 222, line 19 skipping to change at page 214, line 16
When a client and server try to determine what part and functionality When a client and server try to determine what part and functionality
of the RTSP specification and any future extensions that its counter of the RTSP specification and any future extensions that its counter
part implements there is need for a namespace. This registry part implements there is need for a namespace. This registry
contains named entries representing certain functionality. contains named entries representing certain functionality.
The usage of feature-tags is explained in Section 11 and The usage of feature-tags is explained in Section 11 and
Section 13.1. Section 13.1.
22.1.2. Registering New Feature-tags with IANA 22.1.2. Registering New Feature-tags with IANA
The registering of feature-tags is done on a first come, first served The registering of feature-tags is done on a First Come, First Served
basis. [RFC5226] basis.
The name of the feature MUST follow these rules: The name may be of The registry entry for a feature-tag has the following information:
any length, but SHOULD be no more than twenty characters long. The
name MUST NOT contain any spaces, or control characters. The o The name of the feature-tag
registration MUST indicate if the feature-tag applies to clients,
servers, or proxies only or any combinations of these. Any * If the registrant indicates that the feature is proprietary,
proprietary feature MUST have as the first part of the name a vendor IANA should request a vendor "prefix" portion of the name. The
tag, which identifies the organization. The registry entries consist name will then be the vendor prefix followed by a "." followed
of the feature tag, a one paragraph description of what it by the rest of the provided feature name.
represents, its applicability (server, client, proxy, any
combination) and a reference to its specification where applicable. * If the feature is not proprietary, then IANA need not collect a
prefix for the name.
o A one paragraph description of what the feature-tag represents
o The applicability (server, client, proxy, or some combination)
o A reference to a specification, if applicable
Feature-tag names (including the vendor prefix) may contain any non-
space and non-control characters. There is no length limit on
feature-tags.
Examples for a vendor tag describing a proprietary feature are: Examples for a vendor tag describing a proprietary feature are:
vendorA.specfeat01 vendorA.specfeat01
vendorA.specfeat02 vendorA.specfeat02
22.1.3. Registered entries 22.1.3. Registered entries
The following feature-tags are defined in this specification and The following feature-tags are defined in this specification and
skipping to change at page 223, line 24 skipping to change at page 215, line 32
22.2. RTSP Methods 22.2. RTSP Methods
22.2.1. Description 22.2.1. Description
Methods are described in Section 13. Extending the protocol with new Methods are described in Section 13. Extending the protocol with new
methods allow for totally new functionality. 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 is registered through an IETF Standards Action
The reason is that new methods may radically change the protocol's [RFC5226]. The reason is that new methods may radically change the
behavior and purpose. protocol's behavior and purpose.
A specification for a new RTSP method MUST consist of the following A specification for a new RTSP method 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 what a request using the method does and o A clear specification what a request using the method does and
what responses are expected. 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 IANA registered headers o A list or table specifying which of the IANA registered headers
that are allowed to be used with the method in request or/and that are allowed to be used with the method in request or/and
skipping to change at page 224, line 28 skipping to change at page 216, line 35
22.3. RTSP Status Codes 22.3. RTSP Status Codes
22.3.1. Description 22.3.1. Description
A status code is the three digit number used to convey information in A status code is the three digit number used to convey information in
RTSP response messages, see Section 8. The number space is limited RTSP response messages, see Section 8. The number space is limited
and care should be taken not to fill the space. and care should be taken not to fill the space.
22.3.2. Registering New Status Codes with IANA 22.3.2. Registering New Status Codes with IANA
A new status code registration follows the policy of IETF Review. A new status code registration follows the policy of IETF Review
New RTSP functionality requiring Status Codes should first be [RFC5226]. New RTSP functionality requiring Status Codes should
registered in the range x50-x99. Only when the range is full should first be registered in the range x50-x99. Only when the range is
registrations be done in the x00-x49 range, unless it is to adopt an full should registrations be done in the x00-x49 range, unless it is
HTTP extension also to RTSP. The reason is to enable any HTTP to adopt an HTTP extension also to RTSP. The reason is to enable any
extension to be adopted to RTSP without needing to renumber any HTTP extension to be adopted to RTSP without needing to renumber any
related status codes. A specification for a new status code MUST related status codes. A specification for a new status code specify
specify the following: the following:
o The registered number. o The registered number.
o A description of what the status code means and the expected o A description of what the status code means and the expected
behavior of the sender and receiver of the code. behavior of the sender and receiver of the code.
22.3.3. Registered Entries 22.3.3. Registered Entries
RFCXXXX, registers the numbered status code defined in the ABNF entry RFCXXXX, registers the numbered status code defined in the ABNF entry
"Status-Code" except "extension-code" (that defines the syntax "Status-Code" except "extension-code" (that defines the syntax
skipping to change at page 225, line 16 skipping to change at page 217, line 25
By specifying new headers a method(s) can be enhanced in many By specifying new headers a method(s) can be enhanced in many
different ways. An unknown header will be ignored by the receiving different ways. An unknown header will be ignored by the receiving
agent. If the new header is vital for a certain functionality, a agent. If the new header is vital for a certain functionality, a
feature-tag for the functionality can be created and demanded to be feature-tag for the functionality can be created and demanded to be
used by the counter-part with the inclusion of a Require header used by the counter-part with the inclusion of a Require header
carrying the feature-tag. carrying the feature-tag.
22.4.2. Registering New Headers with IANA 22.4.2. Registering New Headers with IANA
Registrations in the registry can be done following the Expert Review Registrations in the registry can be done following the Expert Review
policy. A specification SHOULD be provided, preferably an IETF RFC policy [RFC5226]. A specification is recommended to be provided,
or other Standards Developing Organization specification. The preferably an IETF RFC or other Standards Developing Organization
minimal information in a registration request is the header name and specification. The minimal information in a registration request is
the contact information. the header name and the contact information.
The specification SHOULD contain the following information: The expert reviewer verifies that the registration request contain
the following information:
o The name of the header. o The name of the header.
o An ABNF specification of the header syntax. o An ABNF specification of the header syntax.
o A list or table specifying when the header may be used, o A list or table specifying when the header may be used,
encompassing all methods, their request or response, the direction encompassing all methods, their request or response, the direction
(C->S or S->C). (C->S or S->C).
o How the header is to be handled by proxies. o How the header is to be handled by proxies.
skipping to change at page 227, line 12 skipping to change at page 219, line 19
The use of "x-" is NOT RECOMMENDED but the above headers in the The use of "x-" is NOT RECOMMENDED but the above headers in the
register list were defined prior to the clarification. register list were defined prior to the clarification.
22.5. Accept-Credentials 22.5. Accept-Credentials
The security framework's TLS connection mechanism has two The security framework's TLS connection mechanism has two
registerable entities. registerable entities.
22.5.1. Accept-Credentials policies 22.5.1. Accept-Credentials policies
In Section 19.3.1 three policies for how to handle certificates are This registry are for polices for a RTSP proxy's handling and
specified. Further policies may be defined and MUST be registered verification of TLS certificates when establishing outbound TLS
with IANA using the following rules: connection on clients behalf. In Section 19.3.1 three policies for
how to handle certificates are specified. Further policies may be
o Registering requires an IETF Standards Action defined and registration is done through an IETF Standards Action
[RFC5226]. The registration is required to contain the following
o A registration is required to name a contact person. information:
o Name of the policy. o Name of the policy.
o A describing text that explains how the policy works for handling o A describing text that explains how the policy works for handling
the certificates. the certificates.
o A contact person.
This specification registers the following values: This specification registers the following values:
Any Any: A policy requiring the proxy to accept any received
certificate.
Proxy Proxy: A policy where the proxy applies its own policies to
determine which certificates are accepted or not.
User User: A policy where the certificate is required to be forwarded down
the proxy chain to the client, thus allowing the user to
decided to accept or refuse a certificate.
22.5.2. Accept-Credentials hash algorithms 22.5.2. Accept-Credentials hash algorithms
The Accept-Credentials header (See Section 18.2) allows for the usage The Accept-Credentials header (See Section 18.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities. of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely The registration of any future algorithm is expected to be extremely
rare and could also cause interoperability problems. Therefore the rare and could also cause interoperability problems. Therefore the
bar for registering new algorithms is intentionally placed high. bar for registering new algorithms is intentionally placed high.
Any registration of a new hash algorithm MUST fulfill the following Any registration of a new hash algorithm requires an IETF Standards
Action [RFC5226]. The registration needs to fulfill the following
requirement: requirement:
o Follow the IETF Standards Action policy. o The algorithms identifier meeting the "token" ABNF requirement.
o A definition of the algorithm and its identifier meeting the o Provide a definition of the algorithm.
"token" ABNF requirement.
The registered value is: The registered value is:
Hash Alg. Id Reference Hash Alg. Id Reference
------------------------ ------------------------
sha-256 [RFCXXXX] sha-256 [RFCXXXX]
22.6. Cache-Control Cache Directive Extensions 22.6. Cache-Control Cache Directive Extensions
There exists a number of cache directives which can be sent in the There exists a number of cache directives which can be sent in the
Cache-Control header. A registry for these cache directives MUST be Cache-Control header. A registry for these cache directives is
defined with the following rules: established by IANA. New registrations in this registry requires an
IETF Standards Action or IESG Approval [RFC5226]. The registration
o Registering requires an IETF Standards Action or IESG Approval. needs to contain the following information.
o A registration is required to contain a contact person. o Name of the directive
o Name of the directive and a definition of the value, if any. o A definition of the parameter value, if any is allowed.
o Specification if it is a request or response directive. o Specification if it is a request or response directive.
o A describing text that explains how the cache directive is used o A describing text that explains how the cache directive is used
for RTSP controlled media streams. for RTSP controlled media streams.
o A contact person.
This specification registers the following values: This specification registers the following values:
no-cache: no-cache:
public: public:
private: private:
no-transform: no-transform:
only-if-cached: only-if-cached:
max-stale: max-stale:
min-fresh: min-fresh:
must-revalidate: must-revalidate:
proxy-revalidate: proxy-revalidate:
max-age: max-age:
The registry should be represented as: Name of the directive, contact The registry should be represented as: Name of the directive, contact
person and reference. person and reference.
22.7. Media Properties 22.7. Media Properties
22.7.1. Description 22.7.1. Description
The media streams being controlled by RTSP can have many different The media streams being controlled by RTSP can have many different
properties. The media properties required to cover the use cases properties. The media properties required to cover the use cases
that were in mind when writing the specification are defined. that were in mind when writing the specification are defined.
However, it can be expected that further innovation will result in However, it can be expected that further innovation will result in
new use cases or media streams with properties not covered by the new use cases or media streams with properties not covered by the
ones specified here. Thus new media properties can be specified. As ones specified here. Thus new media properties can be specified. As
new media properties may need a substantial amount of new definitions new media properties may need a substantial amount of new definitions
to correctly specify behavior for this property the bar is intended to correctly specify behavior for this property the bar is intended
skipping to change at page 229, line 18 skipping to change at page 221, line 30
that were in mind when writing the specification are defined. that were in mind when writing the specification are defined.
However, it can be expected that further innovation will result in However, it can be expected that further innovation will result in
new use cases or media streams with properties not covered by the new use cases or media streams with properties not covered by the
ones specified here. Thus new media properties can be specified. As ones specified here. Thus new media properties can be specified. As
new media properties may need a substantial amount of new definitions new media properties may need a substantial amount of new definitions
to correctly specify behavior for this property the bar is intended to correctly specify behavior for this property the bar is intended
to be high. to be high.
22.7.2. Registration Rules 22.7.2. Registration Rules
Registering a new media property MUST fulfill the following Registering a new media property is done following the Specification
requirements Required policy [RFC5226]. The Expert reviewer verifies that a
registration request fulfill the following requirements.
o Follow the Specification Required policy and get the approval of
the designated Expert.
o Have an ABNF definition of the media property value name that o Have an ABNF definition of the media property value name that
meets "media-prop-ext" definition meets "media-prop-ext" definition.
o Define which media property group it belongs to or define a new o Define which media property group it belongs to or define a new
group. group.
o A Contact Person for the Registration
o Description of all changes to the behavior of the RTSP protocol as o Description of all changes to the behavior of the RTSP protocol as
result of these changes. result of these changes.
o A Contact Person for the Registration.
22.7.3. Registered Values 22.7.3. Registered Values
This specification registers the ten values listed in Section 18.29. This specification registers the ten values listed in Section 18.29.
The registry should be represented as: Name of the media property, The registry should be represented as: Name of the media property,
property group, contact person and reference. property group, contact person and reference.
22.8. Notify-Reason header 22.8. Notify-Reason header
22.8.1. Description 22.8.1. Description
Notify-Reason values are used for indicating the reason the Notify-Reason values are used for indicating the reason the
notification was sent. Each reason has its associated rules on what notification was sent. Each reason has its associated rules on what
headers and information that may or must be included in the headers and information that may or must be included in the
notification. New notification behaviors need to be specified to notification. New notification behaviors need to be specified to
enable interoperable usage, thus a specification of each new value is enable interoperable usage, thus a specification of each new value is
required. required.
22.8.2. Registration Rules 22.8.2. Registration Rules
Registrations for new Notify-Reason value MUST fulfill the following Registrations for new Notify-Reason value follows the Specification
requirements Required policy [RFC5226]. The Expert Reviewer verifies that the
request fulfills the following requirements:
o Follow the Specification Required policy and get the approval of
the designated Expert.
o An ABNF definition of the Notify reason value name that meets o An ABNF definition of the Notify reason value name that meets
"Notify-Reason-extension" definition "Notify-Reason-extension" definition
o A Contact Person for the Registration
o Description of which headers shall be included in the request and o Description of which headers shall be included in the request and
response, when it should be sent, and any effect it has on the response, when it should be sent, and any effect it has on the
server client state. server client state.
o A Contact Person for the Registration
22.8.3. Registered Values 22.8.3. Registered Values
This specification registers 3 values defined in the Notify-Reas-val This specification registers 3 values defined in the Notify-Reas-val
ABNF, Section 20.2.3: ABNF, Section 20.2.3:
end-of-stream: This Notify-Reason value indicates the end of a media end-of-stream: This Notify-Reason value indicates the end of a media
stream. stream.
media-properties-update: This Notify-Reason value allows the server media-properties-update: This Notify-Reason value allows the server
to indicate that the properties of the media has changed during to indicate that the properties of the media has changed during
skipping to change at page 231, line 7 skipping to change at page 223, line 17
22.9.1. Description 22.9.1. Description
The Range header (Section 18.40) allows for different range formats. The Range header (Section 18.40) allows for different range formats.
These range formats also needs an identifier to be used the Accept- These range formats also needs an identifier to be used the Accept-
Ranges header (Section 18.5). New range formats may be registered, Ranges header (Section 18.5). New range formats may be registered,
but moderation should be applied as it makes interoperability more but moderation should be applied as it makes interoperability more
difficult. difficult.
22.9.2. Registration Rules 22.9.2. Registration Rules
A registration MUST fulfill the following requirements: A registration follows the Specification Required policy [RFC5226].
The Expert Reviewer verifies that the request fulfills the following
o Follow the Specification Required policy. requirements:
o An ABNF definition of the range format that fulfills the "range- o An ABNF definition of the range format that fulfills the "range-
ext" definition. ext" definition.
o Define the range format identifier used in Accept-Ranges header o Define the range format identifier used in Accept-Ranges header
according to the "extension-format" definition. according to the "extension-format" definition.
o A Contact person for the registration.
o Rules for how one handles the range when using a negative Scale. o Rules for how one handles the range when using a negative Scale.
o A Contact person for the registration.
22.9.3. Registered Values 22.9.3. Registered Values
The registry should be represented as: Range header format The registry should be represented as: Range header format
identifier, Name of the range format, contact person and reference. identifier, Name of the range format, contact person and reference.
This specification registers the following values. This specification registers the following values.
npt: Normal Play Time npt: Normal Play Time
clock: UTC Absolute Time format clock: UTC Absolute Time format
skipping to change at page 231, line 44 skipping to change at page 224, line 7
smpte-25: SMPTE Timestamps 25 Frames/sec smpte-25: SMPTE Timestamps 25 Frames/sec
22.10. Terminate-Reason Header 22.10. Terminate-Reason Header
The Terminate-Reason header (Section 18.52) has two registries for The Terminate-Reason header (Section 18.52) has two registries for
extensions. extensions.
22.10.1. Redirect Reasons 22.10.1. Redirect Reasons
Registrations are done under the policy of Expert Review. The This registry contains reasons for session Termination that can be
registered value needs to follow the Terminate-Reason ABNF, i.e., be included in a Terminate-Reason header (Section 18.52). Registrations
a token. The specification needs to provide a definition of what are following the policy of Expert Review [RFC5226]. The Expert
procedures are to be followed when a client receives this redirect Reviewer verifies that the registration contains the following
reason. This specification registers three values: information:
o The value follows the Terminate-Reason ABNF, i.e., be a token.
o That the specification provide a definition of what procedures are
to be followed when a client receives this redirect reason.
o A Contact Person
This specification registers three values:
o Session-Timeout o Session-Timeout
o Server-Admin o Server-Admin
o Internal-Error o Internal-Error
The registry should be represented as: Name of the Redirect Reason, The registry should be represented as: Name of the Redirect Reason,
contact person and reference. contact person and reference.
22.10.2. Terminate-Reason Header Parameters 22.10.2. Terminate-Reason Header Parameters
Registrations are done under the policy of Specification Required. This registry contains parameters that may be included in the
The registrations must define a syntax for the parameter that also Terminate-Reason header (Section 18.52) in addition to a reason.
follows the syntax allowed by the RTSP 2.0 specification. A contact Registrations are done under the policy of Specification Required
person is also required. This specification registers: [RFC5226]. The Expert Reviewer verifies that the registration or the
reference specification contains the following:
o A Parameter Name.
o A Parameter following the syntax allowed by the RTSP 2.0
specification.
o A Reference to the specification.
o A contact person.
This specification registers:
o time o time
o user-msg o user-msg
The registry should be represented as: Name of the Terminate Reason, The registry should be represented as: Name of the Terminate Reason,
contact person and reference. contact person and reference.
22.11. RTP-Info header parameters 22.11. RTP-Info header parameters
22.11.1. Description 22.11.1. Description
The RTP-Info header (Section 18.45) carries one or more parameter The RTP-Info header (Section 18.45) carries one or more parameter
value pairs with information about a particular point in the RTP value pairs with information about a particular point in the RTP
stream. RTP extensions or new usages may need new types of stream. RTP extensions or new usages may need new types of
skipping to change at page 232, line 38 skipping to change at page 225, line 20
The RTP-Info header (Section 18.45) carries one or more parameter The RTP-Info header (Section 18.45) carries one or more parameter
value pairs with information about a particular point in the RTP value pairs with information about a particular point in the RTP
stream. RTP extensions or new usages may need new types of stream. RTP extensions or new usages may need new types of
information. As RTP information that could be needed is likely to be information. As RTP information that could be needed is likely to be
generic enough and to maximize the interoperability, new registration generic enough and to maximize the interoperability, new registration
requires Specification Required. requires Specification Required.
22.11.2. Registration Rules 22.11.2. Registration Rules
Registrations for new RTP-Info value MUST fulfill the following Registrations for new RTP-Info values follows the policy of
requirements Specification Required [RFC5226]. The Expert Reviewer verifies that
the registration and its reference contains the following
information.
o Follow the Specification Required policy and get the approval of o Have an ABNF definition that meets the "generic-param" definition.
the designated Expert.
o Have an ABNF definition that meets the "generic-param" definition o A Reference to the specification.
o A Contact Person for the Registration o A Contact Person for the Registration.
22.11.3. Registered Values 22.11.3. Registered Values
This specification registers the following parameter value pairs: This specification registers the following parameter value pairs:
o url o url
o ssrc o ssrc
o seq o seq
skipping to change at page 233, line 21 skipping to change at page 226, line 4
o ssrc o ssrc
o seq o seq
o rtptime o rtptime
The registry should be represented as: Name of the parameter, contact The registry should be represented as: Name of the parameter, contact
person and reference. person and reference.
22.12. Seek-Style Policies 22.12. Seek-Style Policies
22.12.1. Description 22.12.1. Description
New seek policies may be registered, however, a large number of these Seek-Style Policies defines how the RTSP agent seeks in media content
will complicate implementation substantially. The impact of unknown when given a position within the media content. New seek policies
policies is that the server will not honor the unknown and use the may be registered, however, a large number of these will complicate
server default policy instead. implementation substantially. The impact of unknown policies is that
the server will not honor the unknown and use the server default
policy instead.
22.12.2. Registration Rules 22.12.2. Registration Rules
Registrations of new Seek-Style polices MUST fulfill the following Registrations of new Seek-Style polices follows the policy of
requirements Specification Required [RFC5226]. The Expert Reviewer verifies that
the registration fulfill the following requirements:
o Follow the Specification Required policy.
o Have an ABNF definition of the Seek-Style policy name that meets o Have an ABNF definition of the Seek-Style policy name that meets
"Seek-S-value-ext" definition "Seek-S-value-ext" definition
o Short Description
o A Contact Person for the Registration o A Contact Person for the Registration
o Description of which headers shall be included in the request and o Description of which headers shall be included in the request and
response, when it should be sent, and any affect it has on the response, when it should be sent, and any affect it has on the
server client state. server client state.
22.12.3. Registered Values 22.12.3. Registered Values
This specification registers 4 values: This specification registers 4 values (Name - Short Description):
o RAP o RAP - Using the closest Random Access Point prior or at the
requested start position.
o CoRAP o CoRAP - Conditional Random Access Point is like RAP, but only if
o First-Prior the RAP is closer prior to the requested start position than
current pause point.
o Next o First-Prior - The first-prior policy will start delivery with the
media unit that has a playout time first prior to the requested
start position.
o Next - The next media units after the provided start position.
The registry should be represented as: Name of the Seek-Style Policy, The registry should be represented as: Name of the Seek-Style Policy,
short description, contact person and reference. short description, contact person and reference.
22.13. Transport Header Registries 22.13. Transport Header Registries
The transport header (Section 18.54) contains a number of parameters The transport header (Section 18.54) contains a number of parameters
which have possibilities for future extensions. Therefore registries which have possibilities for future extensions. Therefore registries
for these need to be defined. for these need to be defined.
22.13.1. Transport Protocol Identifier 22.13.1. Transport Protocol Identifier
A Transport Protocol Specification consists of a Transport Protocol A Transport Protocol Specification consists of a Transport Protocol
Identifier, representing some combination of transport protocols, and Identifier, representing some combination of transport protocols, and
any number of transport header parameters required or optional to use any number of transport header parameters required or optional to use
with the identified protocol specification. This registry contains with the identified protocol specification. This registry contains
the identifiers used by registered Transport Protocol Identifiers. the identifiers used by registered Transport Protocol Identifiers.
A registry for the parameter transport protocol identifier MUST be A registration for the parameter transport protocol identifier
defined with the following rules: follows the policy of Specification Required [RFC5226]. The expert
reviewer verifies that the registration fulfill the following
o Registering uses the policy of Specification Required. requirements:
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF syntax definition o A value definition that are following the ABNF syntax definition
of "transport-id" Section 20.2.3. of "transport-id" Section 20.2.3.
o A descriptive text that explains how the registered value are used o A descriptive text that explains how the registered value are used
in RTSP, which underlying transport protocols that are used, and in RTSP, which underlying transport protocols that are used, and
any required Transport header parameters. any required Transport header parameters.
skipping to change at page 236, line 12 skipping to change at page 228, line 48
SAVPF)" [RFC5124] over TCP. The usage is explained in RFC SAVPF)" [RFC5124] over TCP. The usage is explained in RFC
XXXX, Appendix C.2.2. XXXX, Appendix C.2.2.
22.13.2. Transport modes 22.13.2. Transport modes
The Transport Mode is a Transport header (Section 18.54) parameter, The Transport Mode is a Transport header (Section 18.54) parameter,
it is used to identify the general mode of media transport. The PLAY it is used to identify the general mode of media transport. The PLAY
value registered defines a PLAYBACK mode, where media flows from value registered defines a PLAYBACK mode, where media flows from
Server to Client. Server to Client.
A registry for the transport parameter mode MUST be defined with the A registration for the transport parameter mode follows the policy of
following rules: IETF Standards Action [RFC5226]. The registration needs to meet the
following requirements:
o Registering requires an IETF Standards Action.
o A contact person or organization with address and email.
o A value definition that are following the ABNF "token" definition o A value definition that are following the ABNF "token" definition
Section 20.2.3. Section 20.2.3.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers 1 value: This specification registers 1 value:
PLAY: See RFC XXXX. PLAY: See RFC XXXX.
skipping to change at page 236, line 39 skipping to change at page 229, line 25
The registry should be represented as: The Transport Mode value, The registry should be represented as: The Transport Mode value,
contact person and reference. contact person and reference.
22.13.3. Transport Parameters 22.13.3. Transport Parameters
Transport Parameters are different parameters used in a Transport Transport Parameters are different parameters used in a Transport
Header's transport specification (Section 18.54) to provide Header's transport specification (Section 18.54) to provide
additional information required beyond the transport protocol additional information required beyond the transport protocol
identifier to establish a functioning transport. identifier to establish a functioning transport.
A registry for parameters that may be included in the Transport A registration for parameters that may be included in the Transport
header MUST be defined with the following rules: header follows the policy of Specification Required [RFC5226]. The
expert reviewer verifies that the registration fulfill the following
o Registering uses the Specification Required policy. requirements:
o A Transport Parameter Name following the "token" ABNF definition. o A Transport Parameter Name following the "token" ABNF definition.
o A value definition, if the parameter takes a value, that are o A value definition, if the parameter takes a value, that are
following the ABNF definition "trn-par-value" Section 20.2.3. following the ABNF definition "trn-par-value" Section 20.2.3.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers all the transport parameters defined in This specification registers all the transport parameters defined in
skipping to change at page 238, line 26 skipping to change at page 231, line 12
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
That encoding is done according to RFC 3987. That encoding is done according to RFC 3987.
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC
2326), RTSP 2.0 (RFC XXXX) 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The extensions in the URI syntax Interoperability considerations: The extensions in the URI syntax
performed between RTSP 1.0 and 2.0 can create interoperability performed between RTSP 1.0 and 2.0 can create interoperability
issues. The changes are: issues. The changes are:
Support for IPV6 literal in host part and future IP Support for IPV6 literal in host part and future IP literals
literals through RFC 3986 defined mechanism. through RFC 3986 defined mechanism.
A new relative format to use in the RTSP protocol A new relative format to use in the RTSP protocol elements
elements that is not required to start with "/". that is not required to start with "/".
The above changes should have no impact on interoperability as The above changes should have no impact on interoperability as
in detail discussed in Section 4.2 of RFCXXXX. in detail discussed in Section 4.2 of RFCXXXX.
Security considerations: All the security threats identified in Security considerations: All the security threats identified in
Section 7 of RFC 3986 apply also to this scheme. They need to Section 7 of RFC 3986 apply also to this scheme. They need to
be reviewed and considered in any implementation utilizing this be reviewed and considered in any implementation utilizing this
scheme. scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
skipping to change at page 239, line 34 skipping to change at page 232, line 16
2326), RTSP 2.0 (RFC XXXX) 2326), RTSP 2.0 (RFC XXXX)
Interoperability considerations: The "rtsps" scheme was never Interoperability considerations: The "rtsps" scheme was never
officially defined for RTSP 1.0, however it has seen widespread officially defined for RTSP 1.0, however it has seen widespread
use in actual deployments of RTSP 1.0. Therefore this section use in actual deployments of RTSP 1.0. Therefore this section
discusses the believed changes between the unspecified RTSP 1.0 discusses the believed changes between the unspecified RTSP 1.0
"rtsps" scheme and RTSP 2.0 definition. The extensions in the "rtsps" scheme and RTSP 2.0 definition. The extensions in the
URI syntax performed between RTSP 1.0 and 2.0 can create URI syntax performed between RTSP 1.0 and 2.0 can create
interoperability issues. The changes are: interoperability issues. The changes are:
Support for IPV6 literal in host part and future IP Support for IPV6 literal in host part and future IP literals
literals through RFC 3986 defined mechanism. through RFC 3986 defined mechanism.
A new relative format to use in the RTSP protocol A new relative format to use in the RTSP protocol elements
elements that is not required to start with "/". that is not required to start with "/".
The above changes should have no impact on interoperability as The above changes should have no impact on interoperability as
in detail discussed in Section 4.2 of RFCXXXX. in detail discussed in Section 4.2 of RFCXXXX.
Security considerations: All the security threats identified in Security considerations: All the security threats identified in
Section 7 of RFC 3986 apply also to this scheme. They need to Section 7 of RFC 3986 apply also to this scheme. They need to
be reviewed and considered in any implementation utilizing this be reviewed and considered in any implementation utilizing this
scheme. scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
skipping to change at page 242, line 30 skipping to change at page 235, line 30
RTSP GET_PARAMETER and SET_PARAMETER methods. RTSP GET_PARAMETER and SET_PARAMETER methods.
Additional information: Additional information:
Magic number(s): Magic number(s):
File extension(s): File extension(s):
Macintosh file type code(s): Macintosh file type code(s):
Person & email address to contact for further information: Magnus Person & email address to contact for further information: Magnus We
Westerlund (magnus.westerlund@ericsson.com) sterlund (magnus.westerlund@ericsson.com)
Intended usage: Common Intended usage: Common
Restrictions on usage: None Restrictions on usage: None
Author: Magnus Westerlund (magnus.westerlund@ericsson.com) Author: Magnus Westerlund (magnus.westerlund@ericsson.com)
Change controller: IETF Change controller: IETF
Addition Notes: Addition Notes:
skipping to change at page 243, line 16 skipping to change at page 236, line 7
23.1. Normative References 23.1. Normative References
[FIPS-pub-180-2] [FIPS-pub-180-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Federal Information Processing Standards Publications "Federal Information Processing Standards Publications
(FIPS PUBS) 180-2: Secure Hash Standard", August 2002. (FIPS PUBS) 180-2: Secure Hash Standard", August 2002.
[I-D.ietf-avtcore-rtp-circuit-breakers] [I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control: Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", Circuit Breakers for Unicast RTP Sessions", draft-ietf-
draft-ietf-avtcore-rtp-circuit-breakers-03 (work in avtcore-rtp-circuit-breakers-03 (work in progress), July
progress), July 2013. 2013.
[I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)", draft-
ietf-mmusic-rtsp-nat-17 (work in progress), November 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 244, line 14 skipping to change at page 237, line 14
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, Registration Procedures for New URI Schemes", BCP 35, RFC
RFC 4395, February 2006. 4395, February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July
July 2006. 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY- [RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738, Multimedia Internet KEYing (MIKEY)", RFC 4738, November
November 2006. 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 245, line 37 skipping to change at page 238, line 37
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13, RFC
RFC 6838, January 2013. 6838, January 2013.
[SMPTE_TC] [SMPTE_TC]
Society of Motion Picture and Television Engineers, "SMPTE Society of Motion Picture and Television Engineers, "SMPTE
Standard for Television -- Time and Control Code, ST 12M- Standard for Television -- Time and Control Code, ST
1-2008". 12M-1-2008", .
[TS-26234] [TS-26234]
Third Generation Partnership Project (3GPP), "Transparent Third Generation Partnership Project (3GPP), "Transparent
end-to-end Packet-switched Streaming Service (PSS); end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs; Technical Specification 26.234", Protocols and codecs; Technical Specification 26.234",
December 2002. December 2002.
23.2. Informative References 23.2. Informative References
[I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-16 (work in progress),
May 2013.
[ISO.13818-6.1995] [ISO.13818-6.1995]
International Organization for Standardization, International Organization for Standardization,
"Information technology - Generic coding of moving "Information technology - Generic coding of moving
pictures and associated audio information - part 6: pictures and associated audio information - part 6:
Extension for digital storage media and control", Extension for digital storage media and control", ISO
ISO Draft Standard 13818-6, November 1995. Draft Standard 13818-6, November 1995.
[ISO.8601.2000] [ISO.8601.2000]
International Organization for Standardization, "Data International Organization for Standardization, "Data
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO/IEC Standard - Representation of dates and times", ISO/IEC Standard
8601, December 2000. 8601, December 2000.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
September 1981. 1981.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations", RFC
RFC 2663, August 1999. 2663, August 1999.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264, June
June 2002. 2002.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
skipping to change at page 247, line 27 skipping to change at page 240, line 22
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in [RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", the RTP Profile for Audio and Video Conferences", RFC
RFC 4856, February 2007. 4856, February 2007.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245, April
April 2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)", RFC
RFC 5583, July 2009. 5583, July 2009.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298, June
June 2011. 2011.
[Stevens98] [Stevens98]
Stevens, W., "Unix Networking Programming - Volume 1, Stevens, W., "Unix Networking Programming - Volume 1,
second edition", 1998. second edition", 1998.
Appendix A. Examples Appendix A. Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However, remember that understanding of how functions of RTSP work. However, remember that
skipping to change at page 250, line 12 skipping to change at page 242, line 12
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
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
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 24 Jan 1997 15:35:06 GMT Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 271 Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: Fri, 20 Dec 2013 12:20:32 +0000
v=0 v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.5 o=- 2890844256 2890842807 IN IP4 198.51.100.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=control: * a=control: *
a=range:npt=0-0:10:34.10 a=range:npt=00:00:00-00:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
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;unicast;dest_addr=":8000"/":8001" Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock Accept-Ranges: npt, smpte, clock
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: Fri, 20 Dec 2013 12:20:33 +0000
Date: 24 Jan 1997 15:35:12 GMT Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Ranges: npt Accept-Ranges: npt
Media-Properties: Random-Access=0.02, Immutable, 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, clock Accept-Ranges: npt, smpte, clock
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: Fri, 20 Dec 2013 12:20:33 +0000
Date: 24 Jan 1997 15:35:13 GMT Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Range: NPT Accept-Range: NPT
Media-Properties: Random-Access=0.8, Immutable, 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
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 24 Jan 1997 15:35:14 GMT Date: Fri, 20 Dec 2013 10:20:34 +0000
Session: 12345678 Session: 12345678
Range: npt=30-634.10 Range: npt=30-634.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,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
# Pause happens 0.87 seconds after starting to play # Pause happens 0.87 seconds after starting to play
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 24 Jan 1997 15:36:01 GMT Date: Fri, 20 Dec 2013 10:20:35 +0000
Session: 12345678 Session: 12345678
Range: npt=30.87-634.10 Range: npt=30.87-634.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6 CSeq: 6
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=30.87-634.10 Range: npt=30.87-634.10
Seek-Style: Next Seek-Style: Next
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 24 Jan 1997 15:36:01 GMT Date: Fri, 20 Dec 2013 10:22:13 +0000
Session: 12345678 Session: 12345678
Range: npt=30.87-634.10 Range: npt=30.87-634.10
Seek-Style: Next Seek-Style: Next
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012, ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889 ssrc=4F312DD8:seq=55021;rtptime=3132889
C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 7 CSeq: 7
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 7 CSeq: 7
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 24 Jan 1997 15:49:34 GMT Date: Fri, 20 Dec 2013 10:31:53 +0000
A.2. Media on Demand using Pipelining A.2. Media on Demand using Pipelining
This example is basically the example above (Appendix A.1), but now This example is basically the example above (Appendix A.1), but now
utilizing pipelining to speed up the setup. It requires only two utilizing pipelining to speed up the setup. It requires only two
round trip times until the media starts flowing. First of all, the round trip times until the media starts flowing. First of all, the
session description is retrieved to determine what media resources session description is retrieved to determine what media resources
need to be setup. In the second step, one sends the necessary SETUP need to be setup. In the second step, one sends the necessary SETUP
requests and the PLAY request to initiate media delivery. requests and the PLAY request to initiate media delivery.
skipping to change at page 253, line 32 skipping to change at page 245, line 32
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
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
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 271 Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: Fri, 20 Dec 2013 12:20:32 +0000
v=0 v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=control: * a=control: *
a=range:npt=0-0:10:34.10 a=range:npt=00:00:00-00:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
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
skipping to change at page 254, line 36 skipping to change at page 246, line 36
Pipelined-Requests: 7654 Pipelined-Requests: 7654
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; 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: Fri, 20 Dec 2013 12:20:32 +0000
Date: 23 Jan 1997 15:35:12 GMT Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Ranges: npt Accept-Ranges: npt
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, 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: Sat, 21 Dec 2013 10:20:32 +0000
Date: 23 Jan 1997 15:35:13 GMT Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Range: NPT Accept-Range: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, 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: Fri, 20 Dec 2013 10:20:32 +0000
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,
url="rtsp://example.com/twister.3gp/trackID=1" url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.3. Secured Media Session for on Demand Content A.3. Secured Media Session for on Demand Content
skipping to change at page 255, line 41 skipping to change at page 247, line 41
including MIKEY messages. This is pipeline with a PLAY request to including MIKEY messages. This is pipeline with a PLAY request to
initiate media delivery. initiate media delivery.
Client C requests a presentation from media server M. The movie is Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to stored in a container file. The client has obtained an RTSP URI to
the container file. the container file.
Note: The MIKEY messages below are not valid MIKEY message and are Note: The MIKEY messages below are not valid MIKEY message and are
BASE64 encoded random data to represent where the MIKEY messages BASE64 encoded random data to represent where the MIKEY messages
would go. would go.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 301 Moved Permanently M->C: RTSP/2.0 301 Moved Permanently
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Fri, 20 Dec 2013 10:25:32 +0000
Location: rtsps://example.com/twister.3gp Location: rtsps://example.com/twister.3gp
C->M: Establish TCP/TLS connection and verify server's C->M: Establish TCP/TLS connection and verify server's
certificate that is represents example.com. certificate that is represents example.com.
Used for all below RTSP messages. Used for all below RTSP messages.
C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0
CSeq: 2 CSeq: 2
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: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Fri, 20 Dec 2013 10:25:33 +0000
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 271 Content-Length: 271
Content-Base: rtsps://example.com/twister.3gp/ Content-Base: rtsps://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: Fri, 20 Dec 2013 12:25:33 +0000
v=0 v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=control: * a=control: *
a=range:npt=0-0:10:34.10 a=range:npt=00:00:00-00:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/SAVP 0 m=audio 0 RTP/SAVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/SAVP 26 m=video 0 RTP/SAVP 26
a=control: trackID=4 a=control: trackID=4
C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
skipping to change at page 257, line 21 skipping to change at page 249, line 21
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/SAVP;unicast; Transport: RTP/SAVP;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;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: 23 Jan 1997 15:35:12 GMT Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Ranges: npt Accept-Ranges: npt
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited Media-Properties: Random-Access=0.2, 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
Transport: RTP/SAVP;unicast; Transport: RTP/SAVP;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;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00 MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: 23 Jan 1997 15:35:13 GMT Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Range: NPT Accept-Range: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: Fri, 20 Dec 2013 10:25:34 +0000
Session: 12345678 Session: 12345678
Range: npt=0-623.10 Range: npt=0-623.10
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsps://example.com/twister.3gp/trackID=1" url="rtsps://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889; ssrc=4F312DD8:seq=54321;rtptime=2876889;
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.4. Media on Demand (Unicast) A.4. Media on Demand (Unicast)
An alternative example of media on demand with a bit more tweaks is An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two the following. Client C requests a movie distributed from two
different media servers A (audio.example.com) and V ( different media servers A (audio.example.com) and V (
video.example.com). The media description is stored on a web server video.example.com). The media description is stored on a web server
W. The media description contains descriptions of the presentation W. The media description contains descriptions of the presentation
and all its streams, including the codecs that are available, dynamic and all its streams, including the codecs that are available, dynamic
RTP payload types, the protocol stack, and content information such RTP payload types, the protocol stack, and content information such
as language or copyright restrictions. It may also give an as language or copyright restrictions. It may also give an
indication about the timeline of the movie. indication about the timeline of the movie.
In this example, the client is only interested in the last part of In this example, the client is only interested in the last part of
the movie. the movie.
C->W: GET /twister.sdp HTTP/1.1 C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com Host: www.example.com
Accept: application/sdp Accept: application/sdp
W->C: HTTP/1.1 200 OK W->C: HTTP/1.1 200 OK
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Wed, 23 Jan 2013 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 278 Content-Length: 278
Expires: 23 Jan 1998 15:35:06 GMT Expires: Thu, 24 Jan 2013 15:35:06 GMT
v=0 v=0
o=- 2890844526 2890842807 IN IP4 198.51.100.5 o=- 2890844526 2890842807 IN IP4 198.51.100.5
s=RTSP Session s=RTSP Session
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=range:npt=0-1:49:34 a=range:npt=00:00:00-01:49:34
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1