draft-ietf-mmusic-rfc2326bis-31.txt   draft-ietf-mmusic-rfc2326bis-32.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: August 29, 2013 R. Lanphier Expires: September 23, 2013 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
February 25, 2013 March 22, 2013
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-31 draft-ietf-mmusic-rfc2326bis-32
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326. 1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
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 August 29, 2013. This Internet-Draft will expire on September 23, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 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 . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . 29 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . . 27
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . . 27
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 27
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . . 28
4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 29
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . . 29
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 29
4.9.1. Random Access and Seeking . . . . . . . . . . . . . 33 4.9.1. Random Access and Seeking . . . . . . . . . . . . . . 30
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . . 31
4.9.3. Content Modifications . . . . . . . . . . . . . . . 34 4.9.3. Content Modifications . . . . . . . . . . . . . . . . 31
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . . 32
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . . 32
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . . 33
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 34
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 34
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 34
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 36
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41 7.2. Request Header Fields . . . . . . . . . . . . . . . . . . 37
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 39
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 39
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 43
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 44
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 45
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 46
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 48
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 49
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 50
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 51
10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 51
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 53
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 54
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 55
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 56
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 58
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 59
13.3.1. Changing Transport Parameters . . . . . . . . . . . 68 13.3.1. Changing Transport Parameters . . . . . . . . . . . 63
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 63
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 74 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 68
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 75 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 69
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 72
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 78 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 72
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 78 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 72
13.4.7. Playing Live with Recording . . . . . . . . . . . . 79 13.4.7. Playing Live with Recording . . . . . . . . . . . . 73
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 74
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 80 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 74
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 81 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 75
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 82 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 76
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 83 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 77
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 87 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 81
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 87 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 81
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 88 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 82
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 83
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 91 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 84
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 92 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 86
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 95 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 88
15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 98 15.1. Proxies and Protocol Extensions . . . . . . . . . . . . 92
15.2. Multiplexing and Demultiplexing of Messages . . . . . . 99 15.2. Multiplexing and Demultiplexing of Messages . . . . . . 93
16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
16.1. Validation Model . . . . . . . . . . . . . . . . . . . . 100 16.1. Validation Model . . . . . . . . . . . . . . . . . . . 94
16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 102 16.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 95
16.1.2. Message Body Tag Cache Validators . . . . . . . . . 102 16.1.2. Message Body Tag Cache Validators . . . . . . . . . 95
16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 102 16.1.3. Weak and Strong Validators . . . . . . . . . . . . . 95
16.1.4. Rules for When to Use Message Body Tags and 16.1.4. Rules for When to Use Message Body Tags and Last-
Last-Modified Dates . . . . . . . . . . . . . . . . 104 Modified Dates . . . . . . . . . . . . . . . . . . . 98
16.1.5. Non-validating Conditionals . . . . . . . . . . . . 106 16.1.5. Non-validating Conditionals . . . . . . . . . . . . 99
16.2. Invalidation After Updates or Deletions . . . . . . . . 106 16.2. Invalidation After Updates or Deletions . . . . . . . . 99
17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 108 17. Status Code Definitions . . . . . . . . . . . . . . . . . . . 100
17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 108 17.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 100
17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 108 17.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 100
17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 108 17.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 101
17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 108 17.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 101
17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 108 17.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 101
17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 109 17.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 101
17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 109 17.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 102
17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 109 17.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 102
17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 109 17.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 102
17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 110 17.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 103
17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 110 17.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 103
17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 110 17.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 103
17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 110 17.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 103
17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 111 17.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 103
17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 111 17.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 103
17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 111 17.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 104
17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 111 17.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 104
17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 111 17.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 104
17.4.8. 407 Proxy Authentication Required . . . . . . . . . 112 17.4.8. 407 Proxy Authentication Required . . . . . . . . . 104
17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 112 17.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 105
17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 112 17.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 105
17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 112 17.4.11. 411 Length Required . . . . . . . . . . . . . . . . 105
17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 113 17.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 105
17.4.13. 413 Request Message Body Too Large . . . . . . . . . 113 17.4.13. 413 Request Message Body Too Large . . . . . . . . . 106
17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 113 17.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 106
17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 113 17.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 106
17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 113 17.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 106
17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 114 17.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 106
17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 114 17.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 106
17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 114 17.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 107
17.4.20. 455 Method Not Valid in This State . . . . . . . . . 114 17.4.20. 455 Method Not Valid in This State . . . . . . . . . 107
17.4.21. 456 Header Field Not Valid for Resource . . . . . . 114 17.4.21. 456 Header Field Not Valid for Resource . . . . . . 107
17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 114 17.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 107
17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 114 17.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 107
17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 114 17.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 107
17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 115 17.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 107
17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 115 17.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 108
17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 115 17.4.27. 462 Destination Unreachable . . . . . . . . . . . . 108
17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 115 17.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 108
17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 115 17.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 108
17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 115 17.4.30. 465 Notification Reason Unknown . . . . . . . . . . 108
17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 116 17.4.31. 466 Key Management Error . . . . . . . . . . . . . . 108
17.4.32. 470 Connection Authorization Required . . . . . . . 116 17.4.32. 470 Connection Authorization Required . . . . . . . 109
17.4.33. 471 Connection Credentials not accepted . . . . . . 116 17.4.33. 471 Connection Credentials not accepted . . . . . . 109
17.4.34. 472 Failure to establish secure connection . . . . . 116 17.4.34. 472 Failure to establish secure connection . . . . . 109
17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 116 17.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 109
17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 116 17.5.1. 500 Internal Server Error . . . . . . . . . . . . . 109
17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 116 17.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 109
17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 117 17.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 109
17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 117 17.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 109
17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 117 17.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 110
17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 117 17.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 110
17.5.7. 551 Option not supported . . . . . . . . . . . . . . 117 17.5.7. 551 Option not supported . . . . . . . . . . . . . . 110
18. Header Field Definitions . . . . . . . . . . . . . . . . . . 118 18. Header Field Definitions . . . . . . . . . . . . . . . . . . 110
18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 128 18.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 121
18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 128 18.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 121
18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 129 18.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 122
18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 130 18.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 122
18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 131 18.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 123
18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 131 18.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 124
18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 131 18.7. Authorization . . . . . . . . . . . . . . . . . . . . . 124
18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 132 18.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 125
18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 133 18.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 126
18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 133 18.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 126
18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 136 18.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 129
18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 136 18.12. Connection-Credentials . . . . . . . . . . . . . . . . . 129
18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 137 18.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 130
18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 137 18.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 131
18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 138 18.15. Content-Language . . . . . . . . . . . . . . . . . . . . 131
18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 139 18.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 132
18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 139 18.17. Content-Location . . . . . . . . . . . . . . . . . . . . 132
18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 140 18.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 134
18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 140 18.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 134
18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 141 18.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 134
18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 142 18.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 135
18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 143 18.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 136
18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 143 18.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 137
18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 144 18.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 137
18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 144 18.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 137
18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 145 18.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 138
18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 145 18.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 139
18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 146 18.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 139
18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 148 18.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 141
18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 148 18.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 142
18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 149 18.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 142
18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 149 18.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 142
18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 150 18.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 143
18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 150 18.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 144
18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 151 18.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 144
18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 151 18.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 144
18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 152 18.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 145
18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 153 18.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 146
18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 154 18.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 148
18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 155 18.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 149
18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 155 18.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 149
18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 156 18.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 150
18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 157 18.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 150
18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 159 18.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 153
18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 160 18.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 154
18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 162 18.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 156
18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 162 18.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 156
18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 163 18.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 157
18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 164 18.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 158
18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 165 18.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 159
18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 165 18.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 159
18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 166 18.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 160
18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 173 18.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 167
18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 173 18.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 167
18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 174 18.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 168
18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 174 18.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 168
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 175 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 168
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 175 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 169
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 175 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 169
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 176 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 170
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 177 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 171
19.3.2. User approved TLS procedure . . . . . . . . . . . . 178 19.3.2. User approved TLS procedure . . . . . . . . . . . . 172
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 181 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 174
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 183 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 176
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 183 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 176
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 186 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 179
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 190 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 182
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 199 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 190
21. Security Considerations . . . . . . . . . . . . . . . . . . . 200 21. Security Considerations . . . . . . . . . . . . . . . . . . . 190
21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 200 21.1. Signaling Protocol Threats . . . . . . . . . . . . . . . 190
21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 203 21.2. Media Stream Delivery Threats . . . . . . . . . . . . . 193
21.2.1. Remote Denial of Service Attack . . . . . . . . . . 204 21.2.1. Remote Denial of Service Attack . . . . . . . . . . 194
21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 205 21.2.2. RTP Security analysis . . . . . . . . . . . . . . . 195
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 207 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 197
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 207 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 198
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 208 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.1.2. Registering New Feature-tags with IANA . . . . . . . 208 22.1.2. Registering New Feature-tags with IANA . . . . . . . 198
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 208 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 198
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 209 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 199
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 209 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 199
22.2.2. Registering New Methods with IANA . . . . . . . . . 209 22.2.2. Registering New Methods with IANA . . . . . . . . . 199
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 209 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 199
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 210 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 200
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 210 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 200
22.3.2. Registering New Status Codes with IANA . . . . . . . 210 22.3.2. Registering New Status Codes with IANA . . . . . . . 200
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 210 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 200
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 210 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 200
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 210 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 200
22.4.2. Registering New Headers with IANA . . . . . . . . . 211 22.4.2. Registering New Headers with IANA . . . . . . . . . 201
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 211 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 201
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 202
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 212 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 202
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 212 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 203
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 213 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 203
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 213 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 204
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 214 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 204
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 214 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 205
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 215 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 205
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 215 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 205
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 215 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 215 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 205
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 215 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 206
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 216 22.9. Range header formats . . . . . . . . . . . . . . . . . . 206
22.9. Range header formats . . . . . . . . . . . . . . . . . . 216 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 206
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 216 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 206
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 216 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 207
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 216 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 207
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 217 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . 207
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 217 22.10.2. Terminate-Reason Header Parameters . . . . . . . . 207
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 217 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 208
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 218 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 208
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 218 22.11.2. Registration Rules . . . . . . . . . . . . . . . . 208
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 218 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 208
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 218 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 208
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 218 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 218 22.12.2. Registration Rules . . . . . . . . . . . . . . . . 209
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 219 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 209
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 219 22.13. Transport Header Registries . . . . . . . . . . . . . . 209
22.13. Transport Header Registries . . . . . . . . . . . . . . 219 22.13.1. Transport Protocol Specification . . . . . . . . . 209
22.13.1. Transport Protocol Specification . . . . . . . . . . 219 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 211
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 221 22.13.3. Transport Parameters . . . . . . . . . . . . . . . 211
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 221 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 212
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 222 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 212
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 222 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . 213
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 223 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . 214
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 224 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 215
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 225 22.16. Media Type Registration for text/parameters . . . . . . 216
22.16. Media Type Registration for text/parameters . . . . . . 226 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 217
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 228 23.1. Normative References . . . . . . . . . . . . . . . . . . 217
23.1. Normative References . . . . . . . . . . . . . . . . . . 228 23.2. Informative References . . . . . . . . . . . . . . . . . 220
23.2. Informative References . . . . . . . . . . . . . . . . . 230 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 221
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 233 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 222
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 233 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 225
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 237 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . . 227
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 239 A.4. Single Stream Container Files . . . . . . . . . . . . . . 230
A.4. Single Stream Container Files . . . . . . . . . . . . . 243 A.5. Live Media Presentation Using Multicast . . . . . . . . . 232
A.5. Live Media Presentation Using Multicast . . . . . . . . 245 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 234
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 246 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 235
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 248 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 235
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 248 B.2. State variables . . . . . . . . . . . . . . . . . . . . . 236
B.2. State variables . . . . . . . . . . . . . . . . . . . . 248 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 236
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 248 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 236
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 249 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 241
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 255 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 255 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . . 241
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 255 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . . 242
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 255 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 243
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 256 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 243
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 257 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 246
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 259 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 246
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 259 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 248
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 261 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 248
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 261 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 248
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 261 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 252
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 265 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . . 256
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 269 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 258
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 271 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 258
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 271 C.7. Maintaining NPT synchronization with RTP timestamps . . . 258
C.7. Maintaining NPT synchronization with RTP timestamps . . 271 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 258
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 271 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 258
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 271 C.10. Usage of SSRCs and the RTCP BYE Message During an RTSP
C.10. Usage of SSRCs and the RTCP BYE Message During an Session . . . . . . . . . . . . . . . . . . . . . . . . . 259
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 271 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 259
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 272 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 260
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 273 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 260
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 273 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . . 260
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 273 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . . 262
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 274 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . . 262
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 275 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 263
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 275 D.1.5. Directionality of media stream . . . . . . . . . . . 263
D.1.5. Directionality of media stream . . . . . . . . . . . 275 D.1.6. Range of Presentation . . . . . . . . . . . . . . . . 263
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 276 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 264
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 277 D.1.8. Connection Information . . . . . . . . . . . . . . . 265
D.1.8. Connection Information . . . . . . . . . . . . . . . 277 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 265
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 278 D.2. Aggregate Control Not Available . . . . . . . . . . . . . 266
D.2. Aggregate Control Not Available . . . . . . . . . . . . 278 D.3. Aggregate Control Available . . . . . . . . . . . . . . . 266
D.3. Aggregate Control Available . . . . . . . . . . . . . . 279 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 267
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 280 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 268
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 280 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 268
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 281 E.1. On-demand Playback of Stored Content . . . . . . . . . . 268
E.1. On-demand Playback of Stored Content . . . . . . . . . . 281 E.2. Unicast Distribution of Live Content . . . . . . . . . . 270
E.2. Unicast Distribution of Live Content . . . . . . . . . . 282 E.3. On-demand Playback using Multicast . . . . . . . . . . . 270
E.3. On-demand Playback using Multicast . . . . . . . . . . . 283 E.4. Inviting an RTSP server into a conference . . . . . . . . 271
E.4. Inviting an RTSP server into a conference . . . . . . . 283 E.5. Live Content using Multicast . . . . . . . . . . . . . . 272
E.5. Live Content using Multicast . . . . . . . . . . . . . . 284 Appendix F. Text format for Parameters . . . . . . . . . . . . . 272
Appendix F. Text format for Parameters . . . . . . . . . . . . . 286 Appendix G. Requirements for Unreliable Transport of RTSP . . . 273
Appendix G. Requirements for Unreliable Transport of RTSP . . . 287 Appendix H. Backwards Compatibility Considerations . . . . . . . 274
Appendix H. Backwards Compatibility Considerations . . . . . . . 289 H.1. Play Request in Play State . . . . . . . . . . . . . . . 275
H.1. Play Request in Play State . . . . . . . . . . . . . . . 289 H.2. Using Persistent Connections . . . . . . . . . . . . . . 275
H.2. Using Persistent Connections . . . . . . . . . . . . . . 289 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 275
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 290 I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 275
I.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 290 I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 277
I.2. Detailed List of Changes . . . . . . . . . . . . . . . . 291 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 283
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 298 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 283
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 298 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 284
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 300 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 284
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 301
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, similar to the "network remote control" for multimedia servers, similar to the
remote control for a DVD player. remote control for a DVD player.
skipping to change at page 19, line 34 skipping to change at page 17, line 46
updating the media properties and the currently used scale factor updating the media properties and the currently used scale factor
exist. exist.
Speed affects how much of the playback timeline is delivered in a Speed affects how much of the playback timeline is delivered in a
given wallclock period. The default is Speed = 1 which means to given wallclock period. The default is Speed = 1 which means to
deliver at the same rate the media is consumed. Speed > 1 means that deliver at the same rate the media is consumed. Speed > 1 means that
the receiver will get content faster than it regularly would consume the receiver will get content faster than it regularly would consume
it. Speed < 1 means that delivery is slower than the regular media it. Speed < 1 means that delivery is slower than the regular media
rate. Speed values of 0 or lower have no meaning and are not rate. Speed values of 0 or lower have no meaning and are not
allowed. This mechanism enables two general functionalities. One is allowed. This mechanism enables two general functionalities. One is
client side scale operations, i.e. the client receives all the frames client side scale operations, i.e. the client receives all the
and makes the adjustment to the playback locally. The second is frames and makes the adjustment to the playback locally. The second
delivery control for buffering of media. By specifying a speed over is delivery control for buffering of media. By specifying a speed
1.0 the client can build up the amount of playback time it has over 1.0 the client can build up the amount of playback time it has
present in its buffers to a level that is sufficient for its needs. present in its buffers to a level that is sufficient for its needs.
A naive implementation of Speed would only affect the transmission A naive implementation of Speed would only affect the transmission
schedule of the media and has a clear impact on the needed bandwidth. schedule of the media and has a clear impact on the needed bandwidth.
This would result in the data rate being proportional to the speed This would result in the data rate being proportional to the speed
factor. Speed = 1.5, i.e., 50% faster than normal delivery, would factor. Speed = 1.5, i.e., 50% faster than normal delivery, would
result in a 50% increase in the data transport rate. If that can be result in a 50% increase in the data transport rate. If that can be
supported or not depends solely on the underlying network path. supported or not depends solely on the underlying network path.
Scale may also have some impact on the required bandwidth due to the Scale may also have some impact on the required bandwidth due to the
manipulation of the content in the new playback schedule. An example manipulation of the content in the new playback schedule. An example
skipping to change at page 29, line 37 skipping to change at page 27, line 14
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 chosen 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. SMPTE Relative Timestamps 4.4. SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
skipping to change at page 30, line 14 skipping to change at page 27, line 40
through the use of "smpte-type". For SMPTE 30, the "frames" field in through the use of "smpte-type". For SMPTE 30, the "frames" field in
the time value can assume the values 0 through 29. The difference the time value can assume the values 0 through 29. The difference
between 30 and 29.97 frames per second is handled by dropping the between 30 and 29.97 frames per second is handled by dropping the
first two frame indices (values 00 and 01) of every minute, except first two frame indices (values 00 and 01) of every minute, except
every tenth minute. If the frame and the subframe values are zero, every tenth minute. If the frame and the subframe values are zero,
they may be omitted. Subframes are measured in one-hundredth of a they may be omitted. Subframes are measured in one-hundredth of a
frame. frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
4.5. Normal Play Time 4.5. Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [RFC5905]. The timestamp with the Network Time Protocol (NTP) [RFC5905]. The timestamp
consists of two parts: the mandatory first part may be expressed in consists of two parts: the mandatory first part may be expressed in
either seconds or hours, minutes, and seconds. The optional second either seconds or hours, minutes, and seconds. The optional second
part consists of a decimal point and decimal figures and indicates part consists of a decimal point and decimal figures and indicates
fractions of a second. fractions of a second.
skipping to change at page 30, line 46 skipping to change at page 28, line 24
NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is
the clock the viewer associates with a program. It is often the clock the viewer associates with a program. It is often
digitally displayed on a VCR. NPT advances normally when in normal digitally displayed on a VCR. NPT advances normally when in normal
play mode (scale = 1), advances at a faster rate when in fast scan play mode (scale = 1), advances at a faster rate when in fast scan
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 conforms to ISO 8601 [ISO.8601.2000]. The npt-sec The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec
notation is optimized for automatic generation, the npt-hhmmss notation is optimized for automatic generation, the npt-hhmmss
notation for consumption by human readers. The "now" constant 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.6. Absolute Time 4.6. Absolute Time
Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
using UTC (GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h 37 min and 20 and a quarter Example for November 8, 1996 at 14h 37 min and 20 and a quarter
seconds UTC: seconds UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-Tags 4.7. Feature-Tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 18.41), Proxy-Require RTSP. These tags are used in Require (Section 18.41), Proxy-Require
(Section 18.35), Proxy-Supported (Section 18.36), Supported (Section 18.35), Proxy-Supported (Section 18.36), Supported
(Section 18.49) and Unsupported (Section 18.53) header fields. (Section 18.49) and Unsupported (Section 18.53) header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies it applies to. servers or proxies it applies to.
skipping to change at page 32, line 30 skipping to change at page 30, line 13
different properties a media instance for delivery and playback can different properties a media instance for delivery and playback can
have. This specification considers the below listed media properties have. This specification considers the below listed media properties
in its protocol operations. They are derived from the differences in its protocol operations. They are derived from the differences
between a number of supported usages. between a number of supported usages.
On-demand: Media that has a fixed (given) duration that doesn't On-demand: Media that has a fixed (given) duration that doesn't
change during the life time of the RTSP session and is known at change during the life time of the RTSP session and is known at
the time of the creation of the session. It is expected that the the time of the creation of the session. It is expected that the
content of the media will not change, even if the representation, content of the media will not change, even if the representation,
i.e encoding, quality, etc, may change. Generally one can seek, i.e encoding, quality, etc, may change. Generally one can seek,
i.e. request any range, within the media. i.e. request any range, within the media.
Dynamic On-demand: This is a variation of the on-demand case where Dynamic On-demand: This is a variation of the on-demand case where
external methods are used to manipulate the actual content of the external methods are used to manipulate the actual content of the
media setup for the RTSP session. The main example is a content media setup for the RTSP session. The main example is a content
defined by a playlist. defined by a playlist.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
accessed. accessed.
skipping to change at page 34, line 27 skipping to change at page 32, line 8
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.9.4. Supported Scale Factors 4.9.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". It may be updated at
any point in the content due to content consisting of spliced pieces any point in the content due to content consisting of spliced pieces
or content being dynamically updated by out-of-band mechanisms. or content being dynamically updated by out-of-band mechanisms.
4.9.5. Mapping to the Attributes 4.9.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
skipping to change at page 44, line 8 skipping to change at page 40, line 5
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 complete the request
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. desirable to import into RTSP.
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
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
skipping to change at page 44, line 32 skipping to change at page 40, line 29
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the message body cases, user agents SHOULD present to the user the message body
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 | | | | |
| | | | | | | |
| 302 | Found | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 303 | reserved | n/a | | 302 | Found | all |
| | | | | | | |
| 304 | Not Modified | all | | 303 | reserved | n/a |
| | | | | | | |
| 305 | Use Proxy | all | | 304 | Not Modified | all |
| | | | | | | |
| | | | | 305 | Use Proxy | all |
| 400 | Bad Request | all | | | | |
| 401 | Unauthorized | all | | | | |
| | | | | | | |
| 402 | Payment Required | all | | 400 | Bad Request | all |
| | | | | | | |
| 403 | Forbidden | all | | 401 | Unauthorized | all |
| | | | | | | |
| 404 | Not Found | all | | 402 | Payment Required | all |
| | | | | | | |
| 405 | Method Not Allowed | all | | 403 | Forbidden | all |
| | | | | | | |
| 406 | Not Acceptable | all | | 404 | Not Found | all |
| | | | | | | |
| 407 | Proxy Authentication Required | all | | 405 | Method Not Allowed | all |
| | | | | | | |
| 408 | Request Timeout | all | | 406 | Not Acceptable | all |
| | | | | | | |
| 410 | Gone | all | | 407 | Proxy Authentication | all |
| | | | | | Required | |
| 411 | Length Required | all | | | | |
| | | | | 408 | Request Timeout | all |
| 412 | Precondition Failed | DESCRIBE, SETUP | | | | |
| | | | | 410 | Gone | all |
| 413 | Request Message Body Too Large | all | | | | |
| | | | | 411 | Length Required | all |
| 414 | Request-URI Too Long | all | | | | |
| | | | | 412 | Precondition Failed | DESCRIBE, SETUP |
| 415 | Unsupported Media Type | all | | | | |
| | | | | 413 | Request Message Body Too | all |
| 451 | Parameter Not Understood | SET_PARAMETER, | | | Large | |
| | | GET_PARAMETER | | | | |
| | | | | 414 | Request-URI Too Long | all |
| 452 | reserved | n/a | | | | |
| | | | | 415 | Unsupported Media Type | all |
| 453 | Not Enough Bandwidth | SETUP | | | | |
| | | | | 451 | Parameter Not Understood | SET_PARAMETER, |
| 454 | Session Not Found | all | | | | GET_PARAMETER |
| | | | | | | |
| 455 | Method Not Valid In This State | all | | 452 | reserved | n/a |
| | | | | | | |
| 456 | Header Field Not Valid | all | | 453 | Not Enough Bandwidth | SETUP |
| | | | | | | |
| 457 | Invalid Range | PLAY, PAUSE | | 454 | Session Not Found | all |
| | | | | | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER | | 455 | Method Not Valid In This | all |
| | | | | | State | |
| 459 | Aggregate Operation Not Allowed | all | | | | |
| | | | | 456 | Header Field Not Valid | all |
| 460 | Only Aggregate Operation | all | | | | |
| | Allowed | | | 457 | Invalid Range | PLAY, PAUSE |
| | | | | | | |
| 461 | Unsupported Transport | all | | 458 | Parameter Is Read-Only | SET_PARAMETER |
| | | | | | | |
| 462 | Destination Unreachable | all | | 459 | Aggregate Operation Not | all |
| | | | | | Allowed | |
| 463 | Destination Prohibited | SETUP | | | | |
| | | | | 460 | Only Aggregate Operation | all |
| 464 | Data Transport Not Ready Yet | PLAY | | | Allowed | |
| | | | | | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY | | 461 | Unsupported Transport | all |
| | | | | | | |
| 466 | Key Management Error | all | | 462 | Destination Unreachable | all |
| | | | | | | |
| 470 | Connection Authorization | all | | 463 | Destination Prohibited | SETUP |
| | Required | | | | | |
| | | | | 464 | Data Transport Not Ready Yet | PLAY |
| 471 | Connection Credentials not | all | | | | |
| | accepted | | | 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | | | | | |
| 472 | Failure to establish secure | all | | 466 | Key Management Error | all |
| | connection | | | | | |
| | | | | 470 | Connection Authorization | all |
| | | | | | Required | |
| 500 | Internal Server Error | all | | | | |
| | | | | 471 | Connection Credentials not | all |
| 501 | Not Implemented | all | | | accepted | |
| | | | | | | |
| 502 | Bad Gateway | all | | 472 | Failure to establish secure | all |
| | | | | | connection | |
| 503 | Service Unavailable | all | | | | |
| | | | | | | |
| 504 | Gateway Timeout | all | | | | |
| | | | | 500 | Internal Server Error | all |
| 505 | RTSP Version Not Supported | all | | | | |
| | | | | 501 | Not Implemented | all |
| 551 | Option Not Support | all | | | | |
+------+---------------------------------+--------------------------+ | 502 | Bad Gateway | all |
| | | |
| 503 | Service Unavailable | all |
| | | |
| 504 | Gateway Timeout | all |
| | | |
| 505 | RTSP Version Not Supported | all |
| | | |
| 551 | Option Not Support | all |
+---------+------------------------------+--------------------------+
Table 4: Status codes and their usage with RTSP methods Table 4: Status codes and their usage with RTSP methods
8.2. Response Headers 8.2. Response Headers
The response-headers allow the request recipient to pass additional The response-headers allow the request recipient to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. This header gives information about the server and about Line. This header gives information about the server and about
further access to the resource identified by the Request-URI. All further access to the resource identified by the Request-URI. All
headers currently classified as response headers are listed in headers currently classified as response headers are listed in Table
Table 5. 5.
+------------------------+--------------------+ +------------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------------+--------------------+ +------------------------+--------------------+
| Connection-Credentials | Section 18.12 | | Connection-Credentials | Section 18.12 |
| | | | | |
| Location | Section 18.27 | | Location | Section 18.27 |
| | | | | |
| MTag | Section 18.30 | | MTag | Section 18.30 |
| | | | | |
skipping to change at page 51, line 19 skipping to change at page 46, line 41
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on if the port indicates the default port that the server will listen on if the port
is not explicitly given. is not explicitly given.
In addition to the registered default ports, i.e. 554 (rtsp) and 322
(rtsps), there are an alternative port 8554 registered. This port
may provide some benefits from non-registered ports if a RTSP server
is unable to use the default ports. The benefits may include pre-
configured security policies as well as classifiers in network
monitoring tools.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault tolerance. Transient connections facilitate mechanisms for fault tolerance.
They also allow for application layer mobility. A server and They also allow for application layer mobility. A server and
client pair that support transient connections can survive the client pair that support transient connections can survive the
loss of a TCP connection; e.g., due to a NAT timeout. When the loss of a TCP connection; e.g., due to a NAT timeout. When the
client has discovered that the TCP connection has been lost, it client has discovered that the TCP connection has been lost, it
can set up a new one when there is need to communicate again. can set up a new one when there is need to communicate again.
A persistent connection is RECOMMENDED to be used for all A persistent connection is RECOMMENDED to be used for all
skipping to change at page 53, line 33 skipping to change at page 49, line 13
close a connection immediately after responding to a session-level close a connection immediately after responding to a session-level
TEARDOWN request for the last RTSP session being controlled through TEARDOWN request for the last RTSP session being controlled through
the connection. Instead, it should wait for a reasonable amount of the connection. Instead, it should wait for a reasonable amount of
time for the client to receive the TEARDOWN response, take time for the client to receive the TEARDOWN response, take
appropriate action, and initiate the connection closing. The server appropriate action, and initiate the connection closing. The server
SHOULD wait at least 10 seconds after sending the TEARDOWN response SHOULD wait at least 10 seconds after sending the TEARDOWN response
before closing the connection. before closing the connection.
This is to ensure that the client has time to issue a SETUP for a This is to ensure that the client has time to issue a SETUP for a
new session on the existing connection after having torn the last new session on the existing connection after having torn the last
one down. 10 seconds should give the client ample opportunity to one down. 10 seconds should give the client ample opportunity to
get its message to the server. get its message to the server.
A server SHOULD NOT close the connection directly as a result of A server SHOULD NOT close the connection directly as a result of
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 17.4.25) are used for negotiating capabilities Allowed" (Section 17.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
skipping to change at page 59, line 14 skipping to change at page 54, line 14
Proxy-Supported: This header is used similarly to the Supported Proxy-Supported: This header is used similarly to the Supported
header, but instead of giving the supported functionality of header, but instead of giving the supported functionality of
the client or server it provides both the requester and the the client or server it provides both the requester and the
responder a view of what functionality the proxy chain between responder a view of what functionality the proxy chain between
the two supports. Proxies are required to add this header the two supports. Proxies are required to add this header
whenever the Supported header is present, but proxies may also whenever the Supported header is present, but proxies may also
add it independently of the requester. add it independently of the requester.
Require: This header can be included in any request where the end- Require: This header can be included in any request where the end-
point, i.e. the client or server, is required to understand the point, i.e. the client or server, is required to understand
feature to correctly perform the request. This can, for the feature to correctly perform the request. This can, for
example, be a SETUP request where the server is required to example, be a SETUP request where the server is required to
understand a certain parameter to be able to set up the media understand a certain parameter to be able to set up the media
delivery correctly. Ignoring this parameter would not have the delivery correctly. Ignoring this parameter would not have the
desired effect and is not acceptable. Therefore the end-point desired effect and is not acceptable. Therefore the end-point
receiving a request containing a Require MUST negatively receiving a request containing a Require MUST negatively
acknowledge any feature that it does not understand and not acknowledge any feature that it does not understand and not
perform the request. The response in cases where features are perform the request. The response in cases where features are
not supported are 551 (Option Not Supported). Also the not supported are 551 (Option Not Supported). Also the
features that are not supported are given in the Unsupported features that are not supported are given in the Unsupported
header in the response. header in the response.
skipping to change at page 62, line 40 skipping to change at page 57, line 21
An OPTIONS request may be issued at any time. Such a request does An OPTIONS request may be issued at any time. Such a request does
not modify the session state. However, it may prolong the session not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the Request- scope of the request and the corresponding response. If the Request-
URI refers to a specific media resource on a given host, the scope is URI refers to a specific media resource on a given host, the scope is
limited to the set of methods supported for that media resource by limited to the set of methods supported for that media resource by
the indicated RTSP agent. A Request-URI with only the host address the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the Request-URI is an without regard to any specific media. If the Request-URI is an
asterisk ("*"), the scope is limited to the general capabilities of asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e. the RTSP agent in direct communication with the the next hop (i.e. the RTSP agent in direct communication with the
request sender). request sender).
Regardless of scope of the request, the Public header MUST always be Regardless of scope of the request, the Public header MUST always be
included in the OPTIONS response listing the methods that are included in the OPTIONS response listing the methods that are
supported by the responding RTSP agent. In addition, if the scope of supported by the responding RTSP agent. In addition, if the scope of
the request is limited to a media resource, the Allow header MUST be the request is limited to a media resource, the Allow header MUST be
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
skipping to change at page 70, line 21 skipping to change at page 64, line 35
What range values are valid depends on the type of content. For What range values are valid depends on the type of content. For
content that isn't time progressing the range value is valid if the content that isn't time progressing the range value is valid if the
given range is part of any media within the aggregate. In other given range is part of any media within the aggregate. In other
words the valid media range for the aggregate is the union of all of words the valid media range for the aggregate is the union of all of
the media components in the aggregate. If a given range value points the media components in the aggregate. If a given range value points
outside of the media, the response MUST be the 457 (Invalid Range) outside of the media, the response MUST be the 457 (Invalid Range)
error code and include the Media-Range header (Section 18.29) with error code and include the Media-Range header (Section 18.29) with
the valid range for the media. Except for time progressing content the valid range for the media. Except for time progressing content
where the client requests a start point prior to what is retained, where the client requests a start point prior to what is retained,
the start point is adjusted to the oldest retained content. For a the start point is adjusted to the oldest retained content. For a
start point that is beyond the media front edge, i.e. beyond the start point that is beyond the media front edge, i.e. beyond the
current value for "now", the server SHALL adjust the start value to current value for "now", the server SHALL adjust the start value to
the current front edge. The Range header's stop point value may the current front edge. The Range header's stop point value may
point beyond the current media edge. In that case, the server SHALL point beyond the current media edge. In that case, the server SHALL
deliver media from the requested (and possibly adjusted) start point deliver media from the requested (and possibly adjusted) start point
until the provided stop point, or the end of the media is reached until the provided stop point, or the end of the media is reached
prior to the specified stop point. Please note that if one simply prior to the specified stop point. Please note that if one simply
wants to play from a particular start point until the end of media wants to play from a particular start point until the end of media
using a Range header with an implicit stop point is RECOMMENDED. using a Range header with an implicit stop point is RECOMMENDED.
If a client requests to start playing at the end of media, either If a client requests to start playing at the end of media, either
skipping to change at page 71, line 9 skipping to change at page 65, line 23
point the media actually is delivered. point the media actually is delivered.
A client desiring to play the media from the beginning MUST send a A client desiring to play the media from the beginning MUST send a
PLAY request with a Range header pointing at the beginning, e.g. PLAY request with a Range header pointing at the beginning, e.g.
"npt=0-". If a PLAY request is received without a Range header and "npt=0-". If a PLAY request is received without a Range header and
media delivery has stopped at the end, the server SHOULD respond with media delivery has stopped at the end, the server SHOULD respond with
a 457 "Invalid Range" error response. In that response, the current a 457 "Invalid Range" error response. In that response, the current
pause point MUST be included in a Range header. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with an All range specifiers in this specification allow for ranges with an
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g. "npt=-30"). When used in a PLAY request,
the server treats this as a request to start or resume delivery from the server treats this as a request to start or resume delivery from
the current pause point, ending at the end time specified in the the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response MUST be given. value, a 457 (Invalid Range) response MUST be given.
The example below will play seconds 10 through 25. It also requests The example below will play seconds 10 through 25. It also requests
the server to deliver media from the first Random Access Point prior the server to deliver media from the first Random Access Point prior
to the indicated start point. to the indicated start point.
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Range: npt=10-25 Range: npt=10-25
Seek-Style: RAP Seek-Style: RAP
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Servers MUST include a "Range" header in any PLAY response, even if Servers MUST include a "Range" header in any PLAY response, even if
no Range header was present in the request. The response MUST use no Range header was present in the request. The response MUST use
the same format as the request's range header contained. If no Range the same format as the request's range header contained. If no Range
header was in the request, the format used in any previous PLAY header was in the request, the format used in any previous PLAY
request within the session SHOULD be used. If no format has been request within the session SHOULD be used. If no format has been
indicated in a previous request the server MAY use any time format indicated in a previous request the server MAY use any time format
supported by the media and indicated in the Accept-Ranges header in supported by the media and indicated in the Accept-Ranges header in
the SETUP request. It is RECOMMENDED that NPT is used if supported the SETUP request. It is RECOMMENDED that NPT is used if supported
by the media. by the media.
skipping to change at page 75, line 30 skipping to change at page 69, line 32
Clients can issue PLAY requests while the stream is in Play state and Clients can issue PLAY requests while the stream is in Play state and
thus updating their request. thus updating their request.
The important difference compared to a PLAY request in Ready state is The important difference compared to a PLAY request in Ready state is
the handling of the current play point and how the Range header in the handling of the current play point and how the Range header in
the request is constructed. The session is actively playing media the request is constructed. The session is actively playing media
and the play point will be moving, making the exact time a request and the play point will be moving, making the exact time a request
will take action hard to predict. Depending on how the PLAY header will take action hard to predict. Depending on how the PLAY header
appears two different cases exist: total replacement or continuation. appears two different cases exist: total replacement or continuation.
A total replacement is signaled by having the first range A total replacement is signaled by having the first range
specification have an explicit start value, e.g. "npt=45-" or specification have an explicit start value, e.g. "npt=45-" or
"npt=45-60", in which case the server stops playout at the current "npt=45-60", in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new PLAY request that isn't based on the pause point. In and then a new PLAY request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and an explicit stop value (Z), e.g. "npt=-60", which start point and an explicit stop value (Z), e.g. "npt=-60", which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. If the current delivery point is the request originally played. If the current delivery point is
beyond the stop point, the server SHALL immediately pause delivery. beyond the stop point, the server SHALL immediately pause delivery.
As the request has been completed successfully it shall be responded As the request has been completed successfully it shall be responded
with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to with 200 OK. A PLAY_NOTIFY with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to the indicate the actual stop point. The pause point is set to the
requested stop point. requested stop point.
Following is an example of this behavior: The server has received Following is an example of this behavior: The server has received
requests to play ranges 10 to 15. If the new PLAY request arrives at requests to play ranges 10 to 15. If the new PLAY request arrives at
the server 4 seconds after the previous one, it will take effect the server 4 seconds after the previous one, it will take effect
while the server still plays the first range (10-15). The server while the server still plays the first range (10-15). The server
changes the current play to continue to 25 seconds, i.e. the changes the current play to continue to 25 seconds, i.e. the
equivalent single request would be PLAY with "range: npt=10-25". equivalent single request would be PLAY with "range: npt=10-25".
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
skipping to change at page 79, line 4 skipping to change at page 73, line 14
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention with Time-Duration set to 0.0. o Retention with Time-Duration set to 0.0.
For live media, the SETUP response 200 OK MUST include the Media- For live media, the SETUP response 200 OK MUST include the Media-
Range header (see Section 18.29). Range header (see Section 18.29).
A client MAY send PLAY requests without the Range header. If the A client MAY send PLAY requests without the Range header. If the
request includes the Range header it MUST use a symbolic value request includes the Range header it MUST use a symbolic value
representing "now". For NPT that range specification is "npt=now-". representing "now". For NPT that range specification is "npt=now-".
The server MUST include the Range header in the response and it MUST The server MUST include the Range header in the response and it MUST
indicate an explicit time value and not a symbolic value. In other indicate an explicit time value and not a symbolic value. In other
words, "npt=now-" is not valid to be used in the response. Instead words, "npt=now-" is not valid to be used in the response. Instead
the time since session start is recommended expressed as an open the time since session start is recommended expressed as an open
interval, e.g. "npt=96.23-". An absolute time value (clock) for the interval, e.g. "npt=96.23-". An absolute time value (clock) for the
corresponding time MAY be given, i.e. "clock=20030213T143205Z-". The corresponding time MAY be given, i.e. "clock=20030213T143205Z-".
UTC clock format can only be used if client has shown support for it The UTC clock format can only be used if client has shown support for
using the Accept-Ranges header. it using the Accept-Ranges header.
13.4.7. Playing Live with Recording 13.4.7. Playing Live with Recording
Certain media servers may offer recording services of live sessions Certain media servers may offer recording services of live sessions
to their clients. This recording would normally be from the to their clients. This recording would normally be from the
beginning of the media session. Clients can randomly access the beginning of the media session. Clients can randomly access the
media between now and the beginning of the media session. This live media between now and the beginning of the media session. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 18.28): Properties header in the SETUP response by (see also Section 18.28):
skipping to change at page 80, line 35 skipping to change at page 74, line 44
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an asynchronous event for a session in Play state. The Session an asynchronous event for a session in Play state. The Session
header MUST be presented in a PLAY_NOTIFY request and indicates the header MUST be presented in a PLAY_NOTIFY request and indicates the
scope of the request. Sending of PLAY_NOTIFY requests requires a scope of the request. Sending of PLAY_NOTIFY requests requires a
persistent connection between server and client, otherwise there is persistent connection between server and client, otherwise there is
no way for the server to send this request method to the client. no way for the server to send this request method to the client.
PLAY_NOTIFY requests have an end-to-end (i.e. server to client) PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
scope, as they carry the Session header, and apply only to the given scope, as they carry the Session header, and apply only to the given
session. The client SHOULD immediately return a response to the session. The client SHOULD immediately return a response to the
server. server.
PLAY_NOTIFY requests MAY be used with a message body, depending on PLAY_NOTIFY requests MAY be used with a message body, depending on
the value of the Notify-Reason header. It is described in the the value of the Notify-Reason header. It is described in the
particular section for each Notify-Reason if a message body is used. particular section for each Notify-Reason if a message body is used.
However, currently there is no Notify-Reason that allows using a However, currently there is no Notify-Reason that allows using a
message body. In this case, there is a need to obey some limitations message body. In this case, there is a need to obey some limitations
when adding new Notify-Reasons that intend to use a message body: the when adding new Notify-Reasons that intend to use a message body: the
skipping to change at page 89, line 7 skipping to change at page 82, line 44
The TEARDOWN request MUST be done only on the session aggregate The TEARDOWN request MUST be done only on the session aggregate
control URI (i.e., it is not allowed to terminate individual media control URI (i.e., it is not allowed to terminate individual media
streams, if it is a session aggregate) and MUST include the following streams, if it is a session aggregate) and MUST include the following
headers; Session and Terminate-Reason headers. The request only headers; Session and Terminate-Reason headers. The request only
applies to the session identified in the Session header. The server applies to the session identified in the Session header. The server
may include a message to the client's user with the "user-msg" may include a message to the client's user with the "user-msg"
parameter. parameter.
The TEARDOWN request may alternatively be done on the wild card URI * The TEARDOWN request may alternatively be done on the wild card URI *
and without any session header. The scope of such a request is and without any session header. The scope of such a request is
limited to the next-hop (i.e. the RTSP agent in direct communication limited to the next-hop (i.e. the RTSP agent in direct communication
with the server) and applies, as well, to the control connection with the server) and applies, as well, to the control connection
between the next-hop RTSP agent and the server. This request between the next-hop RTSP agent and the server. This request
indicates that all sessions and pending requests being managed via indicates that all sessions and pending requests being managed via
the control connection are terminated. Any intervening proxies the control connection are terminated. Any intervening proxies
SHOULD do all of the following in the order listed: SHOULD do all of the following in the order listed:
1. respond to the TEARDOWN request 1. respond to the TEARDOWN request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
skipping to change at page 91, line 12 skipping to change at page 84, line 46
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a message body. It is the method MAY also be used without a message body. It is the
RECOMMENDED method to be used in a request sent for the sole purpose RECOMMENDED method to be used in a request sent for the sole purpose
of updating the keep-alive timer. If this request is successful, of updating the keep-alive timer. If this request is successful,
i.e. a 200 OK response is received, then the keep-alive timer has i.e. a 200 OK response is received, then the keep-alive timer has
been updated. Any non-required header present in such a request may been updated. Any non-required header present in such a request may
or may not have been processed. To allow a client to determine if or may not have been processed. To allow a client to determine if
any such header has been processed, it is necessary to use a feature any such header has been processed, it is necessary to use a feature
tag and the Require header. Due to this reason it is RECOMMENDED tag and the Require header. Due to this reason it is RECOMMENDED
that any parameters are sent in the body, rather than using any that any parameters are sent in the body, rather than using any
header. header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
skipping to change at page 92, line 43 skipping to change at page 86, line 24
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 18.50) to inform the client of the reason for the request. (Section 18.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow a server administrator to do a The intention here is to allow a server administrator to do a
controlled shutdown of the RTSP server. That requires sufficient controlled shutdown of the RTSP server. That requires sufficient
time to inform all entities having associated state with the server time to inform all entities having associated state with the server
and for them to perform a controlled migration from this server to a and for them to perform a controlled migration from this server to a
fall back server. fall back server.
A REDIRECT request with a Session header has end-to-end (i.e. server A REDIRECT request with a Session header has end-to-end (i.e. server
to client) scope and applies only to the given session. Any to client) scope and applies only to the given session. Any
intervening proxies SHOULD NOT disconnect the control channel while intervening proxies SHOULD NOT disconnect the control channel while
there are other remaining end-to-end sessions. The REQUIRED Location there are other remaining end-to-end sessions. The REQUIRED Location
header MUST contain a complete absolute URI pointing to the resource header MUST contain a complete absolute URI pointing to the resource
to which the client SHOULD reconnect. Specifically, the Location to which the client SHOULD reconnect. Specifically, the Location
MUST NOT contain just the host and port. A client may receive a MUST NOT contain just the host and port. A client may receive a
REDIRECT request with a Session header, if and only if, an end-to-end REDIRECT request with a Session header, if and only if, an end-to-end
session has been established. session has been established.
A client may receive a REDIRECT request without a Session header at A client may receive a REDIRECT request without a Session header at
skipping to change at page 94, line 26 skipping to change at page 88, line 11
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header can be Note: The media resource indicated by the Location header can be
identical, slightly different or totally different. This is the identical, slightly different or totally different. This is the
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 old the old server, i.e. all media configuration information from the
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 are RECOMMENDED to usage of conditional SETUP using MTag identifiers are RECOMMENDED to
verify the assumption. 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
CSeq: 732 CSeq: 732
Location: rtsp://s2.example.com:8001 Location: rtsp://s2.example.com:8001
Terminate-Reason: Server-Admin ;time=19960213T143205Z Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
14. Embedded (Interleaved) Binary Data 14. Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. in In order to fulfill certain requirements on the network side, e.g.
conjunction with network address translators that block RTP traffic in conjunction with network address translators that block RTP
over UDP, it may be necessary to interleave RTSP messages and media traffic over UDP, it may be necessary to interleave RTSP messages and
stream data. This interleaving should generally be avoided unless media stream data. This interleaving should generally be avoided
necessary since it complicates client and server operation and unless necessary since it complicates client and server operation and
imposes additional overhead. Also, head of line blocking may cause imposes additional overhead. Also, head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP. Interleaved data is not allowed inside RTSP carried over TCP. Interleaved data is not allowed inside RTSP
messages. messages.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (36 decimal), followed by a one-byte channel identifier, sign (36 decimal), followed by a one-byte channel identifier,
followed by the length of the encapsulated binary data as a binary, followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows two-byte integer in network byte order. The stream data follows
immediately afterwards, without a CRLF, but including the upper-layer immediately afterwards, without a CRLF, but including the upper-layer
protocol headers. Each $ block MUST contain exactly one upper-layer protocol headers. Each $ block MUST contain exactly one upper-layer
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| "$" = 36 | Channel ID | Length in bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "$" = 36 | Channel ID | Length in bytes |
: Length number of bytes of binary data : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 18.52). interleaved parameter (Section 18.52).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including an interval containing a second channel in the indicated by including an interval containing a second channel in the
interleaved parameter of the Transport header, see Section 18.52. If interleaved parameter of the Transport header, see Section 18.52. If
RTCP is used, packets MUST be sent on the first available channel RTCP is used, packets MUST be sent on the first available channel
higher than the RTP channel. The channels are bi-directional, using higher than the RTP channel. The channels are bi-directional, using
skipping to change at page 97, line 39 skipping to change at page 91, line 10
has been cached and has not become stale. See the caching has been cached and has not become stale. See the caching
Section 16. This type of proxy is also expected to understand Section 16. This type of proxy is also expected to understand
RTSP end-point functionality, i.e., functionality identified in RTSP end-point functionality, i.e., functionality identified in
the Require header in addition to what Proxy-Require demands. the Require header in addition to what Proxy-Require demands.
Translator Proxy: This type of proxy is used to ensure that an RTSP Translator Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers and content on an external client gets access to servers and content on an external
network or using content encodings not supported by the client. network or using content encodings not supported by the client.
The proxy performs the necessary translation of addresses, The proxy performs the necessary translation of addresses,
protocols or encodings. This type of proxy is expected to also protocols or encodings. This type of proxy is expected to also
understand RTSP end-point functionality, i.e. functionality understand RTSP end-point functionality, i.e. functionality
identified in the Require header in addition to what Proxy- identified in the Require header in addition to what Proxy-
Require demands. Require demands.
Access Proxy: This type of proxy is used to ensure that an RTSP Access Proxy: This type of proxy is used to ensure that an RTSP
client gets access to servers on an external network. Thus client gets access to servers on an external network. Thus
this proxy is placed on the border between two domains, e.g. a this proxy is placed on the border between two domains, e.g. a
private address space and the public Internet. The proxy private address space and the public Internet. The proxy
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 also limit the client's access
to certain types of content. This proxy can perform its to certain types of content. This proxy can perform its
function without redirecting the media between the server and function without redirecting the media between the server and
client. However, in deployments with private address spaces client. However, in deployments with private address spaces
this proxy is likely to be combined with the access proxy. this proxy is likely to be combined with the access proxy.
Anyway, the functionality of this proxy is usually closely tied Anyway, the functionality of this proxy is usually closely tied
into 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 be used also when using secured All types of proxies can be used also when using secured
communication with TLS as RTSP 2.0 allows the client to approve communication with TLS as RTSP 2.0 allows the client to approve
certificate chains used for connection establishment from a proxy, certificate chains used for connection establishment from a proxy,
see Section 19.3.2. However, that trust model may not be suitable see Section 19.3.2. However, that trust model may not be suitable
for all types of deployment. In those cases, the secured sessions do for all types of deployment. In those cases, the secured sessions do
by-pass the proxies. by-pass the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters, etc. may fail in a proxy that protocols or profiles, new parameters, etc. may fail in a proxy that
isn't maintained. This would impede RTSP's future development and isn't maintained. This would impede RTSP's future development and
usage. usage.
15.1. Proxies and Protocol Extensions 15.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. Most types of proxies will need to implement new RTSP extensions. Most types of proxies will need to implement
any new method to operate correctly in the presence of that any new method to operate correctly in the presence of that
extension. New headers can be introduced and will not be blocked by extension. New headers can be introduced and will not be blocked by
older proxies. However, it is important to consider if this header older proxies. However, it is important to consider if this header
skipping to change at page 100, line 49 skipping to change at page 94, line 17
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. We call this "validating"
the cache entry. Since we do not want to have to pay the overhead of the cache entry. Since we do not want to have 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 we
do not want to pay the overhead of an extra round trip if the cached do not want to pay the overhead of an extra round trip if the cached
entry is invalid, the RTSP protocol supports the use of conditional entry is invalid, the RTSP protocol supports the use of conditional
methods. methods.
skipping to change at page 109, line 45 skipping to change at page 102, line 31
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server S->C: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
17.3.3. 303 See Other 17.3.3. 303 See Other
This status code MUST NOT be used in RTSP 2.0. However, it was This status code MUST NOT be used in RTSP 2.0. However, it was
allowed in RTSP 1.0 [RFC 2326]. allowed in RTSP 1.0 [RFC2326].
17.3.4. 304 Not Modified 17.3.4. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
Section 18.24) and the requested resource has not been modified, the Section 18.24) and the requested resource has not been modified, the
server SHOULD send a 304 response. This response MUST NOT contain a server SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 110, line 28 skipping to change at page 103, line 14
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is response to SETUP does NOT imply that the resource description is
unchanged. The MTag and If-Match headers may be used to link the unchanged. The MTag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner. DESCRIBE and SETUP in this manner.
17.3.5. 305 Use Proxy 17.3.5. 305 Use Proxy
The requested resource MUST be accessed through the proxy given by The requested resource MUST be accessed through the proxy given by
the Location field. The Location field gives the URI of the proxy. the Location field. The Location field gives the URI of the proxy.
The recipient is expected to repeat this single request via the The recipient is expected to repeat this single request via the
proxy. 305 responses MUST only be generated by origin servers. proxy. 305 responses MUST only be generated by origin servers.
17.4. Client Error 4xx 17.4. Client Error 4xx
17.4.1. 400 Bad Request 17.4.1. 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The client SHOULD NOT repeat the request without
modifications. If the request does not have a CSeq header, the modifications. If the request does not have a CSeq header, the
server MUST NOT include a CSeq in the response. server MUST NOT include a CSeq in the response.
skipping to change at page 114, line 8 skipping to change at page 106, line 44
17.4.16. 451 Parameter Not Understood 17.4.16. 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a message body containing the offending sender SHOULD return a message body containing the offending
parameter(s). parameter(s).
17.4.17. 452 reserved 17.4.17. 452 reserved
This status code MUST NOT be used in RTSP 2.0. However, it was This status code MUST NOT be used in RTSP 2.0. However, it was
allowed in RTSP 1.0 [RFC 2326]. allowed in RTSP 1.0 [RFC2326].
17.4.18. 453 Not Enough Bandwidth 17.4.18. 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
17.4.19. 454 Session Not Found 17.4.19. 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
skipping to change at page 118, line 34 skipping to change at page 111, line 20
| 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: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx
have a body to have a body
The general syntax for header fields is covered in Section 5.2. This The general syntax for header fields is covered in Section 5.2. This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
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, we use [HX.Y] to
informational refer to Section X.Y of the current HTTP/1.1 informational refer to Section X.Y of the current HTTP/1.1
specification RFC 2616 [RFC2616]. Examples of each header field are specification RFC 2616 [RFC2616]. Examples of each header field are
given. 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
Table 12. 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;
r: header field may only appear in responses; r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response codes 2xx, 4xx, etc.: A numerical value or range indicates response codes
with which the header field can be used; with which the header field can be used;
skipping to change at page 120, line 27 skipping to change at page 113, line 15
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 an URI. If the URI The From and Location header fields contain an 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 | Where | Pro | DES | OPT | STP | PL | PS | TR |
| | | xy | S | | | | | | | | | xy | | | | Y | E | D |
+------------------+-------+-----+----+-----+-----+-----+-----+-----+ +--------------------+-------+-----+-----+-----+-----+----+----+----+
| Accept | R | | o | - | - | - | - | - | | Accept | R | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Credentia | R | rm | o | o | o | o | o | o | | Accept-Credentials | R | rm | o | o | o | o | o | o |
| ls | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Accept-Encoding | R | r | o | - | - | - | - | - |
| Accept-Encoding | R | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Language | R | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Ranges | R | r | - | - | m | - | - | - |
| Accept-Ranges | R | r | - | - | m | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Accept-Ranges | r | r | - | - | m | - | - | - |
| Accept-Ranges | r | 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 | | | | | | | | | | |
| | | | | | | | | | | 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 | | r | o | - | o | - | - | - |
| Cache-Control | | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Connection | | ad | o | o | o | o | o | o |
| Connection | | ad | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Connection- | 470,4 | ar | o | o | o | o | o | o |
| Connection-Crede | 470,4 | ar | o | o | o | o | o | o | | Credentials | 07 | | | | | | | |
| ntials | 07 | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Base | r | | o | - | - | - | - | - |
| Content-Base | r | | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Base | 4xx,5 | | o | o | o | o | o | o |
| Content-Base | 4xx,5 | | o | o | o | o | o | o | | | xx | | | | | | | |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | 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 |
| Content-Encoding | 4xx,5 | r | o | o | o | o | o | o | | | xx | | | | | | | |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | 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 |
| Content-Language | 4xx,5 | r | o | o | o | o | o | o | | | xx | | | | | | | |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | r | r | * | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Length | 4xx,5 | r | * | * | * | * | * | * |
| Content-Length | 4xx,5 | r | * | * | * | * | * | * | | | xx | | | | | | | |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | r | r | o | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Location | 4xx,5 | r | o | o | o | o | o | o |
| Content-Location | 4xx,5 | r | o | o | o | o | o | o | | | xx | | | | | | | |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Content-Type | r | r | * | - | - | - | - | - |
| Content-Type | r | r | * | - | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Content-Type | 4xx,5 | ar | * | * | * | * | * | * |
| Content-Type | 4xx,5 | ar | * | * | * | * | * | * | | | xx | | | | | | | |
| | xx | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | CSeq | Rc | rm | m | m | m | m | m | m |
| CSeq | Rc | rm | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Date | | am | o/* | o/* | o/* | o/ | o/ | o/ |
| Date | | am | o/ | o/* | o/* | o/* | o/* | o/* | | | | | | | | * | * | * |
| | | | * | | | | | | | | | | | | | | | |
| | | | | | | | | | | Expires | r | r | o | - | o | - | - | - |
| Expires | r | r | o | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | From | R | r | o | o | o | o | o | o |
| From | R | r | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | If-Match | R | r | - | - | o | - | - | - |
| If-Match | R | r | - | - | o | - | - | - | | | | | | | | | | |
| | | | | | | | | | | If-Modified-Since | R | r | o | - | o | - | - | - |
| If-Modified-Sinc | R | r | o | - | o | - | - | - | | | | | | | | | | |
| e | | | | | | | | | | 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 | Prox | DES | OPT | STP | PLY | PSE | TRD | | Header | Where | Proxy | DES | OPT | STP | PL | PS | TR |
| | | y | | | | | | | | | | | | | | Y | E | D |
+----------------+-------+------+-----+-----+-----+-----+-----+-----+ +------------------+-------+-------+-----+-----+-----+----+----+----+
| Media- | | | - | - | m | m | m | - | | Media- | | | - | - | m | m | m | - |
| Properties | | | | | | | | | | Properties | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Media-Range | | | - | - | m | m | m | - | | Media-Range | | | - | - | m | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| MTag | r | r | o | - | o | - | - | - | | MTag | r | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Pipelined-Requ | | amdr | - | o | o | o | o | o | | Pipelined- | | amdr | - | o | o | o | o | o |
| ests | | | | | | | | | | Requests | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m | | Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | | | Authenticate | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| 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- | R | amr | c | c | c | c | c | c | | Proxy- Supported | R | amr | c | c | c | c | c | c |
| Supported | | | | | | | | | | | | | | | | | | |
| Proxy- | r | | c | c | c | c | c | c | | Proxy- Supported | r | | c | c | c | c | c | c |
| Supported | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Public | r | amr | - | m | - | - | - | - |
| Public | r | amr | - | m | - | - | - | - | | | | | | | | | | |
| | | | | | | | | | | Public | 501 | amr | m | m | m | m | m | m |
| Public | 501 | amr | m | m | m | m | m | m | | | | | | | | | | |
| | | | | | | | | | | Range | R | | - | - | - | o | - | - |
| Range | R | | - | - | - | o | - | - | | | | | | | | | | |
| | | | | | | | | | | Range | r | | - | - | c | m | m | - |
| Range | r | | - | - | c | m | m | - | | | | | | | | | | |
| | | | | | | | | | | Referrer | R | | o | o | o | o | o | o |
| Referrer | R | | o | o | o | o | o | o | | | | | | | | | | |
| | | | | | | | | | | Request- Status | R | | - | - | - | - | - | - |
| Request- | R | | - | - | - | - | - | - | | | | | | | | | | |
| Status | | | | | | | | | | Require | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Require | R | | o | o | o | o | o | o | | Retry-After | 3rr,5 | | o | o | o | o | o | - |
| | | | | | | | | | | | 03 | | | | | | | |
| Retry-After | 3rr,5 | | o | o | o | o | o | - | | | | | | | | | | |
| | 03 | | | | | | | | | Retry-After | 413 | | o | - | - | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - | | RTP-Info | r | | - | - | c | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| RTP-Info | r | | - | - | c | c | - | - | | Scale | R | r | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | R | r | - | - | - | o | - | - | | Scale | r | amr | - | - | - | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Scale | r | amr | - | - | - | c | - | - | | Seek-Style | R | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | R | | - | - | - | o | - | - | | Seek-Style | r | | - | - | - | m | - | - |
| | | | | | | | | | | | | | | | | | | |
| Seek-Style | r | | - | - | - | m | - | - | | Server | R | r | - | o | - | - | - | o |
| | | | | | | | | | | | | | | | | | | |
| Server | R | r | - | o | - | - | - | o | | Server | r | r | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Server | r | r | o | o | o | o | o | o | | Session | R | r | - | o | o | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Session | R | r | - | o | o | m | m | m | | Session | r | r | - | c | m | m | m | o |
| | | | | | | | | | | | | | | | | | | |
| Session | r | r | - | c | m | m | m | o | | Speed | R | admr | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Speed | R | admr | - | - | - | o | - | - | | Speed | r | admr | - | - | - | c | - | - |
| | | | | | | | | | | | | | | | | | | |
| Speed | r | admr | - | - | - | c | - | - | | Supported | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o | | Supported | r | amr | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Supported | r | amr | c | c | c | c | c | c | | Terminate-Reason | R | r | - | - | - | - | - | - |
| Terminate-Reas | R | r | - | - | - | - | - | - | | | | | | | | | | |
| on | | | | | | | | | | Timestamp | R | admr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | R | admr | o | o | o | o | o | o | | Timestamp | c | admr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Timestamp | c | admr | m | m | m | m | m | m | | Transport | | mr | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Transport | | mr | - | - | m | - | - | - | | Unsupported | r | | c | c | c | c | c | c |
| | | | | | | | | | | | | | | | | | | |
| Unsupported | r | | c | c | c | c | c | c | | User-Agent | R | | m* | m* | m* | m* | m* | m* |
| | | | | | | | | | | | | | | | | | | |
| User-Agent | R | | m* | m* | m* | m* | m* | m* | | Via | R | amr | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | o | o | o | | 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 |
| | | | | | | | | | | Authenticate | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m | +------------------+-------+-------+-----+-----+-----+----+----+----+
| 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 | - |
skipping to change at page 125, line 4 skipping to change at page 117, line 35
| | | | | | | | | | | | | | | |
| Authorization | R | | o | o | o | - | | Authorization | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Bandwidth | R | | - | o | - | - | | Bandwidth | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Blocksize | R | | - | o | - | - | | Blocksize | R | | - | o | - | - |
| | | | | | | | | | | | | | | |
| Cache-Control | | r | o | o | - | - | | Cache-Control | | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o | | Connection | | | o | o | o | o |
| | | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o | - | | Connection-Credentials | 470,407 | ar | o | o | o | - |
| | | | | | | | | | | | | | | |
| 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,5xx | | o | o | o | o |
| | | | | | | | | | | | | | | |
| Content-Encoding | R | r | o | o | - | - | | Content-Encoding | R | r | o | o | - | - |
| | | | | | | | | | | | | | | |
skipping to change at page 128, line 4 skipping to change at page 120, line 34
| | | | | | | | | | | | | | | |
| 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 | | mr | - | - | - | - | | Transport | | mr | - | - | - | - |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
| User-Agent | R | r | m* | m* | - | - | | User-Agent | R | r | m* | m* | - | - |
| | | | | | | |
| 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 [RFC4288] 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.
Example of use: Example of use:
Accept: application/example ;q=1.0, application/sdp
Accept: application/example ;q=1.0, application/sdp
18.2. Accept-Credentials 18.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 19 for the usage of this header. It proxies or servers. See Section 19 for the usage of this header. It
MUST NOT be included in server to client requests. MUST NOT be included in server to client requests.
In a request the header MUST contain the method (User, Proxy, or Any) In a request the header MUST contain the method (User, Proxy, or Any)
for approving credentials selected by the requester. The method MUST for approving credentials selected by the requester. The method MUST
skipping to change at page 129, line 11 skipping to change at page 121, line 49
token "sha-256". token "sha-256".
The intention with allowing for other hash algorithms is to enable The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited. A feature tag for this purpose is intended to be extremely limited. A feature tag
can be used to ensure that support for the replacement algorithm can be used to ensure that support for the replacement algorithm
exist. exist.
Example: Example:
Accept-Credentials:User Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
18.3. Accept-Encoding 18.3. Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (see Section 18.14),i.e. transformation restricts the content-codings (see Section 18.14),i.e.
codings of the message body, such as gzip compression, that are transformation codings of the message body, such as gzip compression,
acceptable in the response. that are acceptable in the response.
A server tests whether a content-coding is acceptable, according to A server tests whether a content-coding is acceptable, according to
an Accept-Encoding field, using these rules: an Accept-Encoding field, using these rules:
1. If the content-coding is one of the content-codings listed in the 1. If the content-coding is one of the content-codings listed in the
Accept-Encoding field, then it is acceptable, unless it is Accept-Encoding field, then it is acceptable, unless it is
accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of accompanied by a qvalue of 0. (As defined in [H3.9], a qvalue of
0 means "not acceptable.") 0 means "not acceptable.")
2. The special "*" symbol in an Accept-Encoding field matches any 2. The special "*" symbol in an Accept-Encoding field matches any
available content-coding not explicitly listed in the header available content-coding not explicitly listed in the header
field. field.
3. If multiple content-codings are acceptable, then the acceptable 3. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
4. The "identity" content-coding is always acceptable, i.e. no 4. The "identity" content-coding is always acceptable, i.e. no
transformation at all, unless specifically refused because the transformation at all, unless specifically refused because the
Accept-Encoding field includes "identity;q=0", or because the Accept-Encoding field includes "identity;q=0", or because the
field includes "*;q=0" and does not explicitly include the field includes "*;q=0" and does not explicitly include the
"identity" content-coding. If the Accept-Encoding field-value is "identity" content-coding. If the Accept-Encoding field-value is
empty, then only the "identity" encoding is acceptable. empty, then only the "identity" encoding is acceptable.
If an Accept-Encoding field is present in a request, and if the If an Accept-Encoding field is present in a request, and if the
server cannot send a response which is acceptable according to the server cannot send a response which is acceptable according to the
Accept-Encoding header, then the server SHOULD send an error response Accept-Encoding header, then the server SHOULD send an error response
with the 406 (Not Acceptable) status code. with the 406 (Not Acceptable) status code.
skipping to change at page 131, line 23 skipping to change at page 124, line 16
header in SETUP requests to indicate which formats it support to header in SETUP requests to indicate which formats it support to
receive in PLAY and PAUSE responses, and REDIRECT requests. The receive in PLAY and PAUSE responses, and REDIRECT requests. The
server MUST include the header in SETUP and 456 error responses to server MUST include the header in SETUP and 456 error responses to
indicate the formats supported for the resource indicated by the indicate the formats supported for the resource indicated by the
request URI. The header MAY be included in GET_PARAMETER request and request URI. The header MAY be included in GET_PARAMETER request and
response pairs. The GET_PARAMETER request MUST contain a Session response pairs. The GET_PARAMETER request MUST contain a Session
header to identify the session context the request is related to. header to identify the session context the request is related to.
The requester and responder will indicate their capabilities The requester and responder will indicate their capabilities
regarding Range formats respectively. regarding Range formats respectively.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
The syntax is defined in Section 20.2.3. The syntax is defined in Section 20.2.3.
18.6. Allow 18.6. Allow
The Allow message-header field lists the methods supported by the The Allow message-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. The Allow header MUST also be present in all Allowed) response. The Allow header MUST also be present in all
OPTIONS responses where the content of the header will not include OPTIONS responses where the content of the header will not include
exactly the same methods as listed in the Public header. exactly the same methods as listed in the Public header.
The Allow MUST also be included in SETUP and DESCRIBE responses, if The Allow MUST also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the complete the methods allowed for the resource is different than the complete
set of methods defined in this memo. set of methods defined in this memo.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
18.7. Authorization 18.7. Authorization
An RTSP client that wishes to authenticate itself with a server using An RTSP client that wishes to authenticate itself with a server using
authentication mechanism from HTTP [RFC2617] , usually, but not authentication mechanism from HTTP [RFC2617] , usually, but not
necessarily, after receiving a 401 response, does so by including an necessarily, after receiving a 401 response, does so by including an
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. resource being requested.
skipping to change at page 133, line 15 skipping to change at page 126, line 24
take into account other traffic sharing the bottleneck. For example take into account other traffic sharing the bottleneck. For example
by only assigning a certain fraction to RTSP and its media streams. by only assigning a certain fraction to RTSP and its media streams.
It is RECOMMENDED that only clients that have accurate and explicit It is RECOMMENDED that only clients that have accurate and explicit
information about bandwidth bottlenecks uses this header. information about bandwidth bottlenecks uses this header.
This header is not a substitute for proper congestion control. It is This header is not a substitute for proper congestion control. It is
only a method providing an initial estimate and coarsely determines only a method providing an initial estimate and coarsely determines
if the selected content can be delivered at all. if the selected content can be delivered at all.
Example: Example:
Bandwidth: 62360
Bandwidth: 62360
18.9. Blocksize 18.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block override it with the media-specific size if necessary. The block
skipping to change at page 139, line 23 skipping to change at page 132, line 31
"A First Lesson in Latin," which is clearly intended to be used by an "A First Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language would English-literate audience. In this case, the Content-Language would
properly only include "en". properly only include "en".
Content-Language MAY be applied to any media type -- it is not Content-Language MAY be applied to any media type -- it is not
limited to textual documents. limited to textual documents.
18.16. Content-Length 18.16. Content-Length
The Content-Length general-header field contains the length of the The Content-Length general-header field contains the length of the
message body of the RTSP message (i.e. after the double CRLF message body of the RTSP message (i.e. after the double CRLF
following the last header). Unlike HTTP, it MUST be included in all following the last header). Unlike HTTP, it MUST be included in all
messages that carry a message body beyond the header portion of the messages that carry a message body beyond the header portion of the
RTSP message. If it is missing, a default value of zero is assumed. RTSP message. If it is missing, a default value of zero is assumed.
Any Content-Length greater than or equal to zero is a valid value. Any Content-Length greater than or equal to zero is a valid value.
18.17. Content-Location 18.17. Content-Location
The Content-Location header field MAY be used to supply the resource The Content-Location header field MAY be used to supply the resource
location for the message body enclosed in the message when that body location for the message body enclosed in the message when that body
is accessible from a location separate from the requested resource's is accessible from a location separate from the requested resource's
skipping to change at page 139, line 47 skipping to change at page 133, line 7
entities actually have separate locations by which they might be entities actually have separate locations by which they might be
individually accessed, the server SHOULD provide a Content-Location individually accessed, the server SHOULD provide a Content-Location
for the particular variant which is returned. for the particular variant which is 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 142, line 43 skipping to change at page 136, line 17
the origin server (or with an intermediate cache that has a fresh the origin server (or with an intermediate cache that has a fresh
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: Thu, 01 Dec 1994 16:00:00 GMT
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.22. From 18.22. 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 144, line 16 skipping to change at page 137, line 40
18.24. If-Modified-Since 18.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
stream will not be set up (SETUP). Instead, a 304 (Not Modified) stream will not be set up (SETUP). Instead, a 304 (Not Modified)
response MUST be returned without any message-body. response MUST be returned without any message-body.
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
18.25. If-None-Match 18.25. If-None-Match
This request header can be used with one or several message body tags This request header can be used with one or several message body tags
to make DESCRIBE requests conditional. A client that has one or more to make DESCRIBE requests conditional. A client that has one or more
message bodies previously obtained from the resource, can verify that message bodies previously obtained from the resource, can verify that
none of those entities is current by including a list of their none of those entities is current by including a list of their
associated message body tags in the If-None-Match header field. The associated message body tags in the If-None-Match header field. The
purpose of this feature is to allow efficient updates of cached purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead. As a information with a minimum amount of transaction overhead. As a
skipping to change at page 146, line 42 skipping to change at page 140, line 17
multiple properties SHOULD NOT be used. The list of properties that multiple properties SHOULD NOT be used. The list of properties that
can be expressed MAY be extended at any time. Unknown property can be expressed MAY be extended at any time. Unknown property
values MUST be ignored. values MUST be ignored.
This specification defines the following 4 groups and their property This specification defines the following 4 groups and their property
values: values:
Random Access: Random Access:
Random-Access: Indicates that random access is possible. May Random-Access: Indicates that random access is possible. May
optionally include a floating point value in seconds indicating optionally include a floating point value in seconds
the longest duration between any two random access points in indicating the longest duration between any two random
the media. access points in the media.
Begining-Only: Seeking is limited to the beginning only. Begining-Only: Seeking is limited to the beginning only.
No-Seeking: No seeking is possible. No-Seeking: No seeking is possible.
Content Modifications: Content Modifications:
Immutable: The content will not be changed during the life-time Immutable: The content will not be changed during the life-time
of the RTSP session. of the RTSP session.
Dynamic: The content may be changed based on external methods or Dynamic: The content may be changed based on external methods or
triggers triggers
Time-Progressing The media accessible progresses as wallclock Time-Progressing The media accessible progresses as wallclock
time progresses. time progresses.
Retention: Retention:
Unlimited: Content will be retained for the duration of the life- Unlimited: Content will be retained for the duration of the life-
time of the RTSP session. time of the RTSP session.
Time-Limited: Content will be retained at least until the Time-Limited: Content will be retained at least until the
specified wallclock time. The time must be provided in the specified wallclock time. The time must be provided in the
absolute time format specified in Section 4.6. absolute time format specified in Section 4.6.
Time-Duration Each individual media unit is retained for at least Time-Duration Each individual media unit is retained for at least
the specified time duration. This definition allows for the specified time duration. This definition allows for
retaining data with a time based sliding window. The time retaining data with a time based sliding window. The time
duration is expressed as floating point number in seconds. 0.0 duration is expressed as floating point number in seconds.
is a valid value as this indicates that no data is retained in 0.0 is a valid value as this indicates that no data is
a time-progressing session. retained in a time-progressing session.
Supported Scale: Supported Scale:
Scales: A quoted comma separated list of one or more decimal Scales: A quoted comma separated list of one or more decimal
values or ranges of scale values supported by the content in values or ranges of scale values supported by the content in
arbitrary order. A range has a start and stop value separated arbitrary order. A range has a start and stop value
by a colon. A range indicates that the content supports fine separated by a colon. A range indicates that the content
grained selection of scale values. Fine grained allows for supports fine grained selection of scale values. Fine
steps at least as small as one tenth of a scale value. A grained allows for steps at least as small as one tenth of a
content is considered to support fine grained selection when scale value. A content is considered to support fine
the server in response to a given scale value can produce grained selection when the server in response to a given
content with an actual scale that is less than 1 tenth of scale scale value can produce content with an actual scale that is
unit, i.e., 0.1, from the requested value. Negative values are less than 1 tenth of scale unit, i.e., 0.1, from the
supported. The value 0 has no meaning and MUST NOT be used. requested value. Negative values are supported. The value
0 has no meaning and MUST NOT be used.
Examples of this header for on-demand content and a live stream Examples of this header for on-demand content and a live stream
without recording are: without recording are:
On-demand: On-demand:
Media-Properties: Random-Access=2.5s, Unlimited, Immutable, Media-Properties: Random-Access=2.5s, Unlimited, Immutable,
Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20" Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
Live stream without recording/timeshifting: Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
skipping to change at page 148, line 43 skipping to change at page 142, line 13
However, it shall be assumed that media time progresses in direct However, it shall be assumed that media time progresses in direct
relationship to wallclock time (with the exception of clock skew) so relationship to wallclock time (with the exception of clock skew) so
that a reasonably accurate estimation of the media range can be that a reasonably accurate estimation of the media range can be
calculated. calculated.
18.30. MTag 18.30. MTag
The MTag response header MAY be included in DESCRIBE, GET_PARAMETER The MTag response header MAY be included in DESCRIBE, GET_PARAMETER
or SETUP responses. The message body tags (Section 4.8) returned in or SETUP responses. The message body tags (Section 4.8) returned in
a DESCRIBE response, and the one in SETUP refers to the presentation, a DESCRIBE response, and the one in SETUP refers to the presentation,
i.e. both the returned session description and the media stream. i.e. both the returned session description and the media stream.
This allows for verification that one has the right session This allows for verification that one has the right session
description to a media resource at the time of the SETUP request. description to a media resource at the time of the SETUP request.
However, it has the disadvantage that a change in any of the parts However, it has the disadvantage that a change in any of the parts
results in invalidation of all the parts. results in invalidation of all the parts.
If the MTag is provided both inside the message body, e.g. within the If the MTag is provided both inside the message body, e.g. within
"a=mtag" attribute in SDP, and in the response message, then both the "a=mtag" attribute in SDP, and in the response message, then both
tags MUST be identical. It is RECOMMENDED that the MTag is primarily tags MUST be identical. It is RECOMMENDED that the MTag is primarily
given in the RTSP response message, to ensure that caches can use the given in the RTSP response message, to ensure that caches can use the
MTag without requiring content inspection. However, for session MTag without requiring content inspection. However, for session
descriptions that are distributed outside of RTSP, for example using descriptions that are distributed outside of RTSP, for example using
HTTP, etc. it will be necessary to include the message body tag in HTTP, etc. it will be necessary to include the message body tag in
the session description as specified in Appendix D.1.9. the session description as specified in Appendix D.1.9.
SETUP and DESCRIBE requests can be made conditional upon the MTag SETUP and DESCRIBE requests can be made conditional upon the MTag
using the headers If-Match (Section 18.23) and If-None-Match ( using the headers If-Match (Section 18.23) and If-None-Match (
Section 18.25). Section 18.25).
18.31. Notify-Reason 18.31. Notify-Reason
The Notify Reason header is solely used in the PLAY_NOTIFY method. The Notify Reason header is solely used in the PLAY_NOTIFY method.
It indicates the reason why the server has sent the asynchronous It indicates the reason why the server has sent the asynchronous
skipping to change at page 151, line 25 skipping to change at page 144, line 44
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 18.41 for more details on the mechanics of this message See Section 18.41 for more details on the mechanics of this message
and a usage example. See discussion in the proxies section and a usage example. See discussion in the proxies section
(Section 15.1) about when to consider that a feature requires proxy (Section 15.1) about when to consider that a feature requires proxy
support. support.
Example of use: Example of use:
Proxy-Require: play.basic
Proxy-Require: play.basic
18.36. Proxy-Supported 18.36. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
MUST be added by any proxy if the Supported header is present in a MUST be added by any proxy if the Supported header is present in a
request. When present in a request, the receiver MUST in the request. When present in a request, the receiver MUST in the
response copy the received Proxy-Supported header. response copy the received Proxy-Supported header.
skipping to change at page 152, line 36 skipping to change at page 146, line 6
The Public response header field lists the set of methods supported The Public response header field lists the set of methods supported
by the response sender. This header applies to the general by the response sender. This header applies to the general
capabilities of the sender and its only purpose is to indicate the capabilities of the sender and its only purpose is to indicate the
sender's capabilities to the recipient. The methods listed may or sender's capabilities to the recipient. The methods listed may or
may not be applicable to the Request-URI; the Allow header field may not be applicable to the Request-URI; the Allow header field
(Section 18.6) MAY be used to indicate methods allowed for a (Section 18.6) MAY be used to indicate methods allowed for a
particular URI. particular URI.
Example of use: Example of use:
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
In the event that there are proxies between the sender and the In the event that there are proxies between the sender and the
recipient of a response, each intervening proxy MUST modify the recipient of a response, each intervening proxy MUST modify the
Public header field to remove any methods that are not supported via Public header field to remove any methods that are not supported via
that proxy. The resulting Public header field will contain an that proxy. The resulting Public header field will contain an
intersection of the sender's methods and the methods allowed through intersection of the sender's methods and the methods allowed through
by the intervening proxies. by the intervening proxies.
In general, proxies should allow all methods to transparently pass In general, proxies should allow all methods to transparently pass
through from the sending RTSP agent to the receiving RTSP agent, through from the sending RTSP agent to the receiving RTSP agent,
skipping to change at page 153, line 34 skipping to change at page 147, line 6
(Section 4.6) range units. While byte ranges [H14.35.1] and other (Section 4.6) range units. While byte ranges [H14.35.1] and other
extended units MAY be used, their behavior is unspecified since they extended units MAY be used, their behavior is unspecified since they
are not normally meaningful in RTSP. Servers supporting the Range are not normally meaningful in RTSP. Servers supporting the Range
header MUST understand the NPT range format and SHOULD understand the header MUST understand the NPT range format and SHOULD understand the
SMPTE range format. If the Range header is sent in a time format SMPTE range format. If the Range header is sent in a time format
that is not understood, the recipient SHOULD return 456 (Header Field that is not understood, the recipient SHOULD return 456 (Header Field
Not Valid for Resource) and include an Accept-Ranges header Not Valid for Resource) and include an Accept-Ranges header
indicating the supported time formats for the given resource. indicating the supported time formats for the given resource.
Example: Example:
Range: clock=19960213T143205Z-
Range: clock=19960213T143205Z-
The Range header contains a range of one single range format. A The Range header contains a range of one single range format. A
range is a half-open interval with a start and an end point, range is a half-open interval with a start and an end point,
including the start point, but excluding the end point. A range may including the start point, but excluding the end point. A range may
either be fully specified with explicit values for start point and either be fully specified with explicit values for start point and
end point, or have either start or end point be implicit. An end point, or have either start or end point be implicit. An
implicit start point indicates the session's pause point, and if no implicit start point indicates the session's pause point, and if no
pause point is set the start of the content. An implicit end point pause point is set the start of the content. An implicit end point
indicates the end of the content. The usage of both implicit start indicates the end of the content. The usage of both implicit start
and end point is not allowed in the same range header, however, the and end point is not allowed in the same range header, however, the
exclusion of the range header has that meaning, i.e. from pause point exclusion of the range header has that meaning, i.e. from pause
(or start) until end of content. point (or start) until end of content.
Regarding the half-open intervals; a range of A-B starts exactly Regarding the half-open intervals; a range of A-B starts exactly
at time A, but ends just before B. Only the start time of a media at time A, but ends just before B. Only the start time of a media
unit such as a video or audio frame is relevant. For example, unit such as a video or audio frame is relevant. For example,
assume that video frames are generated every 40 ms. A range of assume that video frames are generated every 40 ms. A range of
10.0-10.1 would include a video frame starting at 10.0 or later 10.0-10.1 would include a video frame starting at 10.0 or later
time and would include a video frame starting at 10.08, even time and would include a video frame starting at 10.08, even
though it lasted beyond the interval. A range of 10.0-10.08, on though it lasted beyond the interval. A range of 10.0-10.08, on
the other hand, would exclude the frame at 10.08. the other hand, would exclude the frame at 10.08.
Please note the difference between NPT time scales' "now" and an Please note the difference between NPT time scales' "now" and an
implicit start value. Implicit value reference the current pause- implicit start value. Implicit value reference the current pause-
point. While "now" is the currently ongoing time. In a time- point. While "now" is the currently ongoing time. In a time-
progressing session with recording (retention for some or full progressing session with recording (retention for some or full
time) the pause point may be 2 min into the session while now time) the pause point may be 2 min into the session while now
could be 1 hour into the session. could be 1 hour into the session.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15
Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
Section 18.44) indicates a negative scale value. For example, this Section 18.44) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1
Range: npt=15-10 Scale: -1
Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above Thus, for range A-B, A is closed and B is open. In the above
example, 15 is closed and 10 is open. An exception to this rule is example, 15 is closed and 10 is open. An exception to this rule is
the case when B=0 in a decreasing range. In this case, the range is the case when B=0 in a decreasing range. In this case, the range is
closed on both ends, as otherwise there would be no way to reach 0 on closed on both ends, as otherwise there would be no way to reach 0 on
a reverse playback for formats that have such a notion, like NPT and a reverse playback for formats that have such a notion, like NPT and
SMPTE. SMPTE.
Example: Example:
Scale: -1
Range: npt=15-0 Scale: -1
Range: npt=15-0
In this range both 15 and 0 are closed. In this range both 15 and 0 are closed.
A decreasing range interval without a corresponding negative Scale A decreasing range interval without a corresponding negative Scale
header is not valid. header is not valid.
18.39. Referrer 18.39. Referrer
The Referrer request-header field allows the client to specify, for The Referrer request-header field allows the client to specify, for
the server's benefit, the address (URI) of the resource from which the server's benefit, the address (URI) of the resource from which
skipping to change at page 155, line 18 skipping to change at page 148, line 46
a source that does not have its own URI, such as input from the user a source that does not have its own URI, such as input from the user
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.
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.40. Request-Status 18.40. 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 takes time to complete, such a PLAY (Section 13.4). It is sent that takes time to complete, such a 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 160, line 20 skipping to change at page 154, line 21
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY MUST indicate this with the use of the "play.scale" feature-tag. PLAY MUST indicate this with the use of the "play.scale" feature-tag.
When indicating a negative scale for a reverse playback, the Range When indicating a negative scale for a reverse playback, the Range
header MUST indicate a decreasing range as described in header MUST indicate a decreasing range as described in
Section 18.38. Section 18.38.
Example of playing in reverse at 3.5 times normal rate: Example of playing in reverse at 3.5 times normal rate:
Scale: -3.5
Range: npt=15-10 Scale: -3.5
Range: npt=15-10
18.45. Seek-Style 18.45. Seek-Style
When a client sends a PLAY request with a Range header to perform a When a client sends a PLAY request with a Range header to perform a
random access to the media, the client does not know if the server random access to the media, the client does not know if the server
will pick the first media samples or the first random access point will pick the first media samples or the first random access point
prior to the request range. Depending on use case, the client may prior to the request range. Depending on use case, the client may
have a strong preference. To express this preference and provide the have a strong preference. To express this preference and provide the
client with information on how the server actually acted on that client with information on how the server actually acted on that
preference the Seek-Style header is defined. preference the Seek-Style header is defined.
skipping to change at page 163, line 26 skipping to change at page 157, line 33
session keep-alives are needed values smaller than 30 seconds are not session keep-alives are needed values smaller than 30 seconds are not
recommended. However, larger than default values can be useful in recommended. However, larger than default values can be useful in
applications of RTSP that have inactive but established sessions for applications of RTSP that have inactive but established sessions for
longer time periods. longer time periods.
60 seconds was chosen as session timeout value due to: Resulting 60 seconds was chosen as session timeout value due to: Resulting
in not too frequent keep-alive messages and having low sensitivity in not too frequent keep-alive messages and having low sensitivity
to variations in request response timing. If one reduces the to variations in request response timing. If one reduces the
timeout value to below 30 seconds the corresponding request timeout value to below 30 seconds the corresponding request
response timeout becomes a significant part of the session response timeout becomes a significant part of the session
timeout. 60 seconds also allows for reasonably rapid recovery of timeout. 60 seconds also allows for reasonably rapid recovery of
committed server resources in case of client failure. committed server resources in case of client failure.
18.48. Speed 18.48. Speed
The Speed request-header field requests the server to deliver The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time, specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to stream at the given speed. The client requests the delivery speed to
be within a given range with a lower and upper bound. The server be within a given range with a lower and upper bound. The server
SHALL deliver at the highest possible speed within the range, but not SHALL deliver at the highest possible speed within the range, but not
skipping to change at page 164, line 14 skipping to change at page 158, line 23
specified in the form "lower bound - upper bound". The lower bound specified in the form "lower bound - upper bound". The lower bound
value may be smaller or equal to the upper bound. All speeds may not value may be smaller or equal to the upper bound. All speeds may not
be possible to support. Therefore the server MAY modify the be possible to support. Therefore the server MAY modify the
requested values to the closest supported. The actual supported requested values to the closest supported. The actual supported
speed MUST be included in the response. Note, however, that the use speed MUST be included in the response. Note, however, that the use
cases may vary and that Speed value ranges such as 0.7 - 0.8, cases may vary and that Speed value ranges such as 0.7 - 0.8,
0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage. 0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage.
Example: Example:
Speed: 1.0-2.5 Speed: 1.0-2.5
Use of this header changes the bandwidth used for data delivery. It Use of this header changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where delivery of the is meant for use in specific circumstances where delivery of the
presentation at a higher or lower rate is desired. The main use presentation at a higher or lower rate is desired. The main use
cases are buffer operations or local scale operations. Implementors cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate. ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server Thus the media transport needs to support feedback so that the server
skipping to change at page 166, line 39 skipping to change at page 160, line 44
The Transport header MAY also be used in subsequent SETUP requests to The Transport header MAY also be used in subsequent SETUP requests to
change transport parameters. A server MAY refuse to change change transport parameters. A server MAY refuse to change
parameters of an existing stream. parameters of an existing stream.
A transport specification may only contain one of any given parameter A transport specification may only contain one of any given parameter
within it. Parameters MAY be given in any order. Additionally, it within it. Parameters MAY be given in any order. Additionally, it
may only contain either of the unicast or the multicast transport may only contain either of the unicast or the multicast transport
type parameter. All parameters need to be understood in a transport type parameter. All parameters need to be understood in a transport
specification, if not, the transport specification MUST be ignored. specification, if not, the transport specification MUST be ignored.
An RTSP proxy of any type that uses or modifies the transport An RTSP proxy of any type that uses or modifies the transport
specification, e.g. access proxy or security proxy, MUST remove specification, e.g. access proxy or security proxy, MUST remove
specifications with unknown parameters before forwarding the RTSP specifications with unknown parameters before forwarding the RTSP
message. If that results in no remaining transport specification the message. If that results in no remaining transport specification the
proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26) proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.26)
response without any Transport header. response without any Transport header.
The Transport header is restricted to describing a single media The Transport header is restricted to describing a single media
stream. (RTSP can also control multiple streams as a single stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
skipping to change at page 167, line 40 skipping to change at page 161, line 47
dest_addr with client picked address: The address and relevant dest_addr with client picked address: The address and relevant
parameters, like TTL (scope), for the actual multicast group to parameters, like TTL (scope), for the actual multicast group to
deliver the media to. There are security implications deliver the media to. There are security implications
(Section 21) with this method that need to be addressed if (Section 21) with this method that need to be addressed if
using this method because a RTSP server can be used as a DoS using this method because a RTSP server can be used as a DoS
attacker on an existing multicast group. attacker on an existing multicast group.
dest_addr using Session Description Information: The information dest_addr using Session Description Information: The information
included in the transport header can all be coming from the included in the transport header can all be coming from the
session description, e.g. the SDP c= and m= line. This session description, e.g. the SDP c= and m= line. This
mitigates some of the security issues of the previous methods mitigates some of the security issues of the previous methods
as it is the session provider that picks the multicast group as it is the session provider that picks the multicast group
and scope. The client MUST include the information if it is and scope. The client MUST include the information if it is
available in the session description. available in the session description.
No dest_addr: The behavior when no explicit multicast group is No dest_addr: The behavior when no explicit multicast group is
present in a request is not defined. present in a request is not defined.
An RTSP proxy will need to take care. If the media is not desired to An RTSP proxy will need to take care. If the media is not desired to
be routed through the proxy, the proxy will need to introduce the be routed through the proxy, the proxy will need to introduce the
skipping to change at page 177, line 28 skipping to change at page 171, line 32
enforce policies to each trusted proxy of whether it should accept enforce policies to each trusted proxy of whether it should accept
the next agent in the chain. However, it should be noted that not the next agent in the chain. However, it should be noted that not
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 proxy MUST, when
initiating the next hop TLS connection, use the incoming TLS initiating the next hop TLS connection, use the incoming TLS
connections cipher suite list, only modified by removing any cipher connections cipher suite list, only modified by removing any cipher
suites that the proxy does not support. In case a proxy fails to suites that the proxy does not support. In case a proxy fails to
establish a TLS connection due to cipher suite mismatch between proxy establish a TLS connection due to cipher suite mismatch between proxy
and next hop proxy or server, this is indicated using error code 472 and next hop proxy or server, this is indicated using error code 472
(Failure to establish secure connection). (Failure to establish secure connection).
19.3.1. Accept-Credentials 19.3.1. Accept-Credentials
skipping to change at page 190, line 51 skipping to change at page 183, line 18
/ ( 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 / "*"
skipping to change at page 195, line 5 skipping to change at page 186, line 43
MTag = "MTag" HCOLON message-tag MTag = "MTag" HCOLON message-tag
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream" Notify-Reas-val = "end-of-stream"
/ "media-properties-update" / "media-properties-update"
/ "scale-change" / "scale-change"
/ Notify-Reason-extension / Notify-Reason-extension
Notify-Reason-extension = token Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT startup-id = 1*8DIGIT
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = challenge *(COMMA challenge) challenge-list = challenge *(COMMA challenge)
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge / other-challenge
other-challenge = auth-scheme LWS auth-param other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param) *(COMMA auth-param)
digest-cln = realm / domain / nonce digest-cln = realm / domain / nonce
/ opaque / stale / algorithm / opaque / stale / algorithm
/ qop-options / auth-param / qop-options / auth-param
realm = "realm" EQUAL realm-value realm = "realm" EQUAL realm-value
realm-value = quoted-string realm-value = quoted-string
domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref domain = "domain" EQUAL LDQUOT RTSP-REQ-Ref
*(1*SP RTSP-REQ-Ref ) RDQUOT *(1*SP RTSP-REQ-Ref ) RDQUOT
nonce = "nonce" EQUAL nonce-value nonce = "nonce" EQUAL nonce-value
nonce-value = quoted-string nonce-value = quoted-string
opaque = "opaque" EQUAL quoted-string opaque = "opaque" EQUAL quoted-string
stale = "stale" EQUAL ( "true" / "false" ) stale = "stale" EQUAL ( "true" / "false" )
algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token) algorithm = "algorithm" EQUAL ("MD5" / "MD5-sess" / token)
qop-options = "qop" EQUAL LDQUOT qop-value qop-options = "qop" EQUAL LDQUOT qop-value
*("," qop-value) RDQUOT *("," qop-value) RDQUOT
qop-value = "auth" / "auth-int" / token qop-value = "auth" / "auth-int" / token
Proxy-Require = "Proxy-Require" HCOLON feature-tag-list Proxy-Require = "Proxy-Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list] Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list]
Public = "Public" HCOLON Method *(COMMA Method) Public = "Public" HCOLON Method *(COMMA Method)
Range = "Range" HCOLON ranges-spec Range = "Range" HCOLON ranges-spec
ranges-spec = npt-range / utc-range / smpte-range ranges-spec = npt-range / utc-range / smpte-range
/ range-ext / range-ext
range-ext = extension-format ["=" range-value] range-ext = extension-format ["=" range-value]
range-value = 1*(rtsp-unreserved / quoted-string / ":" ) range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref)
Request-Status = "Request-Status" HCOLON req-status-info Request-Status = "Request-Status" HCOLON req-status-info
req-status-info = cseq-info LWS status-info LWS reason-info req-status-info = cseq-info LWS status-info LWS reason-info
cseq-info = "cseq" EQUAL cseq-nr cseq-info = "cseq" EQUAL cseq-nr
status-info = "status" EQUAL Status-Code status-info = "status" EQUAL Status-Code
reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE
Require = "Require" HCOLON feature-tag-list Require = "Require" HCOLON feature-tag-list
RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec
*(COMMA rtsp-info-spec)]
rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter)
ri-parameter = ("seq" EQUAL 1*5DIGIT)
/ ("rtptime" EQUAL 1*10DIGIT)
/ generic-param
Retry-After = "Retry-After" HCOLON ( RTSP-date / delta-seconds ) RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec
Scale = "Scale" HCOLON scale-value *(COMMA rtsp-info-spec)]
Seek-Style = "Seek-Style" HCOLON Seek-S-values rtsp-info-spec = stream-url 1*ssrc-parameter
Seek-S-values = "RAP" stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE
/ "CoRAP" ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
/ "First-Prior" ri-parameter *(SEMI ri-parameter)
/ "Next" ri-parameter = ("seq" EQUAL 1*5DIGIT)
/ Seek-S-value-ext / ("rtptime" EQUAL 1*10DIGIT)
Seek-S-value-ext = token / generic-param
Server = "Server" HCOLON ( product / comment ) Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds)
*(LWS (product / comment)) Scale = "Scale" HCOLON scale-value
product = token [SLASH product-version] Seek-Style = "Seek-Style" HCOLON Seek-S-values
product-version = token Seek-S-values = "RAP"
comment = LPAREN *( ctext / quoted-pair) RPAREN / "CoRAP"
/ "First-Prior"
/ "Next"
/ Seek-S-value-ext
Seek-S-value-ext = token
Session = "Session" HCOLON session-id Server = "Server" HCOLON ( product / comment )
[ SEMI "timeout" EQUAL delta-seconds ] *(LWS (product / comment))
product = token [SLASH product-version]
product-version = token
comment = LPAREN *( ctext / quoted-pair) RPAREN
Speed = "Speed" HCOLON lower-bound MINUS upper-bound Session = "Session" HCOLON session-id
lower-bound = POS-FLOAT [ SEMI "timeout" EQUAL delta-seconds ]
upper-bound = POS-FLOAT
Speed = "Speed" HCOLON lower-bound MINUS upper-bound
lower-bound = POS-FLOAT
upper-bound = POS-FLOAT
Supported = "Supported" HCOLON [feature-tag-list]
Supported = "Supported" HCOLON [feature-tag-list]
Terminate-Reason = "Terminate-Reason" HCOLON TR-Info Terminate-Reason = "Terminate-Reason" HCOLON TR-Info
TR-Info = TR-Reason *(SEMI TR-Parameter) TR-Info = TR-Reason *(SEMI TR-Parameter)
TR-Reason = "Session-Timeout" TR-Reason = "Session-Timeout"
/ "Server-Admin" / "Server-Admin"
/ "Internal-Error" / "Internal-Error"
/ token / token
TR-Parameter = TR-time / TR-user-msg / generic-param TR-Parameter = TR-time / TR-user-msg / generic-param
TR-time = "time" EQUAL utc-time TR-time = "time" EQUAL utc-time
TR-user-msg = "user-msg" EQUAL quoted-string TR-user-msg = "user-msg" EQUAL quoted-string
skipping to change at page 198, line 5 skipping to change at page 188, line 48
delay = *9DIGIT [ "." *9DIGIT ] delay = *9DIGIT [ "." *9DIGIT ]
Transport = "Transport" HCOLON transport-spec Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec) *(COMMA transport-spec)
transport-spec = transport-id *trns-parameter transport-spec = transport-id *trns-parameter
transport-id = trans-id-rtp / other-trans transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport] trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id ; no LWS is allowed inside transport-id
other-trans = token *("/" token) other-trans = token *("/" token)
profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token
lower-transport = "TCP" / "UDP" / token lower-transport = "TCP" / "UDP" / token
trns-parameter = (SEMI ( "unicast" / "multicast" )) trns-parameter = (SEMI ( "unicast" / "multicast" ))
/ (SEMI "interleaved" EQUAL channel [ "-" channel ]) / (SEMI "interleaved" EQUAL channel ["-" channel])
/ (SEMI "ttl" EQUAL ttl) / (SEMI "ttl" EQUAL ttl)
/ (SEMI "layers" EQUAL 1*DIGIT) / (SEMI "layers" EQUAL 1*DIGIT)
/ (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ (SEMI "mode" EQUAL mode-spec) / (SEMI "mode" EQUAL mode-spec)
/ (SEMI "dest_addr" EQUAL addr-list) / (SEMI "dest_addr" EQUAL addr-list)
/ (SEMI "src_addr" EQUAL addr-list) / (SEMI "src_addr" EQUAL addr-list)
/ (SEMI "setup" EQUAL contrans-setup) / (SEMI "setup" EQUAL contrans-setup)
/ (SEMI "connection" EQUAL contrans-con) / (SEMI "connection" EQUAL contrans-con)
/ (SEMI "RTCP-mux") / (SEMI "RTCP-mux")
/ (SEMI "MIKEY" EQUAL MIKEY-Value) / (SEMI "MIKEY" EQUAL MIKEY-Value)
/ (SEMI trn-param-ext) / (SEMI trn-param-ext)
contrans-setup = "active" / "passive" / "actpass" contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing" contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value] trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token par-name = token
trn-par-value = *(rtsp-unreserved / quoted-string) trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX ssrc = 8HEX
channel = 1*3DIGIT ; 0 to 255 channel = 1*3DIGIT ; 0 to 255
MIKEY-Value = base64 MIKEY-Value = base64
mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE ) mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / token mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr) addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE
host-port = ( host [":" port] ) host-port = ( host [":" port] )
/ ( ":" port ) / ( ":" port )
extension-addr = 1*qdtext extension-addr = 1*qdtext
host = < As defined in RFC 3986> host = < As defined in RFC 3986>
port = < As defined in RFC 3986> port = < As defined in RFC 3986>
Unsupported = "Unsupported" HCOLON feature-tag-list Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment ) User-Agent = "User-Agent" HCOLON ( product / comment )
*(LWS (product / comment)) *(LWS (product / comment))
field-name-list = field-name *(COMMA field-name) field-name-list = field-name *(COMMA field-name)
field-name = token field-name = token
Via = "Via" HCOLON via-parm *(COMMA via-parm) Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr via-params = via-ttl / via-maddr
skipping to change at page 201, line 45 skipping to change at page 192, line 27
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Session hijacking: Since there is no or little relation between a Session hijacking: Since there is no or little relation between a
transport layer connection and an RTSP session, it is possible transport layer connection and an RTSP session, it is possible
for a malicious client to issue requests with random session for a malicious client to issue requests with random session
identifiers which could affect other clients of an unsuspecting identifiers which could affect other clients of an unsuspecting
server. To mitigate this the server SHALL use a large, random server. To mitigate this the server SHALL use a large, random
and non-sequential session identifier to minimize the and non-sequential session identifier to minimize the
possibility of this kind of attack. However, unless the RTSP possibility of this kind of attack. However, unless the RTSP
signaling is always confidentiality protected, e.g. using TLS, signaling is always confidentiality protected, e.g. using TLS,
an on-path attacker will be able to hijack a session. To an on-path attacker will be able to hijack a session. To
prevent session hijacking client authentication needs to be prevent session hijacking client authentication needs to be
performed and only the authenticated client creating the performed and only the authenticated client creating the
session SHALL be able to access that session. session SHALL be able to access that session.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[RFC2617] authentication. In environments requiring tighter [RFC2617] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS [RFC5246] SHOULD be used. mechanism TLS [RFC5246] SHOULD be used.
skipping to change at page 213, line 16 skipping to change at page 203, line 19
o A registration is required to name a contact person. o A registration is required to name a contact person.
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.
This specification registers the following values: This specification registers the following values:
Any Any
Proxy Proxy
User User
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 MUST fulfill the following
skipping to change at page 214, line 14 skipping to change at page 204, line 21
o Name of the directive and a definition of the value, if any. o Name of the directive and a definition of the value, if any.
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.
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
skipping to change at page 226, line 40 skipping to change at page 216, line 23
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
Values: See ABNF definition Values: See ABNF definition
22.16. Media Type Registration for text/parameters 22.16. Media Type Registration for text/parameters
Type name: text Type name: text
Subtype name: parameters Subtype name: parameters
Required parameters:
Optional parameters: charset: The charset parameter is applicable to Optional parameters: charset: The charset parameter is applicable to
the encoding of the parameter values. The default charset is the encoding of the parameter values. The default charset is
UTF-8, if the 'charset' parameter is not present. UTF-8, if the 'charset' parameter is not present.
Encoding considerations: 8bit Encoding considerations: 8bit
Security considerations: This format may carry any type of Security considerations: This format may carry any type of
parameters. Some can have security requirements, like privacy, parameters. Some can have security requirements, like privacy,
confidentiality or integrity requirements. The format has no confidentiality or integrity requirements. The format has no
built in security protection. For the usage it was defined the built in security protection. For the usage it was defined the
skipping to change at page 227, line 22 skipping to change at page 217, line 5
fictional example in [RFC2326], but was not formally specified. fictional example in [RFC2326], but was not formally specified.
This has resulted in usage of this media type which may not match This has resulted in usage of this media type which may not match
its formal definition. its formal definition.
Published specification: RFC XXXX, Appendix F. Published specification: RFC XXXX, Appendix F.
Applications that use this media type: Applications that use RTSP Applications that use this media type: Applications that use RTSP
and have additional parameters they like to read and set using the and have additional parameters they like to read and set using the
RTSP GET_PARAMETER and SET_PARAMETER methods. RTSP GET_PARAMETER and SET_PARAMETER methods.
Additional information: Person & email address to contact for further information: Magnus We
sterlund (magnus.westerlund@ericsson.com)
Magic number(s):
File extension(s):
Macintosh file type code(s):
Person & email address to contact for further information: Magnus
Westerlund (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:
23. References 23. References
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.
[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.E. and R.M. Hinden, "Internet Protocol, Version
(IPv6) Specification", RFC 2460, December 1998. 6 (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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P.M., Hostetler, J.L., Lawrence,
Leach, P., Luotonen, A., and L. Stewart, "HTTP S.D., Leach, P.J., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
skipping to change at page 229, line 4 skipping to change at page 218, line 17
July 2003. July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[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.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, December 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.
[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
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006. Protocol (RTSP)", RFC 4567, 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 230, line 37 skipping to change at page 219, line 45
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[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
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
[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] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)", controlled by Real-Time Streaming Protocol (RTSP)", draft-
draft-ietf-mmusic-rtsp-nat-14 (work in progress), ietf-mmusic-rtsp-nat-14 (work in progress), November 2012.
November 2012.
[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.
[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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
April 2001. 2001.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June
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.
[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
Formats", RFC 4855, February 2007.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in
the RTP Profile for Audio and Video Conferences", RFC
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.
[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. R., "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
these are examples and the normative and syntax description in the these are examples and the normative and syntax description in the
other sections take precedence. Please also note that many of the other sections take precedence. Please also note that many of the
examples contain syntax illegal line breaks to accommodate the examples contain syntax illegal line breaks to accommodate the
skipping to change at page 233, line 49 skipping to change at page 222, line 42
multiple streams. It also illustrates the use of aggregate URIs. In multiple streams. It also illustrates the use of aggregate URIs. In
a container file it is also desirable to not write any URI parts a container file it is also desirable to not write any URI parts
which are not kept, when the container is distributed, like the host which are not kept, when the container is distributed, like the host
and most of the path element. Therefore this example also uses the and most of the path element. Therefore this example also uses the
"*" and relative URI in the delivered SDP. "*" and relative URI in the delivered SDP.
Also this presentation description (SDP) is not cachable, as the Also this presentation description (SDP) is not cachable, as the
Expires header is set to an equal value with date indicating Expires header is set to an equal value with date indicating
immediate expiration of its valididty. immediate expiration of its valididty.
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.
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
skipping to change at page 234, line 25 skipping to change at page 223, line 18
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
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=0-0: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 237, line 21 skipping to change at page 225, line 41
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.
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.
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
skipping to change at page 237, line 45 skipping to change at page 226, line 19
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
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=0-0: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 239, line 26 skipping to change at page 227, line 48
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. Media on Demand (Unicast) A.3. 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
skipping to change at page 247, line 5 skipping to change at page 234, line 34
The server, through the clients request and the included Supported The server, through the clients request and the included Supported
header, learns the client supports RTSP 2.0, and also supports the header, learns the client supports RTSP 2.0, and also supports the
playback time scaling feature of RTSP. The server's response playback time scaling feature of RTSP. The server's response
contains the following feature related information to the client; it contains the following feature related information to the client; it
supports the basic media delivery functions (play.basic), the supports the basic media delivery functions (play.basic), the
extended functionality of time scaling of content (play.scale), and extended functionality of time scaling of content (play.scale), and
one "example.com" proprietary feature (com.example.flight). The one "example.com" proprietary feature (com.example.flight). The
client also learns the methods supported (Public header) by the client also learns the methods supported (Public header) by the
server for the indicated resource. server for the indicated resource.
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0 C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER
Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request it tells the server that it When the client sends its SETUP request it tells the server that it
requires support of the play.scale feature for this session by requires support of the play.scale feature for this session by
including the Require header. including the Require header.
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057", dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
skipping to change at page 248, line 31 skipping to change at page 236, line 5
B.1. States B.1. States
The state machine contains three states, described below. For each The state machine contains three states, described below. For each
state there exists a table which shows which requests and events are state there exists a table which shows which requests and events are
allowed and whether they will result in a state change. allowed and whether they will result in a state change.
Init: Initial state no session exists. Init: Initial state no session exists.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e. sending media stream data in the Play: Session is playing, i.e. sending media stream data in the
direction S->C. direction S->C.
B.2. State variables B.2. State variables
This representation of the state machine needs more than its state to This representation of the state machine needs more than its state to
work. A small number of variables are also needed and they are work. A small number of variables are also needed and they are
explained below. explained below.
NRM: The number of media streams part of this session. NRM: The number of media streams part of this session.
skipping to change at page 250, line 12 skipping to change at page 237, line 34
The server will timeout the session after the period of time The server will timeout the session after the period of time
specified in the SETUP response, if no activity from the client is specified in the SETUP response, if no activity from the client is
detected. Therefore there exists a timeout event for all states detected. Therefore there exists a timeout event for all states
except Init. except Init.
In the case that NRM = 1 the presentation URI is equal to the media In the case that NRM = 1 the presentation URI is equal to the media
URI or a specified presentation URI. For NRM > 1 the presentation URI or a specified presentation URI. For NRM > 1 the presentation
URI needs to be other than any of the medias that are part of the URI needs to be other than any of the medias that are part of the
session. This applies to all states. session. This applies to all states.
+---------------+-----------------+---------------------------------+ +--------------------+--------------------+-------------------------+
| Event | Prerequisite | Response | | Event | Prerequisite | Response |
+---------------+-----------------+---------------------------------+ +--------------------+--------------------+-------------------------+
| DESCRIBE | Needs REDIRECT | 3rr, Redirect | | DESCRIBE | Needs REDIRECT | 3rr, Redirect |
| | | | | | | |
| DESCRIBE | | 200, Session description | | DESCRIBE | | 200, Session |
| | | | | | | description |
| OPTIONS | Session ID | 200, Reset session timeout | | | | |
| | | timer | | OPTIONS | Session ID | 200, Reset session |
| | | | | | | timeout timer |
| OPTIONS | | 200 | | | | |
| | | | | OPTIONS | | 200 |
| SET_PARAMETER | Valid parameter | 200, change value of parameter | | | | |
| | | | | SET_PARAMETER | Valid parameter | 200, change value of |
| GET_PARAMETER | Valid parameter | 200, return value of parameter | | | | parameter |
+---------------+-----------------+---------------------------------+ | | | |
| GET_PARAMETER | Valid parameter | 200, return value of |
| | | parameter |
+--------------------+--------------------+-------------------------+
Table 13: None state-machine changing events Table 13: None state-machine changing events
The methods in Table 13 do not have any effect on the state machine The methods in Table 13 do not have any effect on the state machine
or the state variables. However, some methods do change other or the state variables. However, some methods do change other
session related parameters, for example SET_PARAMETER which will set session related parameters, for example SET_PARAMETER which will set
the parameter(s) specified in its body. Also all of these methods the parameter(s) specified in its body. Also all of these methods
that allow Session header will also update the keep-alive timer for that allow Session header will also update the keep-alive timer for
the session. the session.
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
skipping to change at page 251, line 8 skipping to change at page 238, line 31
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
Table 14: State: Init Table 14: State: Init
The initial state of the state machine, see Table 14 can only be left The initial state of the state machine, see Table 14 can only be left
by processing a correct SETUP request. As seen in the table the two by processing a correct SETUP request. As seen in the table the two
state variables are also set by a correct request. This table also state variables are also set by a correct request. This table also
shows that a correct SETUP can in some cases be redirected to another shows that a correct SETUP can in some cases be redirected to another
URI and/or server by a 3rr response. URI and/or server by a 3rr response.
+-------------+------------------------+---------+------------------+ +---------------+------------------------+----------+---------------+
| Action | Requisite | New | Response | | Action | Requisite | New | Response |
| | | State | | | | | State | |
+-------------+------------------------+---------+------------------+ +---------------+------------------------+----------+---------------+
| SETUP | New URI | Ready | NRM +=1 | | SETUP | New URI | Ready | NRM +=1 |
| | | | | | | | | |
| SETUP | URI Setup prior | Ready | Change transport | | SETUP | URI Setup prior | Ready | Change |
| | | | param | | | | | transport |
| | | | | | | | | param |
| TEARDOWN | Prs URI, | Init | No session hdr, | | | | | |
| | | | NRM = 0 | | TEARDOWN | Prs URI, | Init | No session |
| | | | | | | | | hdr, NRM = 0 |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | | | | | |
| | | | NRM = 0 | | TEARDOWN | md URI,NRM=1 | Init | No Session |
| | | | | | | | | hdr, NRM = 0 |
| TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM | | | | | |
| | | | -= 1 | | TEARDOWN | md URI,NRM>1 | Ready | Session hdr, |
| | | | | | | | | NRM -= 1 |
| PLAY | Prs URI, No range | Play | Play from RP | | | | | |
| | | | | | PLAY | Prs URI, No range | Play | Play from RP |
| PLAY | Prs URI, Range | Play | According to | | | | | |
| | | | range | | PLAY | Prs URI, Range | Play | According to |
| | | | | | | | | range |
| PLAY | md URI, NRM=1, Range | Play | According to | | | | | |
| | | | range | | PLAY | md URI, NRM=1, Range | Play | According to |
| | | | | | | | | range |
| PLAY | md URI, NRM=1 | Play | Play from RP | | | | | |
| | | | | | PLAY | md URI, NRM=1 | Play | Play from RP |
| PAUSE | Prs URI | Ready | Return PP | | | | | |
| | | | | | PAUSE | Prs URI | Ready | Return PP |
| SC:REDIRECT | Terminate-Reason | Ready | Set RedP | | | | | |
| | | | | | SC:REDIRECT | Terminate-Reason | Ready | Set RedP |
| SC:REDIRECT | No Terminate-Reason | Init | Session is | | | | | |
| | time parameter | | removed | | SC:REDIRECT | No Terminate-Reason | Init | Session is |
| | | | | | | time parameter | | removed |
| Timeout | | Init | | | | | | |
| | | | | | Timeout | | Init | |
| RedP | | Init | TEARDOWN of | | | | | |
| reached | | | session | | RedP reached | | Init | TEARDOWN of |
+-------------+------------------------+---------+------------------+ | | | | session |
+---------------+------------------------+----------+---------------+
Table 15: State: Ready Table 15: State: Ready
In the Ready state, see Table 15, some of the actions are depending In the Ready state, see Table 15, some of the actions are depending
on the number of media streams (NRM) in the session, i.e., aggregated on the number of media streams (NRM) in the session, i.e., aggregated
or non-aggregated control. A SETUP request in the Ready state can or non-aggregated control. A SETUP request in the Ready state can
either add one more media stream to the session or, if the media either add one more media stream to the session or, if the media
stream (same URI) already is part of the session, change the stream (same URI) already is part of the session, change the
transport parameters. TEARDOWN is depending on both the Request-URI transport parameters. TEARDOWN is depending on both the Request-URI
and the number of media streams within the session. If the Request- and the number of media streams within the session. If the Request-
URI is the presentations URI the whole session is torn down. If a URI is the presentations URI the whole session is torn down. If a
media URI is used in the TEARDOWN request and more than one media media URI is used in the TEARDOWN request and more than one media
exists in the session, the session will remain and a session header exists in the session, the session will remain and a session header
is returned in the response. If only a single media stream remains is returned in the response. If only a single media stream remains
in the session when performing a TEARDOWN with a media URI the in the session when performing a TEARDOWN with a media URI the
session is removed. The number of media streams remaining after session is removed. The number of media streams remaining after
tearing down a media stream determines the new state. tearing down a media stream determines the new state.
+----------------+-----------------------+--------+-----------------+ +--------------------+-------------------+---------+----------------+
| Action | Requisite | New | Response | | Action | Requisite | New | Response |
| | | State | | | | | State | |
+----------------+-----------------------+--------+-----------------+ +--------------------+-------------------+---------+----------------+
| PAUSE | Prs URI | Ready | Set RP to | | PAUSE | Prs URI | Ready | Set RP to |
| | | | present point | | | | | present point |
| | | | | | | | | |
| End of media | All media | Play | Set RP = End of | | End of media | All media | Play | Set RP = End |
| | | | media | | | | | of media |
| | | | | | | | | |
| End of range | | Play | Set RP = End of | | End of range | | Play | Set RP = End |
| | | | range | | | | | of range |
| | | | | | | | | |
| PLAY | Prs URI, No range | Play | Play from | | PLAY | Prs URI, No range | Play | Play from |
| | | | present point | | | | | present point |
| | | | | | | | | |
| PLAY | Prs URI, Range | Play | According to | | PLAY | Prs URI, Range | Play | According to |
| | | | range | | | | | range |
| | | | | | | | | |
| SC:PLAY_NOTIFY | | Play | 200 | | SC:PLAY_NOTIFY | | Play | 200 |
| | | | | | | | | |
| SETUP | New URI | Play | 455 | | SETUP | New URI | Play | 455 |
| | | | | | | | | |
| SETUP | Setuped URI | Play | 455 | | SETUP | Setuped URI | Play | 455 |
| | | | | | | | | |
| SETUP | Setuped URI, IFI | Play | Change | | SETUP | Setuped URI, IFI | Play | Change |
| | | | transport | | | | | transport |
| | | | param. | | | | | param. |
| | | | | | | | | |
| TEARDOWN | Prs URI | Init | No session hdr | | TEARDOWN | Prs URI | Init | No session hdr |
| | | | | | | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, | | TEARDOWN | md URI,NRM=1 | Init | No Session |
| | | | NRM=0 | | | | | hdr, NRM=0 |
| | | | | | | | | |
| TEARDOWN | md URI | Play | 455 | | TEARDOWN | md URI | Play | 455 |
| | | | | | | | | |
| SC:REDIRECT | Terminate Reason with | Play | Set RedP | | SC:REDIRECT | Terminate Reason | Play | Set RedP |
| | Time parameter | | | | | with Time | | |
| | | | | | | parameter | | |
| SC:REDIRECT | | Init | Session is | | | | | |
| | | | removed | | SC:REDIRECT | | Init | Session is |
| | | | | | | | | removed |
| RedP reached | | Init | TEARDOWN of | | | | | |
| | | | session | | RedP reached | | Init | TEARDOWN of |
| | | | | | | | | session |
| Timeout | | Init | Stop Media | | | | | |
| | | | playout | | Timeout | | Init | Stop Media |
+----------------+-----------------------+--------+-----------------+ | | | | playout |
+--------------------+-------------------+---------+----------------+
Table 16: State: Play Table 16: State: Play
The Play state table, see Table 16, contains a number of requests The Play state table, see Table 16, contains a number of requests
that need a presentation URI (labeled as Prs URI) to work on (i.e., that need a presentation URI (labeled as Prs URI) to work on (i.e.,
the presentation URI has to be used as the Request-URI). This is due the presentation URI has to be used as the Request-URI). This is due
to the exclusion of non-aggregated stream control in sessions with to the exclusion of non-aggregated stream control in sessions with
more than one media stream. more than one media stream.
To avoid inconsistencies between the client and server, automatic To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End state transitions are avoided. This can be seen at for example "End
skipping to change at page 255, line 43 skipping to change at page 242, line 12
NOT be used. This addressing and multiplexing is used as defined NOT be used. This addressing and multiplexing is used as defined
with use of channel numbers and the interleaved parameter. with use of channel numbers and the interleaved parameter.
C.1.2. AVP/UDP C.1.2. AVP/UDP
This part describes sending of RTP [RFC3550] over lower transport This part describes sending of RTP [RFC3550] over lower transport
layer UDP [RFC0768] according to the profile "RTP Profile for Audio layer UDP [RFC0768] according to the profile "RTP Profile for Audio
and Video Conferences with Minimal Control" defined in RFC 3551 and Video Conferences with Minimal Control" defined in RFC 3551
[RFC3551]. This profile requires one or two uni- or bi-directional [RFC3551]. This profile requires one or two uni- or bi-directional
UDP flows per media stream. The first UDP flow is for RTP and the UDP flows per media stream. The first UDP flow is for RTP and the
second is for RTCP. Embedding of RTP data with the RTSP messages, in second is for RTCP. Multiplexing of RTP and RTCP (Appendix C.1.6.4)
accordance with Section 14, SHOULD NOT be performed when RTSP MAY be used, in which case a single UDP flow is used for both parts.
messages are transported over unreliable transport protocols, like Embedding of RTP data with the RTSP messages, in accordance with
UDP [RFC0768]. Section 14, SHOULD NOT be performed when RTSP messages are
transported over unreliable transport protocols, like UDP [RFC0768].
The RTP/UDP and RTCP/UDP flows can be established using the Transport The RTP/UDP and RTCP/UDP flows can be established using the Transport
header's "src_addr", and "dest_addr" parameters. header's "src_addr", and "dest_addr" parameters.
In RTSP PLAY mode, the transmission of RTP packets from client to In RTSP PLAY mode, the transmission of RTP packets from client to
server is unspecified. The behavior in regards to such RTP packets server is unspecified. The behavior in regards to such RTP packets
MAY be defined in future. MAY be defined in future.
The "src_addr" and "dest_addr" parameters are used in the following The "src_addr" and "dest_addr" parameters are used in the following
way for media delivery and playback mode, i.e. Mode=PLAY: way for media delivery and playback mode, i.e. Mode=PLAY:
o The "src_addr" and "dest_addr" parameters MUST contain either 1 or o The "src_addr" and "dest_addr" parameters MUST contain either 1 or
2 address specifications. 2 address specifications. Note that two address specifications
MAY be provided even if RTP and RTCP multiplexing is negotiated.
o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST
contain either: contain either:
* both an address and a port number, or * both an address and a port number, or
* a port number without an address. * a port number without an address.
o The first address and port pair given in either of the parameters o The first address specification given in either of the parameters
applies to the RTP stream. The second address and port pair if applies to the RTP stream. The second specification if present
present applies to the RTCP stream. applies to the RTCP stream, unless in case RTP and RTCP
multiplexing is negotiated where both RTP and RTCP will use the
first specification.
o The RTP/UDP packets from the server to the client MUST be sent to o The RTP/UDP packets from the server to the client MUST be sent to
the address and port given by the first address and port pair of the address and port given by the first address specification of
the "dest_addr" parameter. the "dest_addr" parameter.
o The RTCP/UDP packets from the server to the client MUST be sent to o The RTCP/UDP packets from the server to the client MUST be sent to
the address and port given by the second address and port pair of the address and port given by the second address specification of
the "dest_addr" parameter. If no second pair is specified RTCP the "dest_addr" parameter, unless RTP and RTCP multiplexing has
MUST NOT be sent. been negotiated, in which case RTCP MUST be sent to the first
address specification. If no second pair is specified and RTP and
RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
o The RTCP/UDP packets from the client to the server MUST be sent to o The RTCP/UDP packets from the client to the server MUST be sent to
the address and port given by the second address and port pair of the address and port given by the second address specification of
the "src_addr" parameter. If no second pair is given RTCP MUST the "src_addr" parameter, unless RTP and RTCP multiplexing has
NOT be sent. been negotiated, in which case RTCP MUST be sent to the first
address specification. If no second pair is specified and RTP and
RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
o The RTP/UDP packets from the client to the server MUST be sent to o The RTP/UDP packets from the client to the server MUST be sent to
the address and port given by the first address and port pair of the address and port given by the first address specification of
the "src_addr" parameter. the "src_addr" parameter.
o RTP and RTCP Packets SHOULD be sent from the corresponding o RTP and RTCP Packets SHOULD be sent from the corresponding
receiver port, i.e. RTCP packets from the server should be sent receiver port, i.e. RTCP packets from the server should be sent
from the "src_addr" parameters second address port pair. from the "src_addr" parameters second address port pair, unless
RTP and RTCP multiplexing has been negotiated in which case the
first address port pair is used.
C.1.3. AVPF/UDP C.1.3. AVPF/UDP
The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/
AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP.
All that is defined for AVP MUST also apply for AVPF. All that is defined for AVP MUST also apply for AVPF.
The usage of AVPF is indicated by the media initialization protocol The usage of AVPF is indicated by the media initialization protocol
used. In the case of SDP it is indicated by media lines (m=) used. In the case of SDP it is indicated by media lines (m=)
containing the profile RTP/AVPF. That SDP MAY also contain further containing the profile RTP/AVPF. That SDP MAY also contain further
skipping to change at page 261, line 12 skipping to change at page 247, line 40
contains the a=rtcp-mux attribute for a media stream, the server MUST contains the a=rtcp-mux attribute for a media stream, the server MUST
support RTP and RTCP multiplexing. If indicated or otherwise desired support RTP and RTCP multiplexing. If indicated or otherwise desired
by the client it can include the Transport parameter "RTCP-mux" in by the client it can include the Transport parameter "RTCP-mux" in
any transport specification where it desires to use RTCP-mux. The any transport specification where it desires to use RTCP-mux. The
server will indicate if it supports RTCP-mux. Servers and Clients server will indicate if it supports RTCP-mux. Servers and Clients
SHOULD support RTP and RTCP multiplexing. SHOULD support RTP and RTCP multiplexing.
For capability exchange, an RTSP feature tag for RTP and RTCP For capability exchange, an RTSP feature tag for RTP and RTCP
multiplexing is defined: "setup.rtp.rtcp.mux". multiplexing is defined: "setup.rtp.rtcp.mux".
To minimize the risk of negotiation failure while using RTP and RTCP
multiplexing some recommendations are here provided. If the session
description includes explicit indication of support (a=rtcp-mux in
SDP), then a RTSP agent can safely create a SETUP request with a
transport specification with only a single dest_addr parameter
address specification. If no such explicit indication is provided,
then even if the feature tag "setup.rtp.rtcp.mux" is provided in a
Supported header by the RTSP server or the feature tag included in
the Required header in the SETUP request, the media resource may not
support RTP and RTCP multiplexing. Thus, to maximize the probability
of successful negotiation the RTSP agent is recommended to include
two dest_addr parameter address specifications in the first or first
set (if pipelining is used) of SETUP request(s) for any media
resource aggregate. That way the RTSP server can either accept RTP
and RTCP multiplexing and only use the first address specification,
and if not use both specifications. The RTSP agent after having
received the response for a successful negotiation of the usage of
RTP and RTCP multiplexing, can then release the resources associated
with the second address specification.
C.2. RTP over TCP C.2. RTP over TCP
Transport of RTP over TCP can be done in two ways: over independent Transport of RTP over TCP can be done in two ways: over independent
TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP
control connection. In both cases the protocol MUST be "rtp" and the control connection. In both cases the protocol MUST be "rtp" and the
lower layer MUST be TCP. The profile may be any of the above lower layer MUST be TCP. The profile may be any of the above
specified ones; AVP, AVPF, SAVP or SAVPF. specified ones; AVP, AVPF, SAVP or SAVPF.
C.2.1. Interleaved RTP over TCP C.2.1. Interleaved RTP over TCP
The use of embedded (interleaved) binary data transported on the RTSP The use of embedded (interleaved) binary data transported on the RTSP
connection is possible as specified in Section 14. When using this connection is possible as specified in Section 14. When using this
declared combination of interleaved binary data the RTSP messages declared combination of interleaved binary data the RTSP messages
MUST be transported over TCP. TLS may or may not be used. MUST be transported over TCP. TLS may or may not be used. If TLS is
used both RTSP messages and the binary data will be protected by TLS.
One should, however, consider that this will result in all media One should, however, consider that this will result in all media
streams go through any proxy. Using independent TCP connections can streams go through any proxy. Using independent TCP connections can
avoid that issue. avoid that issue.
C.2.2. RTP over independent TCP C.2.2. RTP over independent TCP
In this Appendix, we describe the sending of RTP [RFC3550] over lower In this Appendix, we describe the sending of RTP [RFC3550] over lower
transport layer TCP [RFC0793] according to "Framing Real-time transport layer TCP [RFC0793] according to "Framing Real-time
Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over
Connection-Oriented Transport" [RFC4571]. This Appendix adapts the Connection-Oriented Transport" [RFC4571]. This Appendix adapts the
guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work
with RTSP. with RTSP.
A client codes the support of RTP over independent TCP by specifying A client codes the support of RTP over independent TCP by specifying
an RTP/AVP/TCP transport option without an interleaved parameter in an RTP/AVP/TCP transport option without an interleaved parameter in
the Transport line of a SETUP request. This transport option MUST the Transport line of a SETUP request. This transport option MUST
include the "unicast" parameter. include the "unicast" parameter.
If the client wishes to use RTP with RTCP, two ports (or two address/ If the client wishes to use RTP with RTCP, two address specifications
port pairs) are specified by the dest_addr parameter. If the client needs to be included in the dest_addr parameter. If the client
wishes to use RTP without RTCP, one port (or one address/port pair) wishes to use RTP without RTCP, one address specification is included
is specified by the dest_addr parameter. If the client wishes to in the dest_addr parameter. If the client wishes to multiplex RTP
multiplex RTP and RTCP on a single port (see Appendix C.1.6.4), one and RTCP on a single transport flow (see Appendix C.1.6.4), one or
port (or one address/port pair) is specified by the dest_addr two address specifications are included in the dest_addr parameter in
parameter. Ordering rules of dest_addr ports follow the rules for addition to the RTCP-mux transport parameter. Two address
RTP/AVP/UDP. specifications are allowed to allow successful negotiation when
server or content can't support RTP and RTCP multiplexing. Ordering
rules of dest_addr ports follow the rules for RTP/AVP/UDP.
If the client wishes to play the active role in initiating the TCP If the client wishes to play the active role in initiating the TCP
connection, it MAY set the "setup" parameter (See Section 18.52) on connection, it MAY set the "setup" parameter (See Section 18.52) on
the Transport line to be "active", or it MAY omit the setup the Transport line to be "active", or it MAY omit the setup
parameter, as active is the default. If the client signals the parameter, as active is the default. If the client signals the
active role, the ports for all dest_addr values MUST be set to 9 (the active role, the ports in the address specifications in the dest_addr
discard port). parameter MUST be set to 9 (the discard port).
If the client wishes to play the passive role in TCP connection If the client wishes to play the passive role in TCP connection
initiation, it MUST set the "setup" parameter on the Transport line initiation, it MUST set the "setup" parameter on the Transport line
to be "passive". If the client is able to assume the active or the to be "passive". If the client is able to assume the active or the
passive role, it MUST set the "setup" parameter on the Transport line passive role, it MUST set the "setup" parameter on the Transport line
to be "actpass". In either case, the dest_addr port value for RTP to be "actpass". In either case, the dest_addr parameter's address
specification port value for RTP MUST be set to the TCP port number
on which the client is expecting to receive the TCP connection for
RTP, and the dest_addr's address specification port value for RTCP
MUST be set to the TCP port number on which the client is expecting MUST be set to the TCP port number on which the client is expecting
to receive the RTP stream connection, and the dest_addr port value to receive the TCP connection for RTCP. In the case that the client
for RTCP MUST be set to the TCP port number on which the client is wishes to multiplex RTP and RTCP on a single transport flow, the
expecting to receive the RTCP stream connection. In the case that RTCP-mux parameter is included and one or two dest_addr parameter
the client wishes to multiplex RTP and RTCP on a single port, one address specifications are included, as mentioned earlier in this
port is specified by the dest_addr parameter, as mentioned earlier in section.
this section.
If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a If upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, a
server decides to accept this requested option, the 2xx reply MUST server decides to accept this requested option, the 2xx reply MUST
contain a Transport option that specifies RTP/AVP/TCP (without using contain a Transport option that specifies RTP/AVP/TCP (without using
the interleaved parameter, and with using the unicast parameter). the interleaved parameter, and with using the unicast parameter).
The dest_addr parameter value MUST be echoed from the parameter value The dest_addr parameter value MUST be echoed from the parameter value
in the client request unless the destination address (only port) was in the client request unless the destination address (only port) was
not provided in which case the server MAY include the source address not provided in which case the server MAY include the source address
of the RTSP TCP connection with the port number unchanged. of the RTSP TCP connection with the port number unchanged.
In addition, the server reply MUST set the setup parameter on the In addition, the server reply MUST set the setup parameter on the
Transport line, to indicate the role the server will play in the Transport line, to indicate the role the server will play in the
connection setup. Permissible values are "active" (if a client set connection setup. Permissible values are "active" (if a client set
"setup" to "passive" or "actpass") and "passive" (if a client set "setup" to "passive" or "actpass") and "passive" (if a client set
"setup" to "active" or "actpass"). "setup" to "active" or "actpass").
If a server sets "setup" to "passive", the "src_addr" in the reply If a server sets "setup" to "passive", the "src_addr" in the reply
MUST indicate the ports the server is willing to receive an RTP MUST indicate the ports the server is willing to receive an TCP
connection and (if the client requested an RTCP connection by connection for RTP and (if the client requested an TCP connection for
specifying two dest_addr ports or address/port pairs) an RTCP RTCP by specifying two dest_addr address specifications) an TCP/RTCP
connection. If a server sets "setup" to "active", the ports connection. If a server sets "setup" to "active", the ports
specified in "src_addr" MUST be set to 9. The server MAY use the specified in "src_addr" address specifications MUST be set to 9. The
"ssrc" parameter, following the guidance in Section 18.52. The server MAY use the "ssrc" parameter, following the guidance in
server sets only one port in the case that the client has indicated Section 18.52. The server sets only one address specification in the
only a single port. Port ordering for src_addr follows the rules for case that the client has indicated only a single address
specification or in case RTP and RTCP multiplexing was requested and
accepted by server. Port ordering for src_addr follows the rules for
RTP/AVP/UDP. RTP/AVP/UDP.
Servers MUST support taking the passive role and MAY support taking Servers MUST support taking the passive role and MAY support taking
the active role. Servers with a public IP address take the passive the active role. Servers with a public IP address take the passive
role, thus enabling clients behind NATs and Firewalls a better chance role, thus enabling clients behind NATs and Firewalls a better chance
of successful connect to the server by actively connecting outwards. of successful connect to the server by actively connecting outwards.
Therefore the clients are RECOMMENDED to take the active role. Therefore the clients are RECOMMENDED to take the active role.
After sending (receiving) a 2xx reply for a SETUP method for a non- After sending (receiving) a 2xx reply for a SETUP method for a non-
interleaved RTP/AVP/TCP media stream, the active party SHOULD interleaved RTP/AVP/TCP media stream, the active party SHOULD
initiate the TCP connection as soon as possible. The client MUST NOT initiate the TCP connection as soon as possible. The client MUST NOT
send a PLAY request prior to the establishment of all the TCP send a PLAY request prior to the establishment of all the TCP
connections negotiated using SETUP for the session. In case the connections negotiated using SETUP for the session. In case the
server receives a PLAY request in a session that has not yet server receives a PLAY request in a session that has not yet
established all the TCP connections, it MUST respond using the 464 established all the TCP connections, it MUST respond using the 464
"Data Transport Not Ready Yet" (Section 17.4.29) error code. "Data Transport Not Ready Yet" (Section 17.4.29) error code.
Once the PLAY request for a media resource transported over non- Once the PLAY request for a media resource transported over non-
interleaved RTP/AVP/TCP occurs, media begins to flow from server to interleaved RTP/AVP/TCP occurs, media begins to flow from server to
client over the RTP TCP connection, and RTCP packets flow client over the RTP TCP connection, and RTCP packets flow
bidirectionally over the RTCP TCP connection. As in the RTP/UDP bidirectionally over the RTCP TCP connection. Unless RTP and RTCP
case, client to server traffic on the TCP port is unspecified by this multiplexing has been negotiated in which case RTP and RTCP will flow
memo. The packets that travel on these connections MUST be framed over a common TCP connection. As in the RTP/UDP case, client to
using the protocol defined in [RFC4571], not by the framing defined server traffic on a RTP only TCP session is unspecified by this memo.
for interleaving RTP over the RTSP control connection defined in The packets that travel on these connections MUST be framed using the
protocol defined in [RFC4571], not by the framing defined for
interleaving RTP over the RTSP control connection defined in
Section 14. Section 14.
A successful PAUSE request for a media being transported over RTP/ A successful PAUSE request for a media being transported over RTP/AVP
AVP/TCP pauses the flow of packets over the connections, without /TCP pauses the flow of packets over the connections, without closing
closing the connections. A successful TEARDOWN request signals that the connections. A successful TEARDOWN request signals that the TCP
the TCP connections for RTP and RTCP are to be closed as soon as connections for RTP and RTCP are to be closed by the RTSP client as
possible. soon as possible.
Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be Subsequent SETUP requests on an already-SETUP RTP/AVP/TCP URI may be
ambiguous in the following way: does the client wish to open up new ambiguous in the following way: does the client wish to open up new
TCP RTP and RTCP connections for the URI, or does the client wish to TCP connection for RTP or RTCP for the URI, or does the client wish
continue using the existing TCP RTP and RTCP connections? The client to continue using the existing TCP connections? The client SHOULD
SHOULD use the "connection" parameter (defined in Section 18.52) on use the "connection" parameter (defined in Section 18.52) on the
the Transport line to make its intention clear (by setting Transport line to make its intention clear (by setting "connection"
"connection" to "new" if new connections are needed, and by setting to "new" if new connections are needed, and by setting "connection"
"connection" to "existing" if the existing connections are to be to "existing" if the existing connections are to be used). After a
used). After a 2xx reply for a SETUP request for a new connection, 2xx reply for a SETUP request for a new connection, parties should
parties should close the pre-existing connections, after waiting a close the pre-existing connections, after waiting a suitable period
suitable period for any stray RTP or RTCP packets to arrive. for any stray RTP or RTCP packets to arrive.
The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that
a security association is established. The default mechanism for a security association is established. The default mechanism for
establishing that security association is to use MIKEY[RFC3830] with establishing that security association is to use MIKEY[RFC3830] with
RTSP as defined Appendix C.1.4.1. RTSP as defined Appendix C.1.4.1.
Below, we rewrite part of the example media on demand example shown Below, we rewrite part of the example media on demand example shown
in Appendix A.1 to use RTP/AVP/TCP non-interleaved: in Appendix A.1 to use RTP/AVP/TCP non-interleaved:
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
skipping to change at page 264, line 28 skipping to change at page 251, line 36
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.34 o=- 2890844256 2890842807 IN IP4 198.51.100.34
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=0-0: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
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
setup=active;connection=new setup=active;connection=new
skipping to change at page 266, line 5 skipping to change at page 253, line 4
completed PLAY request perform a new PLAY request. This will result completed PLAY request perform a new PLAY request. This will result
in some gap in the media layer. The below text will look into both in some gap in the media layer. The below text will look into both
cases. cases.
A PLAY request that replaces an ongoing request allows the media A PLAY request that replaces an ongoing request allows the media
layer rendering the RTP stream without being affected by jumps in layer rendering the RTP stream without being affected by jumps in
media clock time. The RTP timestamps for the new media range is set media clock time. The RTP timestamps for the new media range is set
so that they become continuous with the previous media range in the so that they become continuous with the previous media range in the
previous request. The RTP sequence number for the first packet in previous request. The RTP sequence number for the first packet in
the new range will be the next following the last packet in the the new range will be the next following the last packet in the
previous range, i.e. monotonically increasing. The goal is to allow previous range, i.e. monotonically increasing. The goal is to allow
the media rendering layer to work without interruption or the media rendering layer to work without interruption or
reconfiguration across the jumps in media clock. This should be reconfiguration across the jumps in media clock. This should be
possible in all cases of replaced PLAY requests for media that has possible in all cases of replaced PLAY requests for media that has
random-access properties. In this case care is needed to align random-access properties. In this case care is needed to align
frames or similar media dependent structures. frames or similar media dependent structures.
In cases where jumps in media clock time are a result of RTSP In cases where jumps in media clock time are a result of RTSP
signaling operations arriving after a completed PLAY operation, the signaling operations arriving after a completed PLAY operation, the
request timing will result in that media becomes non-continuous. The request timing will result in that media becomes non-continuous. The
server becomes unable to send the media so that it arrives timely and server becomes unable to send the media so that it arrives timely and
skipping to change at page 266, line 48 skipping to change at page 253, line 47
the server itself. For this type of basic delivery of live streams the server itself. For this type of basic delivery of live streams
to multiple users over unicast, individual rewriting of RTP sequence to multiple users over unicast, individual rewriting of RTP sequence
numbers becomes quite a burden. For solutions that anyway caches numbers becomes quite a burden. For solutions that anyway caches
media, timeshifts, etc, the rewriting should be a minor issue. media, timeshifts, etc, the rewriting should be a minor issue.
The goal when handling jumps in media clock time is that the provided The goal when handling jumps in media clock time is that the provided
stream is continuous without gaps in RTP timestamp or sequence stream is continuous without gaps in RTP timestamp or sequence
number. However, when delivery has been halted for some reason the number. However, when delivery has been halted for some reason the
RTP timestamp when resuming MUST represent the duration the delivery RTP timestamp when resuming MUST represent the duration the delivery
was halted. RTP sequence number MUST generally be the next number, was halted. RTP sequence number MUST generally be the next number,
i.e. monotonically increasing modulo 65536. For media resources with i.e. monotonically increasing modulo 65536. For media resources
the properties Time-Progressing and Time-Duration=0.0 the server MAY with the properties Time-Progressing and Time-Duration=0.0 the server
create RTP media streams with RTP sequence number jumps in them due MAY create RTP media streams with RTP sequence number jumps in them
to the client first halting delivery and later resuming it (PAUSE and due to the client first halting delivery and later resuming it (PAUSE
then later PLAY). However, servers utilizing this exception must and then later PLAY). However, servers utilizing this exception must
take into consideration the resulting RTCP receiver reports that take into consideration the resulting RTCP receiver reports that
likely contain loss reports for all the packets part of the likely contain loss reports for all the packets part of the
discontinuity. A client cannot rely on that a server will align when discontinuity. A client cannot rely on that a server will align when
resuming playing even if it is RECOMMENDED. The RTP-Info header will resuming playing even if it is RECOMMENDED. The RTP-Info header will
provide information on how the server acts in each case. provide information on how the server acts in each case.
We cannot assume that the RTSP client can communicate with the RTP We cannot assume that the RTSP client can communicate with the RTP
media agent, as the two may be independent processes. If the RTP media agent, as the two may be independent processes. If the RTP
timestamp shows the same gap as the NPT, the media agent will timestamp shows the same gap as the NPT, the media agent will
assume that there is a pause in the presentation. If the jump in assume that there is a pause in the presentation. If the jump in
skipping to change at page 268, line 35 skipping to change at page 255, line 33
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Session: abcdefg Session: abcdefg
Range: npt=18-20 Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100 ssrc=0D12F123:seq=50;rtptime=40100
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . . . . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
In this example, first, NPT 10 through 15 is played, then the client In this example, first, NPT 10 through 15 is played, then the client
requests the server to skip ahead and play NPT 18 through 20. The requests the server to skip ahead and play NPT 18 through 20. The
first segment is presented as RTP packets with sequence numbers 0 first segment is presented as RTP packets with sequence numbers 0
through 49 and timestamp 0 through 39,200. The second segment through 49 and timestamp 0 through 39,200. The second segment
consists of RTP packets with sequence number 50 through 69, with consists of RTP packets with sequence number 50 through 69, with
timestamps 40,100 through 55,200. While there is a gap in the NPT, timestamps 40,100 through 55,200. While there is a gap in the NPT,
there is no gap in the sequence number space of the RTP data stream. there is no gap in the sequence number space of the RTP data stream.
The RTP timestamp gap is present in the above example due to the time The RTP timestamp gap is present in the above example due to the time
skipping to change at page 269, line 47 skipping to change at page 256, line 48
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0 ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
The client then sends a PAUSE request: The client then sends a PAUSE request:
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5 CSeq: 5
Session: abcdefg Session: abcdefg
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: 5 CSeq: 5
skipping to change at page 270, line 32 skipping to change at page 257, line 35
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 6 CSeq: 6
Session: abcdefg Session: abcdefg
Range: npt=10.4-15 Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack" RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400 ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below: The ensuing RTP data stream is depicted below:
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
First, NPT 10 through 10.3 is played, then a PAUSE is received by the First, NPT 10 through 10.3 is played, then a PAUSE is received by the
server. After 20 seconds a PLAY is received by the server which server. After 20 seconds a PLAY is received by the server which
takes 15 ms to process. The duration of time for which the session takes 15 ms to process. The duration of time for which the session
was paused is reflected in the RTP timestamp of the RTP packets sent was paused is reflected in the RTP timestamp of the RTP packets sent
after this PLAY request. after this PLAY request.
A client can use the RTSP range header and RTP-Info header to map NPT A client can use the RTSP range header and RTP-Info header to map NPT
time of a presentation with the RTP timestamp. time of a presentation with the RTP timestamp.
skipping to change at page 273, line 13 skipping to change at page 260, line 19
attributes. attributes.
Appendix D. Use of SDP for RTSP Session Descriptions Appendix D. Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, [RFC4566]) may be used to The Session Description Protocol (SDP, [RFC4566]) may be used to
describe streams or presentations in RTSP. This description is describe streams or presentations in RTSP. This description is
typically returned in reply to a DESCRIBE request on an URI from a typically returned in reply to a DESCRIBE request on an URI from a
server to a client, or received via HTTP from a server to a client. server to a client, or received via HTTP from a server to a client.
This appendix describes how an SDP file determines the operation of This appendix describes how an SDP file determines the operation of
an RTSP session. SDP as is provides no mechanism by which a client an RTSP session. Thus, it is worth pointing out that the
can distinguish, without human guidance, between several media interpretation of the SDP is done in the context of the SDP receiver,
streams to be rendered simultaneously and a set of alternatives which is the one being configured. This is the same as in SAP
(e.g., two audio streams spoken in different languages). The SDP [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where the SDP
extension "Grouping of Media Lines in the Session Description describes what the agent providing the SDP is ready to receive and
Protocol (SDP)" [RFC5888] provides such functionality to some degree. willing to send.
Appendix D.4 describes the usage of SDP media line grouping for RTSP.
SDP as is provides no mechanism by which a client can distinguish,
without human guidance, between several media streams to be rendered
simultaneously and a set of alternatives (e.g., two audio streams
spoken in different languages). The SDP extension "Grouping of Media
Lines in the Session Description Protocol (SDP)" [RFC5888] provides
such functionality to some degree. Appendix D.4 describes the usage
of SDP media line grouping for RTSP.
D.1. Definitions D.1. Definitions
The terms "session-level", "media-level" and other key/attribute The terms "session-level", "media-level" and other key/attribute
names and values used in this appendix are to be used as defined in names and values used in this appendix are to be used as defined in
SDP[RFC4566]: SDP[RFC4566]:
D.1.1. Control URI D.1.1. Control URI
The "a=control:" attribute is used to convey the control URI. This The "a=control:" attribute is used to convey the control URI. This
attribute is used both for the session and media descriptions. If attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URI to be used for used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control level, the attribute indicates the URI for aggregate control
(presentation URI). The session level URI MUST be different from any (presentation URI). The session level URI MUST be different from any
media level URI. The presence of a session level control attribute media level URI. The presence of a session level control attribute
MUST be interpreted as support for aggregated control. The control MUST be interpreted as support for aggregated control. The control
attribute MUST be present on media level unless the presentation only attribute MUST be present on media level unless the presentation only
contains a single media stream, in which case the attribute MAY be contains a single media stream, in which case the attribute MAY be
skipping to change at page 273, line 45 skipping to change at page 261, line 20
media level URI. The presence of a session level control attribute media level URI. The presence of a session level control attribute
MUST be interpreted as support for aggregated control. The control MUST be interpreted as support for aggregated control. The control
attribute MUST be present on media level unless the presentation only attribute MUST be present on media level unless the presentation only
contains a single media stream, in which case the attribute MAY be contains a single media stream, in which case the attribute MAY be
present on the session level only and then also apply to that single present on the session level only and then also apply to that single
media stream. media stream.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=control:rtsp://example.com/foo
a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 [RFC3986]. following the rules and conventions set out in RFC 3986 [RFC3986].
Implementations MUST look for a base URI in the following order: Implementations MUST look for a base URI in the following order:
1. the RTSP Content-Base field; 1. the RTSP Content-Base field;
2. the RTSP Content-Location field; 2. the RTSP Content-Location field;
3. the RTSP Request-URI. 3. the RTSP Request-URI.
If this attribute contains only an asterisk (*), then the URI MUST be If this attribute contains only an asterisk (*), then the URI MUST be
treated as if it were an empty embedded URI, and thus inherit the treated as if it were an empty embedded URI, and thus inherit the
entire base URI. entire base URI.
Note, RFC 2326 was very unclear on the processing of relative URI Note, RFC 2326 was very unclear on the processing of relative URI
and several RTSP 1.0 implementations at the point of publishing and several RTSP 1.0 implementations at the point of publishing
skipping to change at page 274, line 29 skipping to change at page 262, line 7
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example let's assume that a container file has consideration. For example let's assume that a container file has
the URI: "rtsp://example.com/container.mp4". Let's further assume the URI: "rtsp://example.com/container.mp4". Let's further assume
this URI is the base URI, and that there is an absolute media level this URI is the base URI, and that there is an absolute media level
URI: "rtsp://example.com/container.mp4/trackID=2". A relative media URI: "rtsp://example.com/container.mp4/trackID=2". A relative media
level URI that resolves in accordance with RFC 3986 [RFC3986] to the level URI that resolves in accordance with RFC 3986 [RFC3986] to the
above given media URI is: "container.mp4/trackID=2". It is usually above given media URI is: "container.mp4/trackID=2". It is usually
not desirable to need to include in or modify the SDP stored within not desirable to need to include in or modify the SDP stored within
the container file with the server local name of the container file. the container file with the server local name of the container file.
To avoid this, one can modify the base URI used to include a trailing To avoid this, one can modify the base URI used to include a trailing
slash, e.g. "rtsp://example.com/container.mp4/". In this case the slash, e.g. "rtsp://example.com/container.mp4/". In this case the
relative URI for the media will only need to be: "trackID=2". relative URI for the media will only need to be: "trackID=2".
However, this will also mean that using "*" in the SDP will result in However, this will also mean that using "*" in the SDP will result in
control URI including the trailing slash, i.e. control URI including the trailing slash, i.e. "rtsp://example.com/
"rtsp://example.com/container.mp4/". container.mp4/".
Note: The usage of TrackID in the above is not a standardized Note: The usage of TrackID in the above is not a standardized
form, but one example out of several similar strings such as form, but one example out of several similar strings such as
TrackID, Track_ID, StreamID that is used by different server TrackID, Track_ID, StreamID that is used by different server
vendors to indicate a particular piece of media inside a container vendors to indicate a particular piece of media inside a container
file. file.
D.1.2. Media Streams D.1.2. Media Streams
The "m=" field is used to enumerate the streams. It is expected that The "m=" field is used to enumerate the streams. It is expected that
skipping to change at page 275, line 16 skipping to change at page 262, line 41
preference, it SHOULD set the port number value to zero. preference, it SHOULD set the port number value to zero.
The "m=" lines contain information about which transport protocol, The "m=" lines contain information about which transport protocol,
profile, and possibly lower-layer is to be used for the media stream. profile, and possibly lower-layer is to be used for the media stream.
The combination of transport, profile and lower layer, like RTP/AVP/ The combination of transport, profile and lower layer, like RTP/AVP/
UDP needs to be defined for how to be used with RTSP. The currently UDP needs to be defined for how to be used with RTSP. The currently
defined combinations are defined in Appendix C, further combinations defined combinations are defined in Appendix C, further combinations
MAY be specified. MAY be specified.
Example: Example:
m=audio 0 RTP/AVP 31
m=audio 0 RTP/AVP 31
D.1.3. Payload Type(s) D.1.3. Payload Type(s)
The payload type(s) are specified in the "m=" line. In case the The payload type(s) are specified in the "m=" line. In case the
payload type is a static payload type from RFC 3551 [RFC3551], no payload type is a static payload type from RFC 3551 [RFC3551], no
other information may be required. In case it is a dynamic payload other information may be required. In case it is a dynamic payload
type, the media attribute "rtpmap" is used to specify what the media type, the media attribute "rtpmap" is used to specify what the media
is. The "encoding name" within the "rtpmap" attribute may be one of is. The "encoding name" within the "rtpmap" attribute may be one of
those specified in RFC 3551 (Sections 5 and 6), or media type those specified in [RFC4856], or a media type registered with IANA
registered with IANA [RFC4288], or an experimental encoding as according to [RFC4855], or an experimental encoding as specified in
specified in SDP (RFC 4566 [RFC4566]). Codec-specific parameters are SDP [RFC4566]). Codec-specific parameters are not specified in this
not specified in this field, but rather in the "fmtp" attribute field, but rather in the "fmtp" attribute described below.
described below.
The selection of the RTP payload type numbers used may be required to The selection of the RTP payload type numbers used may be required to
consider RTP and RTCP Multiplexing [RFC5761] if that is to be consider RTP and RTCP Multiplexing [RFC5761] if that is to be
supported by the server. supported by the server.
D.1.4. Format-Specific Parameters D.1.4. Format-Specific Parameters
Format-specific parameters are conveyed using the "fmtp" media Format-specific parameters are conveyed using the "fmtp" media
attribute. The syntax of the "fmtp" attribute is specific to the attribute. The syntax of the "fmtp" attribute is specific to the
encoding(s) that the attribute refers to. Note that some of the encoding(s) that the attribute refers to. Note that some of the
skipping to change at page 276, line 6 skipping to change at page 263, line 33
The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
provide instructions about the direction the media streams flow provide instructions about the direction the media streams flow
within a session. When using RTSP the SDP can be delivered to a within a session. When using RTSP the SDP can be delivered to a
client using either RTSP DESCRIBE or a number of RTSP external client using either RTSP DESCRIBE or a number of RTSP external
methods, like HTTP, FTP, and email. Based on this the SDP applies to methods, like HTTP, FTP, and email. Based on this the SDP applies to
how the RTSP client will see the complete session. Thus media how the RTSP client will see the complete session. Thus media
streams delivered from the RTSP server to the client, would be given streams delivered from the RTSP server to the client, would be given
the "a=recvonly" attribute. the "a=recvonly" attribute.
The direction attributes are not commonly used in SDPs for RTSP, but "a=recvonly" in a SDP provided to the RTSP client indicates that
may occur. "a=recvonly" in a SDP provided to the RTSP client MUST media delivery will only occur in the direction from the RTSP server
indicate that media delivery will only occur in the direction from to the client. SDP provided to the RTSP client that lacks any of the
the RTSP server to the client. In SDP provided to the RTSP client directionality attributes (a=recvonly, a=sendonly, a=sendrecv) would
that lacks any of the directionality attributes (a=recvonly, be interpreated as having a=sendrecv. At the time of writing there
a=sendonly, a=sendrecv) MUST behave as if the "a=recvonly" attribute exist no RTSP mode suitable for media traffic in the direction from
was received. Note that this overrules the normal default rule the RTSP client to the server. Thus all RTSP SDP SHOULD have
defined in SDP[RFC4566]. The usage of "a=sendonly" or "a=sendrecv" a=recvonly attribute when using the PLAY mode defined in this
is not defined, nor is the interpretation of SDP by other entities document. If future modes are defined for media in client to server
than the RTSP client. direction, then usage of a=sendonly, or a=sendrecv may become
suitable to indicate intended media directions.
D.1.6. Range of Presentation D.1.6. Range of Presentation
The "a=range" attribute defines the total time range of the stored The "a=range" attribute defines the total time range of the stored
session or an individual media. Non-seekable live sessions can be session or an individual media. Non-seekable live sessions can be
indicated as specified below, while the length of live sessions can indicated as specified below, while the length of live sessions can
be deduced from the "t=" and "r=" SDP parameters. be deduced from the "t=" and "r=" SDP parameters.
The attribute is both a session and a media level attribute. For The attribute is both a session and a media level attribute. For
presentations that contain media streams of the same duration, the presentations that contain media streams of the same duration, the
skipping to change at page 277, line 5 skipping to change at page 264, line 34
Range", in case the client uses PLAY requests with a Range header. Range", in case the client uses PLAY requests with a Range header.
In case the content is dynamic in length and it is infeasible to In case the content is dynamic in length and it is infeasible to
provide a correct value in the SDP the server is recommended to provide a correct value in the SDP the server is recommended to
describe this as non-seekable content (see below). The server MAY describe this as non-seekable content (see below). The server MAY
override that property in the response to a PLAY request using the override that property in the response to a PLAY request using the
correct values in the Range header. correct values in the Range header.
The unit is specified first, followed by the value range. The units The unit is specified first, followed by the value range. The units
and their values are as defined in Section 4.4, Section 4.5 and and their values are as defined in Section 4.4, Section 4.5 and
Section 4.6 and MAY be extended with further formats. Any open ended Section 4.6 and MAY be extended with further formats. Any open ended
range (start-), i.e. without stop range, is of unspecified duration range (start-), i.e. without stop range, is of unspecified duration
and MUST be considered as non-seekable content unless this property and MUST be considered as non-seekable content unless this property
is overridden. Multiple instances carrying different clock formats is overridden. Multiple instances carrying different clock formats
MAY be included at either session or media level. MAY be included at either session or media level.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Examples: Examples:
a=range:npt=0-34.4368
a=range:clock=19971113T211503Z-19971113T220300Z a=range:npt=0-34.4368
Non seekable stream of unknown duration: a=range:clock=19971113T211503Z-19971113T220300Z
a=range:npt=0- Non seekable stream of unknown duration:
a=range:npt=0-
D.1.7. Time of Availability D.1.7. Time of Availability
The "t=" field defines when the SDP is valid. For on-demand content The "t=" field defines when the SDP is valid. For on-demand content
the server SHOULD indicate a stop time value for which it guarantees the server SHOULD indicate a stop time value for which it guarantees
the description to be valid, and a start time that is equal to or the description to be valid, and a start time that is equal to or
before the time at which the DESCRIBE request was received. It MAY before the time at which the DESCRIBE request was received. It MAY
also indicate start and stop times of 0, meaning that the session is also indicate start and stop times of 0, meaning that the session is
always available. always available.
For sessions that are of live type, i.e. specific start time, unknown For sessions that are of live type, i.e. specific start time,
stop time, likely unseekable, the "t=" and "r=" field SHOULD be used unknown stop time, likely unseekable, the "t=" and "r=" field SHOULD
to indicate the start time of the event. The stop time SHOULD be be used to indicate the start time of the event. The stop time
given so that the live event will have ended at that time, while SHOULD be given so that the live event will have ended at that time,
still not be unnecessary long into the future. while still not be unnecessary long into the future.
D.1.8. Connection Information D.1.8. Connection Information
In SDP used with RTSP, the "c=" field contains the destination In SDP used with RTSP, the "c=" field contains the destination
address for the media stream. If a multicast address is specified address for the media stream. If a multicast address is specified
the client SHOULD use this address in any SETUP request as the client SHOULD use this address in any SETUP request as
destination address, including any additional parameters, such as destination address, including any additional parameters, such as
TTL. For on-demand unicast streams and some multicast streams, the TTL. For on-demand unicast streams and some multicast streams, the
destination address MAY be specified by the client via the SETUP destination address MAY be specified by the client via the SETUP
request, thus overriding any specified address. To identify streams request, thus overriding any specified address. To identify streams
without a fixed destination address, where the client is required to without a fixed destination address, where the client is required to
specify a destination address, the "c=" field SHOULD be set to a null specify a destination address, the "c=" field SHOULD be set to a null
value. For addresses of type "IP4", this value MUST be "0.0.0.0", value. For addresses of type "IP4", this value MUST be "0.0.0.0",
and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be
written as "::"), i.e. the unspecified address according to RFC 4291 written as "::"), i.e. the unspecified address according to RFC 4291
[RFC4291]. [RFC4291].
D.1.9. Message Body Tag D.1.9. Message Body Tag
The optional "a=mtag" attribute identifies a version of the session The optional "a=mtag" attribute identifies a version of the session
description. It is opaque to the client. SETUP requests may include description. It is opaque to the client. SETUP requests may include
this identifier in the If-Match field (see Section 18.23) to only this identifier in the If-Match field (see Section 18.23) to only
allow session establishment if this attribute value still corresponds allow session establishment if this attribute value still corresponds
to that of the current description. The attribute value is opaque to that of the current description. The attribute value is opaque
and may contain any character allowed within SDP attribute values. and may contain any character allowed within SDP attribute values.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
One could argue that the "o=" field provides identical One could argue that the "o=" field provides identical
functionality. However, it does so in a manner that would put functionality. However, it does so in a manner that would put
constraints on servers that need to support multiple session constraints on servers that need to support multiple session
description types other than SDP for the same piece of media description types other than SDP for the same piece of media
content. content.
D.2. Aggregate Control Not Available D.2. Aggregate Control Not Available
If a presentation does not support aggregate control no session level If a presentation does not support aggregate control no session level
skipping to change at page 279, line 42 skipping to change at page 267, line 25
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:*
t=0 0 t=0 0
m=video 8002 RTP/AVP 31 m=video 8002 RTP/AVP 31
a=control:trackID=1 a=control:trackID=1
m=audio 8004 RTP/AVP 3 m=audio 8004 RTP/AVP 3
a=control:trackID=2 a=control:trackID=2
In this example, the client is recommended to establish a single RTSP In this example, the client is recommended to establish a single RTSP
session to the server, and uses the URIs session to the server, and uses the URIs rtsp://example.com/movie/
rtsp://example.com/movie/trackID=1 and trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video
rtsp://example.com/movie/trackID=2 to set up the video and audio and audio streams, respectively. The URI rtsp://example.com/movie/,
streams, respectively. The URI rtsp://example.com/movie/, which is which is resolved from the "*", controls the whole presentation
resolved from the "*", controls the whole presentation (movie). (movie).
A client is not required to issue SETUP requests for all streams A client is not required to issue SETUP requests for all streams
within an aggregate object. Servers should allow the client to ask within an aggregate object. Servers should allow the client to ask
for only a subset of the streams. for only a subset of the streams.
D.4. Grouping of Media Lines in SDP D.4. Grouping of Media Lines in SDP
For some types of media it is desirable to express a relationship For some types of media it is desirable to express a relationship
between various media components, for instance, for lip between various media components, for instance, for lip
synchronization or Scalable Video Codec (SVC) [RFC5583]. This synchronization or Scalable Video Codec (SVC) [RFC5583]. This
skipping to change at page 280, line 32 skipping to change at page 268, line 15
D.5. RTSP external SDP delivery D.5. RTSP external SDP delivery
There are some considerations that need to be made when the session There are some considerations that need to be made when the session
description is delivered to the client outside of RTSP, for example description is delivered to the client outside of RTSP, for example
via HTTP or email. via HTTP or email.
First of all, the SDP needs to contain absolute URIs, since relative First of all, the SDP needs to contain absolute URIs, since relative
will in most cases not work as the delivery will not correctly will in most cases not work as the delivery will not correctly
forward the base URI. forward the base URI.
The writing of the SDP session availability information, i.e. "t=" The writing of the SDP session availability information, i.e. "t="
and "r=", needs to be carefully considered. When the SDP is fetched and "r=", needs to be carefully considered. When the SDP is fetched
by the DESCRIBE method, the probability that it is valid is very by the DESCRIBE method, the probability that it is valid is very
high. However, the same is much less certain for SDPs distributed high. However, the same is much less certain for SDPs distributed
using other methods. Therefore the publisher of the SDP should take using other methods. Therefore the publisher of the SDP should take
care to follow the recommendations about availability in the SDP care to follow the recommendations about availability in the SDP
specification [RFC4566] in Section 4.2. specification [RFC4566] in Section 4.2.
Appendix E. RTSP Use Cases Appendix E. RTSP Use Cases
This Appendix describes the most important and considered use cases This Appendix describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in for RTSP. They are listed in descending order of importance in
regards to ensuring that all necessary functionality is present. regards to ensuring that all necessary functionality is present.
This specification only fully supports usage of the two first. Also This specification only fully supports usage of the two first. Also
in these first two cases, there are special cases or exceptions that in these first two cases, there are special cases or exceptions that
are not supported without extensions, e.g. the redirection of media are not supported without extensions, e.g. the redirection of media
delivery to another address than the controlling agent's (client's). delivery to another address than the controlling agent's (client's).
E.1. On-demand Playback of Stored Content E.1. On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required to deliver the uses RTSP to set up the media transport required to deliver the
desired content. RTSP is then used to initiate, halt and manipulate desired content. RTSP is then used to initiate, halt and manipulate
the actual transmission (playout) of the content. RTSP is also the actual transmission (playout) of the content. RTSP is also
required to provide necessary description and synchronization required to provide necessary description and synchronization
skipping to change at page 284, line 18 skipping to change at page 271, line 44
There are several issues with this use case that are not solved by There are several issues with this use case that are not solved by
this core specification for RTSP: this core specification for RTSP:
Denial of service: To avoid an RTSP server from being an unknowing Denial of service: To avoid an RTSP server from being an unknowing
participant in a denial of service attack the server needs to participant in a denial of service attack the server needs to
be able to verify the destination's acceptance of the media. be able to verify the destination's acceptance of the media.
Such a mechanism to verify the approval of received media does Such a mechanism to verify the approval of received media does
not yet exist; instead, only policies can be used, which can be not yet exist; instead, only policies can be used, which can be
made to work in controlled environments. made to work in controlled environments.
Distributing the presentation description to all participants in the Distributing the presentation description to all participants in the group:
group: To enable a media receiver to correctly decode the content To enable a media receiver to correctly decode the content
the media configuration information needs to be distributed the media configuration information needs to be distributed
reliably to all participants. This will most likely require reliably to all participants. This will most likely require
support from an external protocol. support from an external protocol.
Passing control of the session: If it is desired to pass control of Passing control of the session: If it is desired to pass control
the RTSP session between the participants, some support will be of the RTSP session between the participants, some support
required by an external protocol to exchange state information will be required by an external protocol to exchange state
and possibly floor control of who is controlling the RTSP information and possibly floor control of who is controlling
session. the RTSP session.
E.5. Live Content using Multicast E.5. Live Content using Multicast
This use case in its simplest form does not require any use of RTSP This use case in its simplest form does not require any use of RTSP
at all; this is what multicast conferences being announced with SAP at all; this is what multicast conferences being announced with SAP
[RFC2974] and SDP are intended to handle. However, in use cases [RFC2974] and SDP are intended to handle. However, in use cases
where more advanced features like access control to the multicast where more advanced features like access control to the multicast
session are desired, RTSP could be used for session establishment. session are desired, RTSP could be used for session establishment.
A client desiring to join a live multicasted media session with A client desiring to join a live multicasted media session with
skipping to change at page 289, line 9 skipping to change at page 275, line 4
maintained: maintained:
o CSeq: See Section 18.19 o CSeq: See Section 18.19
o Timestamp: See Section 18.51 o Timestamp: See Section 18.51
Appendix H. Backwards Compatibility Considerations Appendix H. Backwards Compatibility Considerations
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 with clients or servers being implemented according to RFC 2326
[RFC2326]. Note that there exists no requirement to implement RTSP [RFC2326]. Note that there exists no requirement to implement RTSP
1.0; in fact we recommend against it as it is difficult to do in an 1.0; in fact we recommend against it as it is difficult to do in an
interoperable way. interoperable way.
A server implementing RTSP/2.0 MUST include an RTSP-Version of A server implementing RTSP/2.0 MUST include an RTSP-Version of RTSP/
RTSP/2.0 in all responses to requests containing RTSP-Version 2.0 in all responses to requests containing RTSP-Version RTSP/2.0.
RTSP/2.0. If a server receives an RTSP/1.0 request, it MAY respond If a server receives an RTSP/1.0 request, it MAY respond with an RTSP
with an RTSP/1.0 response if it chooses to support RFC 2326. If the /1.0 response if it chooses to support RFC 2326. If the server
server chooses not to support RFC 2326, it MUST respond with a 505 chooses not to support RFC 2326, it MUST respond with a 505 (RTSP
(RTSP Version not supported) status code. A server MUST NOT respond Version not supported) status code. A server MUST NOT respond to an
to an RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 RTSP-Version RTSP/1.0 request with an RTSP-Version RTSP/2.0 response.
response.
Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP-
Version of 2.0 to determine whether a server supports RTSP/2.0. If Version of 2.0 to determine whether a server supports RTSP/2.0. If
the server responds with either an RTSP-Version of 1.0 or a status the server responds with either an RTSP-Version of 1.0 or a status
code of 505 (RTSP Version not supported), the client will have to use code of 505 (RTSP Version not supported), the client will have to use
RTSP/1.0 requests if it chooses to support RFC 2326. RTSP/1.0 requests if it chooses to support RFC 2326.
H.1. Play Request in Play State H.1. Play Request in Play State
The behavior in the server when a Play is received in Play state has The behavior in the server when a Play is received in Play state has
skipping to change at page 298, line 24 skipping to change at page 283, line 32
This document has benefited greatly from the comments of all those This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already participating in the MMUSIC-WG. In addition to those already
mentioned, the following individuals have contributed to this mentioned, the following individuals have contributed to this
specification: specification:
Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Rahul Agarwal, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning,
Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari,
Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V.
Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson,
Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo
F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria
Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins,
Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior
Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis
Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan
Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell,
Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick
Hoffman, Jinhang Choi, Ross Finlayson, and especially to Flemming Hoffman, Jinhang Choi, Ross Finlayson, Dale R. Worley, and
Andreasen. especially to Flemming Andreasen.
J.1. Contributors J.1. Contributors
The following people have made written contributions that were The following people have made written contributions that were
included in the specification: included in the specification:
o Tom Marshall contributed text on the usage of 3rr status codes. o Tom Marshall contributed text on the usage of 3rr status codes.
o Thomas Zheng contributed text on the usage of the Range in PLAY o Thomas Zheng contributed text on the usage of the Range in PLAY
responses and proposed an earlier version of the PLAY_NOTIFY responses and proposed an earlier version of the PLAY_NOTIFY
skipping to change at page 301, line 20 skipping to change at page 285, line 4
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
Anup Rao Anup Rao
Cisco Cisco
USA USA
Email: anrao@cisco.com Email: anrao@cisco.com
Rob Lanphier Rob Lanphier
Seattle, WA Seattle, WA
USA USA
Email: robla@robla.net Email: robla@robla.net
Magnus Westerlund Magnus Westerlund
Ericsson AB Ericsson AB
Faeroegatan 6 Faeroegatan 6
STOCKHOLM, SE-164 80 STOCKHOLM SE-164 80
SWEDEN SWEDEN
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Martin Stiemerling Martin Stiemerling
NEC Laboratories Europe, NEC Europe Ltd. NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
 End of changes. 207 change blocks. 
1205 lines changed or deleted 1288 lines changed or added

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