draft-ietf-mmusic-rfc2326bis-21.txt   draft-ietf-mmusic-rfc2326bis-22.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: RFC 2326 A. Rao Obsoletes: RFC 2326 A. Rao
(if approved) Cisco (if approved) Cisco
Intended status: Standards Track R. Lanphier Intended status: Standards Track R. Lanphier
Expires: December 21, 2009 Expires: January 14, 2010
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
June 19, 2009 July 13, 2009
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-21 draft-ietf-mmusic-rfc2326bis-22
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 23 skipping to change at page 3, line 23
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).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1. Notes on Copyright . . . . . . . . . . . . . . . . . . . 11 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Content Description . . . . . . . . . . . . . . . . . . 12
2.1. Content Description . . . . . . . . . . . . . . . . . . 13 2.2. Session Establishment . . . . . . . . . . . . . . . . . 13
2.2. Session Establishment . . . . . . . . . . . . . . . . . 14 2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 14
2.3. Media Delivery Control . . . . . . . . . . . . . . . . . 15 2.4. Session Parameter Manipulations . . . . . . . . . . . . 16
2.4. Session Parameter Manipulations . . . . . . . . . . . . 17 2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 16
2.5. Media Delivery . . . . . . . . . . . . . . . . . . . . . 17 2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 17
2.5.1. Media Delivery Manipulations . . . . . . . . . . . . 18 2.6. Session Maintenance and Termination . . . . . . . . . . 19
2.6. Session Maintenance and Termination . . . . . . . . . . 20 2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 20
2.7. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 21 3. Document Conventions . . . . . . . . . . . . . . . . . . . . 22
3. Document Conventions . . . . . . . . . . . . . . . . . . . . 23 3.1. Notational Conventions . . . . . . . . . . . . . . . . . 22
3.1. Notational Conventions . . . . . . . . . . . . . . . . . 23 3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 22
3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 23 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 26
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 27 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 26
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 27 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 26
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 27 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 28
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 29 4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 28
4.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 29 4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 29
4.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 30 4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 30
4.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 31 4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 30
4.7. Feature-Tags . . . . . . . . . . . . . . . . . . . . . . 31 4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 30
4.8. Message Body Tags . . . . . . . . . . . . . . . . . . . 31 4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 31
4.9. Media Properties . . . . . . . . . . . . . . . . . . . . 32 4.9.1. Random Access and Seeking . . . . . . . . . . . . . 32
4.9.1. Random Access . . . . . . . . . . . . . . . . . . . 33 4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 32
4.9.2. Retention . . . . . . . . . . . . . . . . . . . . . 33 4.9.3. Content Modifications . . . . . . . . . . . . . . . 32
4.9.3. Content Modifications . . . . . . . . . . . . . . . 33 4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 33
4.9.4. Supported Scale Factors . . . . . . . . . . . . . . 34 4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 33
4.9.5. Mapping to the Attributes . . . . . . . . . . . . . 34 5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 34
5. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 34
5.1. Message Types . . . . . . . . . . . . . . . . . . . . . 35 5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 35
5.2. Message Headers . . . . . . . . . . . . . . . . . . . . 36 5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 36 5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 36
5.4. Message Length . . . . . . . . . . . . . . . . . . . . . 37 6. General Header Fields . . . . . . . . . . . . . . . . . . . . 37
6. General Header Fields . . . . . . . . . . . . . . . . . . . . 38 7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 38
7.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Request Header Fields . . . . . . . . . . . . . . . . . 40
7.2. Request Header Fields . . . . . . . . . . . . . . . . . 41 8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 42
8.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 43 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 42
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 43 8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 45
8.2. Response Headers . . . . . . . . . . . . . . . . . . . . 46 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 49 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48
9.1. Message Body Header Fields . . . . . . . . . . . . . . . 49 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 50 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 51 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 51 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 52 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 54 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 55 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 54
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 55
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 56
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 57 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 58
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 59 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 59
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 60 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 60
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 61 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 61
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 62 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 63
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 64 13.3.1. Changing Transport Parameters . . . . . . . . . . . 66
13.3.1. Changing Transport Parameters . . . . . . . . . . . 67 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 68 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 67
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 68 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 71
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 72 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 72
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 73 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 73
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 74 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 74
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 75 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 74
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 75 13.4.7. Playing Live with Recording . . . . . . . . . . . . 75
13.4.7. Playing Live with Recording . . . . . . . . . . . . 76 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 75
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 76 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 76
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 77 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 77
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 78 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 78
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 79 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 79
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 80 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 81 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 83
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 84 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 83
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 84 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 84
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 85 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 85
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 86 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 86
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 87 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 88
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 89 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 91
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 92 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 93
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 94 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 93
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 94 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 93
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 94 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 93
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 94 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 93
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 94 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 93
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 94 15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 94
15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 95 15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 94
15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 95 15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 94
15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 95 15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 94
15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 95 15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 95
15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 96 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 95
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 96 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 95
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 96 15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 95
15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 96 15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 96
15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 97 15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 96
15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 97 15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 96
15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 97 15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 96
15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 97 15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 96
15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 97 15.4.8. 407 Proxy Authentication Required . . . . . . . . . 97
15.4.8. 407 Proxy Authentication Required . . . . . . . . . 98 15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 97
15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 98 15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 97
15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 98 15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 97
15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 98 15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 98
15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 99 15.4.13. 413 Request Message Body Too Large . . . . . . . . . 98
15.4.13. 413 Request Message Body Too Large . . . . . . . . . 99 15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 98
15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 99 15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 98
15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 99 15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 98
15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 99 15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 98
15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 99 15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 99
15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 100 15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 99
15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 100 15.4.20. 455 Method Not Valid in This State . . . . . . . . . 99
15.4.20. 455 Method Not Valid in This State . . . . . . . . . 100 15.4.21. 456 Header Field Not Valid for Resource . . . . . . 99
15.4.21. 456 Header Field Not Valid for Resource . . . . . . 100 15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 99
15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 100 15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 99
15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 100 15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 99
15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 100 15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 99
15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 100 15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 100
15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 101 15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 100
15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 101 15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 100
15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 101 15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 100
15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 101 15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 100
15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 101 15.4.31. 470 Connection Authorization Required . . . . . . . 100
15.4.31. 470 Connection Authorization Required . . . . . . . 101 15.4.32. 471 Connection Credentials not accepted . . . . . . 101
15.4.32. 471 Connection Credentials not accepted . . . . . . 102 15.4.33. 472 Failure to establish secure connection . . . . . 101
15.4.33. 472 Failure to establish secure connection . . . . . 102 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 101
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 102 15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 101
15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 102 15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 101
15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 102 15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 101
15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 102 15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 101
15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 102 15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 102
15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 103 15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 102
15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 103 15.5.7. 551 Option not supported . . . . . . . . . . . . . . 102
15.5.7. 551 Option not supported . . . . . . . . . . . . . . 103 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 103
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 104 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 112
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 113 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 113
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 114 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 113
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 114 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 114
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 115 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 115
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 116
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 116 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 116
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 117 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 116
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 118 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 117
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 118 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 117
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 118 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 117
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 121 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 120
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 121 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 120
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 122 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 121
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 122 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 121
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 123 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 122
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 124 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 123
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 124 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 123
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 124 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 123
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 124
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 124
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 126 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 125
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 127 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 126
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 126
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 128 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 127
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 128 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 127
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 129 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 128
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 129 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 128
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 130 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 129
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 132 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 131
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 132 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 133 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 132
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 133 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 132
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 133
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 134 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 133
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 135 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 134
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 135 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 134
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 136 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 135
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 137 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 136
16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 138 16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 137
16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 139 16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 138
16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 139 16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 138
16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 139 16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 138
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 140 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 139
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 142 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 142
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 143 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 143
16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 144
16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 144
16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 146 16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 145
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 147 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 146
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 147 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 147
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 148 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 147
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 148 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 147
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 155 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 154
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 155 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 154
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 156 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 155
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 156 16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 156
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 157 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 156
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 159 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 158
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.1. Validation Model (HTTP) . . . . . . . . . . . . . . . . 162 18.1. Validation Model (HTTP) . . . . . . . . . . . . . . . . 161
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 163 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 162
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 163 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 162
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 163 18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 162
18.1.4. Rules for When to Use Entity Tags and 18.1.4. Rules for When to Use Entity Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 166 Last-Modified Dates . . . . . . . . . . . . . . . . 165
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 167 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 166
18.2. Invalidation After Updates or Deletions (HTTP) . . . . . 167 18.2. Invalidation After Updates or Deletions (HTTP) . . . . . 166
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 169 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 168
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 169 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 168
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 169 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 168
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 170 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 169
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 171 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 170
19.3.2. User approved TLS procedure . . . . . . . . . . . . 172 19.3.2. User approved TLS procedure . . . . . . . . . . . . 171
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 174 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 173
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 176 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 175
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 176 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 175
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 179 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 178
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 183 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 182
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 192 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 191
21. Security Considerations . . . . . . . . . . . . . . . . . . . 193 21. Security Considerations . . . . . . . . . . . . . . . . . . . 192
21.1. Remote denial of Service Attack . . . . . . . . . . . . 195 21.1. Remote denial of Service Attack . . . . . . . . . . . . 194
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 197 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 196
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 197 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 196
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 197 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 196
22.1.2. Registering New Feature-tags with IANA . . . . . . . 198 22.1.2. Registering New Feature-tags with IANA . . . . . . . 197
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 198 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 197
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 198 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 197
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 198 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 197
22.2.2. Registering New Methods with IANA . . . . . . . . . 198 22.2.2. Registering New Methods with IANA . . . . . . . . . 197
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 199 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 198
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 199 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 198
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 199 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.3.2. Registering New Status Codes with IANA . . . . . . . 199 22.3.2. Registering New Status Codes with IANA . . . . . . . 198
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 199 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 198
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 199 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 198
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 199 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 198
22.4.2. Registering New Headers with IANA . . . . . . . . . 200 22.4.2. Registering New Headers with IANA . . . . . . . . . 199
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 200 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 199
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 201 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 200
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 201 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 200
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 201 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 200
22.6. Cache-Control Cache Directive Extensions . . . . . . . 202 22.6. Cache-Control Cache Directive Extensions . . . . . . . 201
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 202 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 202
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 203 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 202
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 203 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 202
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 203 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 202
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 203 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 202
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 203 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 202
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 203 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 203
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 204 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 203
22.9. Range header formats . . . . . . . . . . . . . . . . . . 204 22.9. Range header formats . . . . . . . . . . . . . . . . . . 203
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 204 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 204
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 204 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 204
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 205 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 204
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 205 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 204
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 205 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 204
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 205 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 204
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 205 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 205
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 206 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 205
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 206 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 206 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 205
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 206 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 205
22.13. Transport Header Registries . . . . . . . . . . . . . . 206 22.13. Transport Header Registries . . . . . . . . . . . . . . 206
22.13.1. Transport Protocol Specification . . . . . . . . . . 207 22.13.1. Transport Protocol Specification . . . . . . . . . . 206
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 208 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 207
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 208 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 207
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 209 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 208
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 209 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 208
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 210 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 209
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 211 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 210
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 211 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 211
22.16. Media Type Registration for text/parameters . . . . . . 212 22.16. Media Type Registration for text/parameters . . . . . . 211
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 214 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 213
23.1. Normative References . . . . . . . . . . . . . . . . . . 214 23.1. Normative References . . . . . . . . . . . . . . . . . . 213
23.2. Informative References . . . . . . . . . . . . . . . . . 216 23.2. Informative References . . . . . . . . . . . . . . . . . 215
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 218 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 217
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 218 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 217
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 221 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 220
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 224 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 223
A.4. Single Stream Container Files . . . . . . . . . . . . . 228 A.4. Single Stream Container Files . . . . . . . . . . . . . 227
A.5. Live Media Presentation Using Multicast . . . . . . . . 230 A.5. Live Media Presentation Using Multicast . . . . . . . . 229
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 231 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 230
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 233 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 232
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 233 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 232
B.2. State variables . . . . . . . . . . . . . . . . . . . . 233 B.2. State variables . . . . . . . . . . . . . . . . . . . . 232
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 233 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 232
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 234 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 233
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 239 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 238
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 239 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 238
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 239 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 238
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 239 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 238
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 240 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 239
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 241 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 240
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 241 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 240
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 241 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 240
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 242 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 241
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 243 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 242
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 243 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 242
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 247 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 246
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 251 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 250
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 253 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 252
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 253 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 252
C.7. Maintaining NPT synchronization with RTP timestamps . . 253 C.7. Maintaining NPT synchronization with RTP timestamps . . 252
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 253 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 252
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 253 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 252
C.10. Usage of SSRCs and the RTCP BYE Message During an C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 253 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 252
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 254 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 253
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 255 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 254
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 255 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 254
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 255 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 254
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 256 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 255
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 257 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 256
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 257 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 256
D.1.5. Directionality of media stream . . . . . . . . . . . 257 D.1.5. Directionality of media stream . . . . . . . . . . . 256
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 258 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 257
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 259 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 258
D.1.8. Connection Information . . . . . . . . . . . . . . . 259 D.1.8. Connection Information . . . . . . . . . . . . . . . 258
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 259 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 258
D.2. Aggregate Control Not Available . . . . . . . . . . . . 260 D.2. Aggregate Control Not Available . . . . . . . . . . . . 259
D.3. Aggregate Control Available . . . . . . . . . . . . . . 260 D.3. Aggregate Control Available . . . . . . . . . . . . . . 259
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 261 D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 260
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 263 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 262
E.1. On-demand Playback of Stored Content . . . . . . . . . . 263 E.1. On-demand Playback of Stored Content . . . . . . . . . . 262
E.2. Unicast Distribution of Live Content . . . . . . . . . . 264 E.2. Unicast Distribution of Live Content . . . . . . . . . . 263
E.3. On-demand Playback using Multicast . . . . . . . . . . . 265 E.3. On-demand Playback using Multicast . . . . . . . . . . . 264
E.4. Inviting an RTSP server into a conference . . . . . . . 265 E.4. Inviting an RTSP server into a conference . . . . . . . 264
E.5. Live Content using Multicast . . . . . . . . . . . . . . 266 E.5. Live Content using Multicast . . . . . . . . . . . . . . 265
Appendix F. Text format for Parameters . . . . . . . . . . . . . 268 Appendix F. Text format for Parameters . . . . . . . . . . . . . 267
Appendix G. Requirements for Unreliable Transport of RTSP . . . 269 Appendix G. Requirements for Unreliable Transport of RTSP . . . 268
Appendix H. Backwards Compatibility Considerations . . . . . . . 271 Appendix H. Backwards Compatibility Considerations . . . . . . . 270
H.1. Play Request in Play mode . . . . . . . . . . . . . . . 271 H.1. Play Request in Play mode . . . . . . . . . . . . . . . 270
H.2. Using Persistent Connections . . . . . . . . . . . . . . 271 H.2. Using Persistent Connections . . . . . . . . . . . . . . 270
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 272 Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 271
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 273 Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 272
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 280 Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 279
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 280 K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 279
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 282 Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 281
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 283 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 282
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, as you know it from "network remote control" for multimedia servers, as you know it from
your TV set. your TV set.
skipping to change at page 11, line 49 skipping to change at page 12, line 5
This document is structured in the way that it begins with an This document is structured in the way that it begins with an
overview of the protocol operations and its functions in an informal overview of the protocol operations and its functions in an informal
way. Then a set of definitions of used terms and document way. Then a set of definitions of used terms and document
conventions is introduced. Then comes the actual protocol conventions is introduced. Then comes the actual protocol
specification. In the appendix some functionality that isn't core specification. In the appendix some functionality that isn't core
RTSP defined, but still important to enable some usage, like RTP and RTSP defined, but still important to enable some usage, like RTP and
SDP usage with RTSP. This is followed by a number of informational SDP usage with RTSP. This is followed by a number of informational
parts discussing the changes, use cases, different considerations or parts discussing the changes, use cases, different considerations or
motivations. motivations.
1.1. Notes on Copyright
The IETF has adopted new IPR contributor rules in [RFC5378], which
results in a changed model of copyright. The baseline is that "The
IETF Trust and the IETF must obtain the right to publish an IETF
Contribution as an RFC or an Internet-Draft from the Contributors."
(taken from Section 3.1 of [RFC5378]).
This memo has plenty of text taken from [RFC2326] and thus the
associated copyright. Magnus Westerlund has solicited the authors of
[RFC2326] and this memo to transfer the copyright to the new model,
i.e., to the IETF trust and the IETF. Most of the authors have
responded and transferred their copyright. However, not all of them
have. This is the first reason for the currently used boiler plate
(and thus the current status), i.e., with pre5378Trust200902. See
also this document [IETF-Trust-License-Policy] for more information.
Furthermore, this memo does contain text that has been copied and
modified from [RFC2616]. Older versions of this memo solely linked
to the particular places. Linking to the HTTP/1.1 specification was
not appropriate anymore, as the text was not fitting to RTSP 2.0
needs and had to be adapted. Thus text copied from HTTP/1.1 is still
under copyright prior to [RFC5378].
2. Protocol Overview 2. Protocol Overview
This section provides a informative overview of the different This section provides a informative overview of the different
mechanisms in the RTSP 2.0 protocol, to give the reader a high level mechanisms in the RTSP 2.0 protocol, to give the reader a high level
understanding before getting into all the different details. In case understanding before getting into all the different details. In case
of conflict with this description and the later sections, the later of conflict with this description and the later sections, the later
sections take precedence. For more information about considered use sections take precedence. For more information about considered use
cases for RTSP see Appendix E. cases for RTSP see Appendix E.
RTSP 2.0 is a bi-directional request and response protocol that first RTSP 2.0 is a bi-directional request and response protocol that first
establish a context including content resources (the media) and then establish a context including content resources (the media) and then
controls the delivery of these content resources from the server to controls the delivery of these content resources from the server to
the client. RTSP has three fundamental parts of interest: Session the client. RTSP has three fundamental parts of interest: Session
Establishment, Playback Control, and an extensibility model described Establishment, Media Delivery Control, and an extensibility model
below. The protocol is based on some assumptions on existing described below. The protocol is based on some assumptions on
functionality to provide a complete solution for client controlled existing functionality to provide a complete solution for client
real-time media delivery. controlled real-time media delivery.
RTSP uses text-based messages, requests and responses, that may RTSP uses text-based messages, requests and responses, that may
contain a binary message body. An RTSP request starts with a method contain a binary message body. An RTSP request starts with a method
line that identifies the method, the protocol and version and the line that identifies the method, the protocol and version and the
resource to act on. Following the method line follows a number of resource to act on. Following the method line follows a number of
RTSP headers. This part is ended by two consecutive carriage return RTSP headers. This part is ended by two consecutive carriage return
line feed (CRLF) character pairs. The message body if present line feed (CRLF) character pairs. The message body if present
follows the two CRLF and the bodies length are described by a message follows the two CRLF and the bodies length are described by a message
header. RTSP responses are similar, but start with a response line header. RTSP responses are similar, but start with a response line
with protocol and version, followed by a status code and a reason with protocol and version, followed by a status code and a reason
skipping to change at page 14, line 30 skipping to change at page 13, line 30
This specification describes in Appendix D how one uses SDP [RFC4566] This specification describes in Appendix D how one uses SDP [RFC4566]
for Content Description for Content Description
2.2. Session Establishment 2.2. Session Establishment
The RTSP client can request the establishment of an RTSP session The RTSP client can request the establishment of an RTSP session
after having used the content description to determine which media after having used the content description to determine which media
streams are available, and also which media delivery protocol is used streams are available, and also which media delivery protocol is used
and their particular resource identifiers. The RTSP session is a and their particular resource identifiers. The RTSP session is a
common context between the client and the server that consist of one common context between the client and the server that consist of one
or more media resource that is to be under common playback control. or more media resource that is to be under common media delivery
control.
The client creates an RTSP session by sending an request using the The client creates an RTSP session by sending an request using the
SETUP method (Section 13.3) to the server. In the SETUP request the SETUP method (Section 13.3) to the server. In the SETUP request the
client also includes all the transport parameter necessary to enable client also includes all the transport parameter necessary to enable
the media delivery protocol to function in the "Transport" header the media delivery protocol to function in the "Transport" header
(Section 16.52). This includes parameters that are pre-established (Section 16.52). This includes parameters that are pre-established
by the content description but necessary for any middlebox to by the content description but necessary for any middlebox to
correctly handle the media delivery protocols. The Transport header correctly handle the media delivery protocols. The Transport header
in a request may contain multiple alternatives for media delivery in in a request may contain multiple alternatives for media delivery in
a prioritized list, which the server can select from. These a prioritized list, which the server can select from. These
alternatives are typically based on information in the content alternatives are typically based on information in the content
description. description.
The server determines if the media resource is available upon The server determines if the media resource is available upon
receiving a SETUP request and if any of the transport parameter receiving a SETUP request and if any of the transport parameter
specifications are acceptable. If that is successful, an RTSP specifications are acceptable. If that is successful, an RTSP
session context is created and the relevant parameters and state is session context is created and the relevant parameters and state is
stored. An identifier is created for the RTSP session and included stored. An identifier is created for the RTSP session and included
in the response in the Session header (Section 16.48). The SETUP in the response in the Session header (Section 16.47). The SETUP
response includes a Transport header that specifies which of the response includes a Transport header that specifies which of the
alternatives that have been selected and relevant parameters. alternatives that have been selected and relevant parameters.
A SETUP request that references an existing RTSP session but A SETUP request that references an existing RTSP session but
identifies a new media resource is a request to add that media identifies a new media resource is a request to add that media
resource under common control with the already present media resource under common control with the already present media
resources in an aggregated session. A client can expect this to work resources in an aggregated session. A client can expect this to work
for all media resources under RTSP control within a multi-media for all media resources under RTSP control within a multi-media
content. However, aggregating resources from different content are content. However, aggregating resources from different content are
likely to be refused by the server. The RTSP session as aggregate is likely to be refused by the server. The RTSP session as aggregate is
skipping to change at page 15, line 26 skipping to change at page 14, line 27
aggregated RTSP sessions, RTSP 2.0 supports pipelined requests, i.e., aggregated RTSP sessions, RTSP 2.0 supports pipelined requests, i.e.,
the client can send multiple requests back to back without waiting the client can send multiple requests back to back without waiting
first for the completion of any of them. The client uses client first for the completion of any of them. The client uses client
selected identifier in the Pipelined-Requests header to instruct the selected identifier in the Pipelined-Requests header to instruct the
server to bind multiple requests together as if they included the server to bind multiple requests together as if they included the
session identifier. session identifier.
The SETUP response also provides additional information about the The SETUP response also provides additional information about the
established sessions in a couple of different headers. The Media- established sessions in a couple of different headers. The Media-
Properties header include a number of properties that apply for the Properties header include a number of properties that apply for the
aggregate that is valuable when doing playback control and aggregate that is valuable when doing media delivery control and
configuring user interface. The Accept-Ranges header inform the configuring user interface. The Accept-Ranges header inform the
client about which range formats that the server supports with these client about which range formats that the server supports with these
media resources. The Media-Range header inform the client about the media resources. The Media-Range header inform the client about the
time range of the media currently available. time range of the media currently available.
2.3. Media Delivery Control 2.3. Media Delivery Control
After having established an RTSP session, the client can start After having established an RTSP session, the client can start
controlling the media delivery. The basic operations are Start by controlling the media delivery. The basic operations are Start by
using the PLAY method (Section 13.4) and Halt by using the PAUSE using the PLAY method (Section 13.4) and Halt by using the PAUSE
skipping to change at page 18, line 8 skipping to change at page 17, line 10
outside of RTSP and this protocol is determined during the session outside of RTSP and this protocol is determined during the session
establishment. This document specifies how media is delivered with establishment. This document specifies how media is delivered with
RTP over UDP, TCP or the RTSP control connection. Additional RTP over UDP, TCP or the RTSP control connection. Additional
protocols may be specified in the future based on demand. protocols may be specified in the future based on demand.
The usage of RTP as media delivery protocol requires some additional The usage of RTP as media delivery protocol requires some additional
information to function well. The PLAY responses contains information to function well. The PLAY responses contains
synchronization information to enable reliable and timely deliver of synchronization information to enable reliable and timely deliver of
how a client should synchronize different sources in the different how a client should synchronize different sources in the different
RTP sessions. It also provides a mapping between RTP timestamps and RTP sessions. It also provides a mapping between RTP timestamps and
the content time scale. When the server is notifying the client the content time scale. When the server want to notify the client
about the end of the media delivery requested using PLAY, it sends a about the completion of the media delivery, it sends a PLAY_NOTIFY
PLAY_NOTIFY request to the client. The PLAY_NOTIFY request includes request to the client. The PLAY_NOTIFY request includes information
information about the last RTP sequence numbers for each stream, and about the stream end, including the last RTP sequence number for each
thus enables correct handling of the buffer drainage at the end. stream, thus enabling the client to empty the buffer smoothly.
2.5.1. Media Delivery Manipulations 2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP is to request content for a The basic playback functionality of RTSP is to request content for a
particular range to be delivered to the client in a pace that enables particular range to be delivered to the client in a pace that enables
playback as intended by the creator. However, RTSP can also playback as intended by the creator. However, RTSP can also
manipulate how this delivery is done to the client in two ways. manipulate how this delivery is done to the client in two ways.
Scale: The ratio of media content time delivered per unit playback Scale: The ratio of media content time delivered per unit playback
time. time.
skipping to change at page 19, line 7 skipping to change at page 18, line 8
type dependent. Lets exemplify with two common media types audio and type dependent. Lets exemplify with two common media types audio and
video. video.
It is very difficult to modify the playback rate of audio. A maximum It is very difficult to modify the playback rate of audio. A maximum
of 10-30% is possible by changing the pitch-rate of speech. Music of 10-30% is possible by changing the pitch-rate of speech. Music
goes out of tune if one tries to manipulate the playback rate by goes out of tune if one tries to manipulate the playback rate by
resampling it. This is a well known problem and audio is commonly resampling it. This is a well known problem and audio is commonly
muted or played back in short segments with skips to keep up with the muted or played back in short segments with skips to keep up with the
current playback point. current playback point.
For video is possible to manipulate the number of frames that is For video is possible to manipulate the frame rate, although the
displayed per second, but the rendering capabilities are often rendering capabilities are often limited to certain frame rates.
limited to certain frame rates. The decoding, handling capabilities Also the allowed bit-rates in decoding, the structured used in the
and bitrate of received encoded content also limits the number of encoding and its dependency between frames and other capabilities of
frames that can be delivered. Therefore, when providing fast the rendering device limits the possible manipulations. Therefore
forward, one generally picks a subset of the frames from the original basic fast forward capabilities often is implemented by selecting
content to be displayed. However, the video encoding methods used certain sub-sets of frames.
will commonly limit the possibilities on which frames that can be
chosen and still be decoded by the receiver.
Due to the media restrictions, a particular content will commonly be Due to the media restrictions, the possible scale values are commonly
restricted to a limited set of possible scale ratios. To handle this restricted to a limited set of possible scale ratios. To enable the
correctly, RTSP has a mechanism to indicate the supported Scale clients to select from the possible scale values, RTSP can signal the
ratios for the content. To support aggregated or dynamic content, supported Scale ratios for the content. To support aggregated or
where this may change during the ongoing session and dependent on the dynamic content, where this may change during the ongoing session and
location within the content, a mechanism for updating the media dependent on the location within the content, a mechanism for
properties and the current used scale factor exist. updating the media properties and the current used scale factor
exist.
Speed affects how much of the playback timeline that is delivered in Speed affects how much of the playback timeline that is delivered in
a given wallclock period. The default is Speed = 1 which is to a given wallclock period. The default is Speed = 1 which is to
deliver at the same rate the media is consumed. Speed > 1 means that deliver at the same rate the media is consumed. Speed > 1 means that
the receiver will get content faster than it regularly would consume the receiver will get content faster than it regularly would consume
it. Speed < 1 means that delivery is slower than the regular media it. Speed < 1 means that delivery is slower than the regular media
rate. Speed values of 0 or lower has no meaning and are not allowed. rate. Speed values of 0 or lower has no meaning and are not allowed.
This mechanism enables two general functionalities. Client side This mechanism enables two general functionalities. Client side
scale operations, i.e. the client receives all the frames and makes scale operations, i.e. the client receives all the frames and makes
the adjustment to the playback locally. The second usage is to the adjustment to the playback locally. The second usage is to
skipping to change at page 21, line 18 skipping to change at page 20, line 18
TEARDOWN request to the server referencing the aggregated control TEARDOWN request to the server referencing the aggregated control
URI. An individual media resource can be removed from a session URI. An individual media resource can be removed from a session
context by a TEARDOWN request referencing that particular media context by a TEARDOWN request referencing that particular media
resource. If all media resources are removed from a session context, resource. If all media resources are removed from a session context,
the session context is terminated. the session context is terminated.
A client may keep the session alive indefinitely if allowed by the A client may keep the session alive indefinitely if allowed by the
server, however it is recommend to release the session context when server, however it is recommend to release the session context when
an extended period of time without media delivery activity has an extended period of time without media delivery activity has
passed. It can re-establish the session context if required later. passed. It can re-establish the session context if required later.
One issue is that what is extended periods of time is dependent on One issue is that what is an extended period of time is dependent on
the server and its usage. It is recommended that the client the server and its usage. It is recommended that the client
terminates the session before 10*times the session timeout value has terminates the session before 10*times the session timeout value has
passed. A server may terminate the session after one session timeout passed. A server may terminate the session after one session timeout
period without any client activity beyond keep-alive. When a server period without any client activity beyond keep-alive. When a server
terminates the session context, it does that by sending a TEARDOWN terminates the session context, it does that by sending a TEARDOWN
request indicating the reason. request indicating the reason.
A server can also request that the client tear down the session and A server can also request that the client tear down the session and
re-establish it at an alternative server, as may be needed for re-establish it at an alternative server, as may be needed for
maintenance. This is done by using the REDIRECT method. The maintenance. This is done by using the REDIRECT method. The
skipping to change at page 24, line 17 skipping to change at page 23, line 17
concept of a container file is not embedded in the protocol. concept of a container file is not embedded in the protocol.
However, RTSP servers may offer aggregate control on the media However, RTSP servers may offer aggregate control on the media
streams within these files. streams within these files.
Continuous media: Data where there is a timing relationship between Continuous media: Data where there is a timing relationship between
source and sink; that is, the sink needs to reproduce the timing source and sink; that is, the sink needs to reproduce the timing
relationship that existed at the source. The most common examples relationship that existed at the source. The most common examples
of continuous media are audio and motion video. Continuous media of continuous media are audio and motion video. Continuous media
can be real-time (interactive or conversational), where there is a can be real-time (interactive or conversational), where there is a
"tight" timing relationship between source and sink, or streaming "tight" timing relationship between source and sink, or streaming
(playback), where the relationship is less strict. where the relationship is less strict.
Feature-tag: A tag representing a certain set of functionality, i.e. Feature-tag: A tag representing a certain set of functionality, i.e.
a feature. a feature.
IRI: Internationalized Resource Identifier, is the same as an URI, IRI: Internationalized Resource Identifier, is the same as an URI,
with the exception that it allows characters from the whole with the exception that it allows characters from the whole
Universal Character Set (Unicode/ISO 10646), rather than the US- Universal Character Set (Unicode/ISO 10646), rather than the US-
ASCII only. See [RFC3987] for more information. ASCII only. See [RFC3987] for more information.
Live: Normally used to describe a presentation or session with media Live: Normally used to describe a presentation or session with media
skipping to change at page 24, line 39 skipping to change at page 23, line 39
session having an unbound or only loosely defined duration, and session having an unbound or only loosely defined duration, and
sometimes no seek operations are possible. sometimes no seek operations are possible.
Media initialization: Datatype/codec specific initialization. This Media initialization: Datatype/codec specific initialization. This
includes such things as clock rates, color tables, etc. Any includes such things as clock rates, color tables, etc. Any
transport-independent information which is required by a client transport-independent information which is required by a client
for playback of a media stream occurs in the media initialization for playback of a media stream occurs in the media initialization
phase of stream setup. phase of stream setup.
Media parameter: Parameter specific to a media type that may be Media parameter: Parameter specific to a media type that may be
changed before or during stream playback. changed before or during stream delivery.
Media server: The server providing playback services for one or more Media server: The server providing media delivery services for one
media streams. Different media streams within a presentation may or more media streams. Different media streams within a
originate from different media servers. A media server may reside presentation may originate from different media servers. A media
on the same host or on a different host from which the server may reside on the same host or on a different host from
presentation is invoked. which the presentation is invoked.
(Media) stream: A single media instance, e.g., an audio stream or a (Media) stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 20 and transmitted over a connection or a connectionless Section 20 and transmitted over a connection or a connectionless
transport. A message is either a Request or a Response. transport. A message is either a Request or a Response.
Message Body: The information transferred as the payload of a Message Body: The information transferred as the payload of a
message. A message body consists of meta-information in the form message (Request and response). A message body consists of meta-
of message-header and content in the form of an message-body, as information in the form of message-header and content in the form
described in Section 9. of an message-body, as described in Section 9.
Non-Aggregated Control: Control of a single media stream. Non-Aggregated Control: Control of a single media stream.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
description as defined below. Presentations with more than one description as defined below. Presentations with more than one
media stream are often handled in RTSP under aggregate control. media stream are often handled in RTSP under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a presentation, information about one or more media streams within a presentation,
skipping to change at page 29, line 28 skipping to change at page 28, line 28
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be used This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of any arbitrary length but with a Session identifiers are strings of length 8-128 characters. A
minimum length of 8 characters. A session identifier MUST be chosen session identifier MUST be chosen cryptographically random (see
cryptographically random (see [RFC4086]) and MUST be at least 8 [RFC4086]) . It is RECOMMENDED that it contains 128 bits of entropy,
characters long (can contain a maximum of 48 bits of entropy) to make i.e. approximately 22 characters from a high quality generator. (see
guessing it more difficult. It is RECOMMENDED that it contains 128 Section 21.) However, note that the session identifier does not
bits of entropy, i.e. approximately 22 characters from a high quality provide any security against session hijacking unless it is kept
generator. (see Section 21.) However, it needs to be noted that the confidential between client, server and trusted proxies.
session identifier does not provide any security against session
hijacking unless it is kept confidential between 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
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default SMPTE format with the origin at the start of the clip. The default SMPTE format
skipping to change at page 30, line 21 skipping to change at page 29, line 18
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) [RFC1305]. The timestamp with the Network Time Protocol (NTP) [RFC1305]. The timestamp
consists of a decimal fraction. The part left of the decimal may be consists of two parts: the mandatory first part may be expressed in
expressed in either seconds or hours, minutes, and seconds. The part either seconds or hours, minutes, and seconds. The optional second
right of the decimal point measures fractions of a second. part consists of a decimal point and decimal figures and indicates
fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. values are not defined.
The special constant "now" is defined as the current instant of a The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events, and MUST NOT be live event. It MAY only be used for live events, and MUST NOT be
used for on-demand (i.e., non-live) content. used for on-demand (i.e., non-live) content.
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
(high 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
skipping to change at page 31, line 41 skipping to change at page 30, line 41
The usage of feature-tags is further described in Section 11 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
4.8. Message Body Tags 4.8. Message Body Tags
Message body tags are opaque strings that are used to compare two Message body tags are opaque strings that are used to compare two
message bodies from the same resource, for example in caches or to message bodies from the same resource, for example in caches or to
optimize setup after a redirect. Message body tags can be carried in optimize setup after a redirect. Message body tags can be carried in
the MTag header (see Section 16.30) or in SDP (see Appendix D.1.9). the MTag header (see Section 16.30) or in SDP (see Appendix D.1.9).
MTag is similar to ETag in HTTP/1.1.
A message body tag MUST be unique across all versions of all message A message body tag MUST be unique across all versions of all message
bodies associated with a particular resource. A given message body bodies associated with a particular resource. A given message body
tag value MAY be used for message body obtained by requests on tag value MAY be used for message body obtained by requests on
different URIs. The use of the same message body tag value in different URIs. The use of the same message body tag value in
conjunction with message bodies obtained by requests on different conjunction with message bodies obtained by requests on different
URIs does not imply the equivalence of those message bodies URIs does not imply the equivalence of those message bodies
Message body tags are used in RTSP to make some methods conditional. Message body tags are used in RTSP to make some methods conditional.
The methods are made conditional through the inclusion of headers, The methods are made conditional through the inclusion of headers,
see Section 16.23 and Section 16.25. Note that RTSP message body see Section 16.23 and Section 16.25. Note that RTSP message body
tags apply to the complete presentation; i.e., both the session tags apply to the complete presentation; i.e., both the session
description and the individual media streams. Thus message body tags description and the individual media streams. Thus message body tags
can be used to verify at setup time after a redirect that the same can be used to verify at setup time after a redirect that the same
session description applies to the media at the new location using session description applies to the media at the new location using
the If-Match header. the If-Match header.
4.9. Media Properties 4.9. Media Properties
When RTSP handles media, it is important to consider the different When an RTSP server handles media, it is important to consider the
properties a media instance for playback can have. This different properties a media instance for delivery and playback can
specification considers the below listed media properties in its have. This specification considers the below listed media properties
protocol operations. They are derived from the differences between a in its protocol operations. They are derived from the differences
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 are 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,
within the media, i.e., randomly access any range of the media i.e. request any range, within the media.
stream to playback.
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 where a media setup for the RTSP session. The main example is a content
playlist determines the content of the session. defined by a playlist-specified.
Live: Live media represents a progressing content stream (such as Live: Live media represents a progressing content stream (such as
broadcast TV) where the duration may or may not be known. It is broadcast TV) where the duration may or may not be known. It is
not seekable, only the content presently being delivered can be not seekable, only the content presently being delivered can be
accessed. accessed.
Live with Recording: A Live stream that is combined with a server Live with Recording: A Live stream that is combined with a server
side capability to store and retain the content of the live side capability to store and retain the content of the live
session for random access playback within the part of the already session for random access delivery within the part of the already
recorded content. The actual behavior of the media stream is very recorded content. The actual behavior of the media stream is very
much depending on the retention policy for the media stream. much depending on the retention policy for the media stream.
Either the server will be able to capture the complete media Either the server will be able to capture the complete media
stream, or it will have a limitation in how much will be retained. stream, or it will have a limitation in how much will be retained.
The media range will dynamically change as the session progress. The media range will dynamically change as the session progress.
For servers with a limited amount of storage available for For servers with a limited amount of storage available for
recording, there will be a sliding window that goes forwards while recording, there will typically be a sliding window that goes
data is made available and content that is older than the forwards while data is made available and content that is older
limitation will be discarded. than a limit will be discarded.
Considering the above usages one get the following media properties To cover the above usages, the following media properties with
and their different instance values. appropriate values are specified:
4.9.1. Random Access 4.9.1. Random Access and Seeking
Random Access, i.e. if one can request that the playback point is Random Access is about the possibility to specify and get media
moved from one point in the media duration to another. The following delivered from any point inside the content, an operation called
different values are considered: seeking. This possiblity is signalled using Seek-Style which can
take the following different values:
Random Access: Yes the media are seekable to any out of a large Random Access: The media are seekable to any out of a large number
number of points within the media. Due to media encoding of points within the media. Due to media encoding limitations, a
limitations a particular point may not be reachable, but seeking particular point may not be reachable, but seeking to a point
to a point close by is enabled. A floating point number of close by is enabled. A floating point number of seconds may be
seconds may be provided to express the worst case distance between provided to express the worst case distance between random access
random access points. points.
Return To Start: Seeking is only possible to beginning of the Return To Start: Seeking is only possible to beginning of the
content. content.
No seeking: Seeking is not possible at all. No seeking: Seeking is not possible at all.
4.9.2. Retention 4.9.2. Retention
Media may have different retention policy in place that affect the Media may have different retention policy in place that affect the
operation on the media. The following different media retention operation on the media. The following different media retention
skipping to change at page 35, line 34 skipping to change at page 34, line 34
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
5.1. Message Types 5.1. Message Types
RTSP messages consist of requests from client to server, or server to RTSP messages consist of requests from client to server, or server to
client, and responses in the reverse direction. Request ( client, and responses in the reverse direction. Request (
(Section 7) ) and Response (Section 8) messages use the generic (Section 7) ) and Response (Section 8) messages uses a format based
message format of RFC 822 [RFC0822] for transferring entities (the on the generic message format of RFC 0822 [RFC0822] for transferring
payload of the message). Both types of message consist of a start- bodies (the payload of the message). Both types of message consist
line, zero or more header fields (also known as "headers"), an empty of a start-line, zero or more header fields (also known as
line (i.e., a line with nothing preceding the CRLF) indicating the "headers"), an empty line (i.e., a line with nothing preceding the
end of the header, and possibly a message-body. CRLF) indicating the end of the header, and possibly the data of the
message-body.
generic-message = start-line generic-message = start-line
*(message-header CRLF) *(message-header CRLF)
CRLF CRLF
[ message-body ] [ message-body-data ]
start-line = Request-Line | Status-Line start-line = Request-Line | Status-Line
In the interest of robustness, servers SHOULD ignore any empty In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, line(s) received where a Request-Line is expected. In other words,
if the server is reading the protocol stream at the beginning of a if the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF. message and receives a CRLF first, it should ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
RTSP header fields (see Section 16) include general-header, request- RTSP header fields (see Section 16) include general-header, request-
skipping to change at page 36, line 48 skipping to change at page 35, line 48
Protocol (SDP). Protocol (SDP).
The presence of a message-body in either a request or a response MUST The presence of a message-body in either a request or a response MUST
be signaled by the inclusion of a Content-Length header (see be signaled by the inclusion of a Content-Length header (see
Section 16.16). Section 16.16).
The presence of a message-body in a request is signaled by the The presence of a message-body in a request is signaled by the
inclusion of a Content-Length header field in the RTSP message. A inclusion of a Content-Length header field in the RTSP message. A
message-body MUST NOT be included in a request or response if the message-body MUST NOT be included in a request or response if the
specification of the particular method (see Method Definitions specification of the particular method (see Method Definitions
(Section 13)) does not allow sending an message body. A server (Section 13)) does not allow sending a message body. A server SHOULD
SHOULD read and forward a message-body on any request; if the request read and forward a message-body on any request; if the request method
method does not include defined semantics for a message body, then does not include defined semantics for a message body, then the
the message-body SHOULD be ignored when handling the request. message-body SHOULD be ignored when handling the request.
5.4. Message Length 5.4. Message Length
When a message body is included with a message, the length of that When a message body is included with a message, the length of that
body is determined by one of the following (in order of precedence): body is determined by one of the following (in order of precedence):
1. Any response message which MUST NOT include a message body (such 1. Any response message which MUST NOT include a message body (such
as the 1xx, 204, and 304 responses) is always terminated by the as the 1xx, 204, and 304 responses) is always terminated by the
first empty line after the header fields, regardless of the first empty line after the header fields, regardless of the
message-header fields present in the message. (Note: An empty message-header fields present in the message. (Note: An empty
skipping to change at page 42, line 10 skipping to change at page 41, line 10
| If-None-Match | Section 16.25 | | If-None-Match | Section 16.25 |
| | | | | |
| Notify-Reason | Section 16.31 | | Notify-Reason | Section 16.31 |
| | | | | |
| Proxy-Require | Section 16.35 | | Proxy-Require | Section 16.35 |
| | | | | |
| Range | Section 16.38 | | Range | Section 16.38 |
| | | | | |
| Terminate-Reason | Section 16.50 | | Terminate-Reason | Section 16.50 |
| | | | | |
| Referer | Section 16.39 | | Referrer | Section 16.39 |
| | | | | |
| Request-Status | Section 16.41 | | Request-Status | Section 16.41 |
| | | | | |
| Require | Section 16.42 | | Require | Section 16.42 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.48 | | Session | Section 16.47 |
| | | | | |
| Speed | Section 16.46 | | Speed | Section 16.48 |
| | | | | |
| Supported | Section 16.49 | | Supported | Section 16.49 |
| | | | | |
| Transport | Section 16.52 | | Transport | Section 16.52 |
| | | | | |
| User-Agent | Section 16.54 | | User-Agent | Section 16.54 |
+--------------------+--------------------+ +--------------------+--------------------+
Table 3: The RTSP request headers Table 3: The RTSP request headers
Detailed headers definition are provided in Section 16. Detailed headers definition are provided in Section 16.
New request headers may be defined. If the receiver of the request New request headers may be defined. If the receiver of the request
is required to understand the request header, the request MUST is required to understand the request header, the request MUST
include a corresponding feature tag in a Require or Proxy-Require include a corresponding feature tag in a Require or Proxy-Require
header to ensure the processing of the header. header to ensure the processing of the header.
8. Response 8. Response
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
responds with an RTSP response message. The final response is responds with an RTSP response message. Normally, there is only one,
exactly one message, and final responses are any using the response final, response. It is only for responses using the response code
code classes from the list; 2xx, 3xx, 4xx and 5xx classes. Only for class 1xx, that it is allowed to send one or more 1xx response
responses using the response code class 1xx, is it allowed to send messages prior to the final response message.
one or more 1xx response messages prior to the final response
message.
The valid response codes and the methods they can be used with are The valid response codes and the methods they can be used with are
listed in Table 4. listed in Table 4.
8.1. Status-Line 8.1. Status-Line
The first line of a Response message is the Status-Line, consisting The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and the of the protocol version followed by a numeric status code and the
textual phrase associated with the status code, with each element textual phrase associated with the status code, with each element
separated by SP characters. No CR or LF is allowed except in the separated by SP characters. No CR or LF is allowed except in the
skipping to change at page 45, line 4 skipping to change at page 43, line 49
| 301 | Moved Permanently | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 304 | Not Modified | all | | 304 | Not Modified | all |
| | | | | | | |
| 305 | Use Proxy | all | | 305 | Use Proxy | all |
| | | | | | | |
| | | | | | | |
| 400 | Bad Request | all | | 400 | Bad Request | all |
| | | |
| 401 | Unauthorized | all | | 401 | Unauthorized | all |
| | | | | | | |
| 402 | Payment Required | all | | 402 | Payment Required | all |
| | | | | | | |
| 403 | Forbidden | all | | 403 | Forbidden | all |
| | | | | | | |
| 404 | Not Found | all | | 404 | Not Found | all |
| | | | | | | |
| 405 | Method Not Allowed | all | | 405 | Method Not Allowed | all |
| | | | | | | |
skipping to change at page 47, line 30 skipping to change at page 46, line 30
| Public | Section 16.37 | | Public | Section 16.37 |
| | | | | |
| Range | Section 16.38 | | Range | Section 16.38 |
| | | | | |
| Retry-After | Section 16.40 | | Retry-After | Section 16.40 |
| | | | | |
| RTP-Info | Section 16.43 | | RTP-Info | Section 16.43 |
| | | | | |
| Scale | Section 16.44 | | Scale | Section 16.44 |
| | | | | |
| Session | Section 16.48 | | Session | Section 16.47 |
| | | | | |
| Server | Section 16.47 | | Server | Section 16.46 |
| | | | | |
| Speed | Section 16.46 | | Speed | Section 16.48 |
| | | | | |
| Transport | Section 16.52 | | Transport | Section 16.52 |
| | | | | |
| Unsupported | Section 16.53 | | Unsupported | Section 16.53 |
| | | | | |
| Vary | Section 16.55 | | Vary | Section 16.55 |
| | | | | |
| WWW-Authenticate | Section 16.57 | | WWW-Authenticate | Section 16.57 |
+------------------------+--------------------+ +------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-headers names can be extended reliably only in combination Response-headers names can be extended reliably only in combination
with a change in the protocol version. However the usage of feature- with a change in the protocol version. However, the usage of
tags in the request allows the responding party to learn the feature-tags in the request allows the responding party to learn the
capability of the receiver of the response. New or experimental capability of the receiver of the response. New or experimental
header MAY be given the semantics of response-header if all parties header MAY be given the semantics of response-header if all parties
in the communication recognize them to be response-header. in the communication recognize them to be response-header.
Unrecognized headers in responses are treated as message-headers. Unrecognized headers in responses are treated as message-headers.
9. Message Body 9. Message Body
Request and Response messages MAY transfer a message body if not Request and Response messages MAY transfer a message body, if not
otherwise restricted by the request method or response status code. otherwise restricted by the request method or response status code.
An message body consists of message-header fields and an message- The message body consists of message-body header fields and an the
body, although some responses will only include the message-headers. content data itself.
The SET_PARAMETER and GET_PARAMETER request and response, and The SET_PARAMETER and GET_PARAMETER request and response, and
DESCRIBE response MAY have an message body. All 4xx and 5xx DESCRIBE response MAY have an message body. All 4xx and 5xx
responses MAY also have an message body. responses MAY also have an message body.
In this section, both sender and recipient refer to either the client In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the message or the server, depending on who sends and who receives the message
body. body.
9.1. Message Body Header Fields 9.1. Message-Body Header Fields
message-header fields define meta-information about the message-body Message-body header fields define meta-information about the content
or, if no body is present, about the resource identified by the data in the message body. The message-body header fields are listed
request. The message body header fields are listed in Table 6. in Table 6.
+------------------+--------------------+ +------------------+--------------------+
| Header | Defined in Section | | Header | Defined in Section |
+------------------+--------------------+ +------------------+--------------------+
| Allow | Section 16.6 | | Allow | Section 16.6 |
| | | | | |
| Content-Base | Section 16.13 | | Content-Base | Section 16.13 |
| | | | | |
| Content-Encoding | Section 16.14 | | Content-Encoding | Section 16.14 |
| | | | | |
skipping to change at page 49, line 48 skipping to change at page 48, line 48
| | | | | |
| Content-Location | Section 16.17 | | Content-Location | Section 16.17 |
| | | | | |
| Content-Type | Section 16.18 | | Content-Type | Section 16.18 |
| | | | | |
| Expires | Section 16.21 | | Expires | Section 16.21 |
| | | | | |
| Last-Modified | Section 16.26 | | Last-Modified | Section 16.26 |
+------------------+--------------------+ +------------------+--------------------+
Table 6: The RTSP message body headers Table 6: The RTSP message-body headers
The extension-header mechanism allows additional message-header The extension-header mechanism allows additional message-header
fields to be defined without changing the protocol, but these fields fields to be defined without changing the protocol, but these fields
cannot be assumed to be recognizable by the recipient. Unrecognized cannot be assumed to be recognizable by the recipient. Unrecognized
header fields SHOULD be ignored by the recipient and forwarded by header fields SHOULD be ignored by the recipient and forwarded by
proxies. proxies.
9.2. Message Body 9.2. Message Body
RTSP message with an message body MUST include the Content-Type and RTSP message with an message body MUST include the Content-Type and
Content-Length headers if a message body is included. Content-Length headers. When a message body is included with a
message, the data type of that content data is determined via the
When an message body is included with a message, the data type of header fields Content-Type and Content-Encoding.
that body is determined via the header fields Content-Type and
Content-Encoding.
Content-Type specifies the media type of the underlying data. Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is compression, that are a property of the requested resource. There is
no default encoding. no default encoding.
The Content-Length of a message is the length of the message-body. The Content-Length of a message is the length of the content,
measured in bytes.
10. Connections 10. Connections
RTSP requests can be transmitted using the two different connection RTSP requests can be transmitted using the two different connection
scenarios listed below: scenarios listed below:
o persistent - a transport connection is used for several request/ o persistent - a transport connection is used for several request/
response transactions; response transactions;
o transient - a transport connection is used for a single request/ o transient - a transport connection is used for a single request/
skipping to change at page 52, line 27 skipping to change at page 51, line 27
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 be used for all transactions A persistent connection is RECOMMENDED to be used for all
between the server and client, including messages for multiple RTSP transactions between the server and client, including messages for
sessions. However a persistent connection MAY be closed after a few multiple RTSP sessions. However, a persistent connection MAY be
message exchanges. For example, a client may use a persistent closed after a few message exchanges. For example, a client may use
connection for the initial SETUP and PLAY message exchanges in a a persistent connection for the initial SETUP and PLAY message
session and then close the connection. Later, when the client wishes exchanges in a session and then close the connection. Later, when
to send a new request, such as a PAUSE for the session, a new the client wishes to send a new request, such as a PAUSE for the
connection would be opened. This connection may either be transient session, a new connection would be opened. This connection may
or persistent. either be transient or persistent.
An RTSP agent SHOULD NOT have more than one connection to the server An RTSP agent SHOULD NOT have more than one connection to the server
at any given point. If a client or proxy handles multiple RTSP at any given point. If a client or proxy handles multiple RTSP
sessions on the same server, it SHOULD use only one connection for sessions on the same server, it SHOULD use only one connection for
managing those sessions. managing those sessions.
This saves connection resources on the server. It also reduces This saves connection resources on the server. It also reduces
complexity by and enabling the server to maintain less state about complexity by and enabling the server to maintain less state about
its sessions and connections. its sessions and connections.
skipping to change at page 53, line 19 skipping to change at page 52, line 19
delivery. However, if the server queue the request it should when delivery. However, if the server queue the request it should when
adding additional requests to the queue ensure to remove older adding additional requests to the queue ensure to remove older
requests that are now redundant. requests that are now redundant.
Without a persistent connection between the client and the server, Without a persistent connection between the client and the server,
the media server has no reliable way of reaching the client. the media server has no reliable way of reaching the client.
Because the likely failure of server to client established Because the likely failure of server to client established
connections the server will not even attempt establishing any connections the server will not even attempt establishing any
connection. connection.
The client and server sending requests can be asynchronous events. The sending of client and server requests can be asynchronous events.
To avoid deadlock situations both client and server MUST be able to To avoid deadlock situations both client and server MUST be able to
send and receive requests simultaneously. As an RTSP response may be send and receive requests simultaneously. As an RTSP response may be
queue up for transmission, reception or processing behind the peer queued up for transmission, reception or processing behind the peer
RTSP agent's own requests, all RTSP agents are required to have a RTSP agent's own requests, all RTSP agents are required to have a
certain capability of handling outstanding messages. The issue is certain capability of handling outstanding messages. The issue is
that outstanding requests may timeout despite them being processed by that outstanding requests may timeout despite them being processed by
the peer due to the response is caught in the queue behind a number the peer due to the response is caught in the queue behind a number
of request that the RTSP agent is processing but that take some time of request that the RTSP agent is processing but that take some time
to complete. To avoid this problem an RTSP agent is recommended to to complete. To avoid this problem an RTSP agent is recommended to
buffer incoming messages locally so that any response messages can be buffer incoming messages locally so that any response messages can be
processed immediately upon reception. If responses are separated processed immediately upon reception. If responses are separated
from requests and directly forwarded for processing can not only the from requests and directly forwarded for processing can not only the
result be used immediately, the state associated with that result be used immediately, the state associated with that
skipping to change at page 54, line 15 skipping to change at page 53, line 15
In light of the above, it is RECOMMENDED that clients use persistent In light of the above, it is RECOMMENDED that clients use persistent
connections whenever possible. A client that supports persistent connections whenever possible. A client that supports persistent
connections MAY "pipeline" its requests (see Section 12). connections MAY "pipeline" its requests (see Section 12).
10.3. Closing Connections 10.3. Closing Connections
The client MAY close a connection at any point when no outstanding The client MAY close a connection at any point when no outstanding
request/response transactions exist for any RTSP session being request/response transactions exist for any RTSP session being
managed through the connection. The server, however, SHOULD NOT managed through the connection. The server, however, SHOULD NOT
close a connection until all RTSP sessions being managed through the close a connection until all RTSP sessions being managed through the
connection have been timed out (Section 16.48). A server SHOULD NOT connection have been timed out (Section 16.47). A server SHOULD NOT
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 get one down. 10 seconds should give the client ample opportunity to
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 15.4.25) are used for negotiating capabilities Allowed" (Section 15.4.25) are used for negotiating capabilities
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
skipping to change at page 56, line 13 skipping to change at page 55, line 13
arrive safely at the receiver. To show liveness between RTSP request arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be issued to accomplish other things, the following mechanisms can be
used, in descending order of preference: used, in descending order of preference:
RTCP: If RTP is used for media transport RTCP SHOULD be used. If RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it MUST also work RTCP is used to report transport statistics, it MUST also work
as keep alive. The server can determine the client by used as keep alive. The server can determine the client by used
network address and port together with the fact that the client network address and port together with the fact that the client
is reporting on the servers SSRC(s). A downside of using RTCP is reporting on the servers SSRC(s). A downside of using RTCP
is that it only gives statistical guarantees to reach the is that it only gives statistical guarantees to reach the
server. However that probability is so low that it can be server. However, that probability is so low that it can be
ignored in most cases. For example, a session with 60 seconds ignored in most cases. For example, a session with 60 seconds
timeout and enough bitrate assigned to RTCP messages to send a timeout and enough bitrate assigned to RTCP messages to send a
message from client to server on average every 5 seconds. That message from client to server on average every 5 seconds. That
client have for a network with 5 % packet loss, the probability client have for a network with 5 % packet loss, the probability
to fail showing liveness sign in that session within the to fail showing liveness sign in that session within the
timeout interval of 2.4*E-16. In sessions with shorter timeout timeout interval of 2.4*E-16. In sessions with shorter timeout
times, or much higher packet loss, or small RTCP bandwidths times, or much higher packet loss, or small RTCP bandwidths
SHOULD also use any of the mechanisms below. SHOULD also use any of the mechanisms below.
SET_PARAMETER: When using SET_PARAMETER for keep alive, no body SET_PARAMETER: When using SET_PARAMETER for keep alive, no body
skipping to change at page 56, line 40 skipping to change at page 55, line 40
server needs to determine the capabilities associated with the server needs to determine the capabilities associated with the
media resource to correctly populate the Public and Allow media resource to correctly populate the Public and Allow
headers. headers.
The timeout parameter MAY be included in a SETUP response, and MUST The timeout parameter MAY be included in a SETUP response, and MUST
NOT be included in requests. The server uses it to indicate to the NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of or other signs of life before closing the session due to lack of
activity (see below and Appendix B). The timeout is measured in activity (see below and Appendix B). The timeout is measured in
seconds, with a default of 60 seconds. The length of the session seconds, with a default of 60 seconds. The length of the session
timeout MUST NOT be changed in a established session. timeout MUST NOT be changed in an established session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
skipping to change at page 57, line 34 skipping to change at page 56, line 34
code indicating the method is either not implemented (501) or does code indicating the method is either not implemented (501) or does
not apply for the resource (405). The choice between the two not apply for the resource (405). The choice between the two
discovery methods depends on the requirements of the service. discovery methods depends on the requirements of the service.
Feature-Tags are defined to handle functionality additions that are Feature-Tags are defined to handle functionality additions that are
not new methods. Each feature-tag represents a certain block of not new methods. Each feature-tag represents a certain block of
functionality. The amount of functionality that a feature-tag functionality. The amount of functionality that a feature-tag
represents can vary significantly. A feature-tag can for example represents can vary significantly. A feature-tag can for example
represent the functionality a single RTSP header provides. Another represent the functionality a single RTSP header provides. Another
feature-tag can represent much more functionality, such as the feature-tag can represent much more functionality, such as the
"play.basic" feature-tag which represents the minimal playback "play.basic" feature-tag which represents the minimal media delivery
implementation. for playback implementation.
Feature-tags are used to determine whether the client, server or Feature-tags are used to determine whether the client, server or
proxy supports the functionality that is necessary to achieve the proxy supports the functionality that is necessary to achieve the
desired service. To determine support of a feature-tag, several desired service. To determine support of a feature-tag, several
different headers can be used, each explained below: different headers can be used, each explained below:
Supported: This header is used to determine the complete set of Supported: This header is used to determine the complete set of
functionality that both client and server have. The intended functionality that both client and server have. The intended
usage is to determine before one needs to use a functionality usage is to determine before one needs to use a functionality
that it is supported. It can be used in any method, however that it is supported. It can be used in any method, however,
OPTIONS is the most suitable one as it at the same time OPTIONS is the most suitable one as it at the same time
determines all methods that are implemented. When sending a determines all methods that are implemented. When sending a
request the requester declares all its capabilities by request the requester declares all its capabilities by
including all supported feature-tags. This results in that the including all supported feature-tags. This results in that the
receiver learns the requesters feature support. The receiver receiver learns the requesters feature support. The receiver
then includes its set of features in the response. then includes its set of features in the response.
Proxy-Supported: This header is used similar to the Supported Proxy-Supported: This header is used similar 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
skipping to change at page 59, line 22 skipping to change at page 58, line 22
Because of this, the responding entity MUST process the incoming Because of this, the responding entity MUST process the incoming
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same as the sending order. The processing of the
request MUST also have been finished before processing the next request MUST also have been finished before processing the next
request from the same entity. The responses MUST be sent in the request from the same entity. The responses MUST be sent in the
order the requests was processed. order the requests was processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate The major improvement is to allow all requests to setup and initiate
media playback to be pipelined after each other. This is media delivery to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (see accomplished by the utilization of the Pipelined-Requests header (see
Section 16.32). This header allows a client to request that two or Section 16.32). This header allows a client to request that two or
more requests are processed in the same RTSP session context which more requests are processed in the same RTSP session context which
the first request creates. In other words a client can request that the first request creates. In other words, a client can request that
two or more media streams are set-up and then played without needing two or more media streams are set-up and then played without needing
to wait for a single response. This speeds up the initial startup to wait for a single response. This speeds up the initial startup
time for an RTSP session with at least one RTT. time for an RTSP session with at least one RTT.
If a pipelined request builds on the successful completion of one or If a pipelined request builds on the successful completion of one or
more prior requests the requester must verify that all requests were more prior requests the requester must verify that all requests were
executed as expected. A common example will be two SETUP requests executed as expected. A common example will be two SETUP requests
and a PLAY request. In case one of the SETUP fails unexpectedly, the and a PLAY request. In case one of the SETUP fails unexpectedly, the
PLAY request can still be successfully executed. However, not as PLAY request can still be successfully executed. However, not as
expected by the requesting client as only a single media instead of expected by the requesting client as only a single media instead of
skipping to change at page 61, line 4 skipping to change at page 60, line 4
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | required | required |
| | | | | | | | | | | |
| | S -> C | | required | required | | | S -> C | | required | required |
+---------------+-----------+--------+--------------+---------------+ +---------------+-----------+--------+--------------+---------------+
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Respond, (P: presentation, S: stream) they operate on. Legend: R=Respond,
Sd=Send, Opt: Optional, Req: Required Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GET_PARAMETER is optional, but SET_PARAMETER is Note on Table 7: GET_PARAMETER is recommended, but not required.
required due to its usage for keep-alive. PAUSE is now required For example, a fully functional server can be built to deliver
due to that it is the only way of getting out of the state media without any parameters. SET_PARAMETER is required, however,
machines play state without terminating the whole session. due to its usage for keep-alive. PAUSE is now required due to
that it is the only way of getting out of the state machines play
state without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
An RTSP proxy who's main function is to log or audit and not modify An RTSP proxy who's main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note, the proxy still needs to perform the minimal unknown methods. Note, the proxy still needs to perform the minimal
required processing, like adding the Via header. required processing, like adding the Via header.
13.1. OPTIONS 13.1. OPTIONS
skipping to change at page 62, line 7 skipping to change at page 61, line 8
included in the response to enumerate the set of methods that are included in the response to enumerate the set of methods that are
allowed for that resource unless the set of methods completely allowed for that resource unless the set of methods completely
matches the set in the Public header. If the given resource is not matches the set in the Public header. If the given resource is not
available, the RTSP agent SHOULD return an appropriate response code available, the RTSP agent SHOULD return an appropriate response code
such as 3rr or 4xx. The Supported header MAY be included in the such as 3rr or 4xx. The Supported header MAY be included in the
request to query the set of features that are supported by the request to query the set of features that are supported by the
responding RTSP agent. responding RTSP agent.
The OPTIONS method can be used to keep an RTSP session alive. The OPTIONS method can be used to keep an RTSP session alive.
However, it is not the preferred means of session keep-alive However, it is not the preferred means of session keep-alive
signalling, see Section 16.48. An OPTIONS request intended for signalling, see Section 16.47. An OPTIONS request intended for
keeping alive an RTSP session MUST include the Session header with keeping alive an RTSP session MUST include the Session header with
the associated session ID. Such a request SHOULD also use the media the associated session ID. Such a request SHOULD also use the media
or the aggregated control URI as the Request-URI. or the aggregated control URI as the Request-URI.
Example: Example:
C->S: OPTIONS * RTSP/2.0 C->S: OPTIONS * RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: Require:
skipping to change at page 63, line 25 skipping to change at page 62, line 25
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 358 Content-Length: 358
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=recvonly
a=control:* a=control:*
t=2873397496 2873404696 t=2873397496 2873404696
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=control:audio a=control:audio
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
a=control:video a=control:video
The DESCRIBE response SHOULD contain all media initialization The DESCRIBE response SHOULD contain all media initialization
information for the resource(s) that it describes. Servers SHOULD information for the resource(s) that it describes. Servers SHOULD
NOT use the DESCRIBE response as a means of media indirection by NOT use the DESCRIBE response as a means of media indirection by
skipping to change at page 64, line 4 skipping to change at page 63, line 4
avoided that might have resulted from other approaches. avoided that might have resulted from other approaches.
Media initialization is a requirement for any RTSP-based system, but Media initialization is a requirement for any RTSP-based system, but
the RTSP specification does not dictate that this is required to be the RTSP specification does not dictate that this is required to be
done via the DESCRIBE method. There are three ways that an RTSP done via the DESCRIBE method. There are three ways that an RTSP
client may receive initialization information: client may receive initialization information:
o via an RTSP DESCRIBE request o via an RTSP DESCRIBE request
o via some other protocol (HTTP, email attachment, etc.) o via some other protocol (HTTP, email attachment, etc.)
o via some form of a user interface o via some form of user interface
If a client obtains a valid description from an alternate source, the If a client obtains a valid description from an alternate source, the
client MAY use this description for initialization purposes without client MAY use this description for initialization purposes without
issuing a DESCRIBE request for the same media. issuing a DESCRIBE request for the same media.
It is RECOMMENDED that minimal servers support the DESCRIBE method, It is RECOMMENDED that minimal servers support the DESCRIBE method,
and highly recommended that minimal clients support the ability to and highly recommended that minimal clients support the ability to
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
skipping to change at page 66, line 25 skipping to change at page 65, line 25
The server MUST generate a session identifier in response to a The server MUST generate a session identifier in response to a
successful SETUP request, unless a SETUP request to a server includes successful SETUP request, unless a SETUP request to a server includes
a session identifier, in which case the server MUST bundle this setup a session identifier, in which case the server MUST bundle this setup
request into the existing session (aggregated session) or return request into the existing session (aggregated session) or return
error 459 (Aggregate Operation Not Allowed) (see Section 15.4.24). error 459 (Aggregate Operation Not Allowed) (see Section 15.4.24).
An Aggregate control URI MUST be used to control an aggregated An Aggregate control URI MUST be used to control an aggregated
session. This URI MUST be different from the stream control URIs of session. This URI MUST be different from the stream control URIs of
the individual media streams included in the aggregate. The the individual media streams included in the aggregate. The
Aggregate control URI is to be specified by the session description Aggregate control URI is to be specified by the session description
if the server supports aggregated control and aggregated control is if the server supports aggregated control and aggregated control is
desired for the session. However even if aggregated control is desired for the session. However, even if aggregated control is
offered the client MAY chose to not set up the session in aggregated offered the client MAY chose to not set up the session in aggregated
control. If an Aggregate control URI is not specified in the session control. If an Aggregate control URI is not specified in the session
description, it is normally an indication that non-aggregated control description, it is normally an indication that non-aggregated control
should be used. The SETUP of media streams in an aggregate which has should be used. The SETUP of media streams in an aggregate which has
not been given an aggregated control URI is unspecified. not been given an aggregated control URI is unspecified.
While the session ID sometimes carries enough information for While the session ID sometimes carries enough information for
aggregate control of a session, the Aggregate control URI is still aggregate control of a session, the Aggregate control URI is still
important for some methods such as SET_PARAMETER where the control important for some methods such as SET_PARAMETER where the control
URI enables the resource in question to be easily identified. The URI enables the resource in question to be easily identified. The
skipping to change at page 66, line 47 skipping to change at page 65, line 47
route the request to the appropriate server, and for logging, route the request to the appropriate server, and for logging,
where it is useful to note the actual resource that a request was where it is useful to note the actual resource that a request was
operating on. operating on.
A session will exist until it is either removed by a TEARDOWN request A session will exist until it is either removed by a TEARDOWN request
or is timed-out by the server. The server MAY remove a session that or is timed-out by the server. The server MAY remove a session that
has not demonstrated liveness signs from the client(s) within a has not demonstrated liveness signs from the client(s) within a
certain timeout period. The default timeout value is 60 seconds; the certain timeout period. The default timeout value is 60 seconds; the
server MAY set this to a different value and indicate so in the server MAY set this to a different value and indicate so in the
timeout field of the Session header in the SETUP response. For timeout field of the Session header in the SETUP response. For
further discussion see Section 16.48. Signs of liveness for an RTSP further discussion see Section 16.47. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client(s) which includes a Session header o Any RTSP request from a client(s) which includes a Session header
with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media streams, an o If RTP is used as a transport for the underlying media streams, an
RTCP sender or receiver report from the client(s) for any of the RTCP sender or receiver report from the client(s) for any of the
media streams in that RTSP session. RTCP Sender Reports may for media streams in that RTSP session. RTCP Sender Reports may for
example be received in sessions where the server is invited into a example be received in sessions where the server is invited into a
conference session and is as valid for keep-alive. conference session and is as valid for keep-alive.
skipping to change at page 67, line 33 skipping to change at page 66, line 33
application layer mobility and flexibility to utilize the best application layer mobility and flexibility to utilize the best
available transport as it becomes available. If a client receives a available transport as it becomes available. If a client receives a
455 when trying to change transport parameters while the server is in 455 when trying to change transport parameters while the server is in
play state, it MAY try to put the server in ready state using PAUSE, play state, it MAY try to put the server in ready state using PAUSE,
before issuing the SETUP request again. If also that fails the before issuing the SETUP request again. If also that fails the
changing of transport parameters will require that the client changing of transport parameters will require that the client
performs a TEARDOWN of the affected media and then setting it up performs a TEARDOWN of the affected media and then setting it up
again. In aggregated session avoiding tearing down all the media at again. In aggregated session avoiding tearing down all the media at
the same time will avoid the creation of a new session. the same time will avoid the creation of a new session.
All transport parameters MAY be changed. However the primary usage All transport parameters MAY be changed. However, the primary usage
expected is to either change transport protocol completely, like expected is to either change transport protocol completely, like
switching from Interleaved TCP mode to UDP or vise versa or change switching from Interleaved TCP mode to UDP or vice versa or change
delivery address. delivery address.
In a SETUP response for a request to change the transport parameters In a SETUP response for a request to change the transport parameters
while in Play state, the server MUST include the Range to indicate while in Play state, the server MUST include the Range to indicate
from what point the new transport parameters are used. Further, if from what point the new transport parameters are used. Further, if
RTP is used for delivery, the server MUST also include the RTP-Info RTP is used for delivery, the server MUST also include the RTP-Info
header to indicate from what timestamp and RTP sequence number the header to indicate from what timestamp and RTP sequence number the
change has taken place. If both RTP-Info and Range is included in change has taken place. If both RTP-Info and Range is included in
the response the "rtp_time" parameter and start point in the Range the response the "rtp_time" parameter and start point in the Range
header MUST be for the corresponding time, i.e. be used in the same header MUST be for the corresponding time, i.e. be used in the same
way as for PLAY to ensure the correct synchronization information is way as for PLAY to ensure the correct synchronization information is
available. available.
If the transport parameters change while in PLAY state results in a If the transport parameters change while in PLAY state results in a
change of synchronization related information, for example changing change of synchronization related information, for example changing
RTP SSRC, the server MUST provide in the SETUP response the necessary RTP SSRC, the server MUST provide in the SETUP response the necessary
synchronization information. However the server is RECOMMENDED to synchronization information. However, the server is RECOMMENDED to
avoid changing the synchronization information if possible. avoid changing the synchronization information if possible.
13.4. PLAY 13.4. PLAY
This section describes the usage of the PLAY method in general, for This section describes the usage of the PLAY method in general, for
aggregated sessions, and in different usage scenarios. aggregated sessions, and in different usage scenarios.
13.4.1. General Usage 13.4.1. General Usage
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP and which part of the media should be mechanism specified in SETUP and which part of the media should be
played out. PLAY requests are valid when the session is in READY or played out. PLAY requests are valid when the session is in READY or
PLAY states. A PLAY request MUST include a Session header to PLAY states. A PLAY request MUST include a Session header to
indicate which session the request applies to. indicate which session the request applies to.
Upon receipt of the PLAY request, the server MUST position the normal Upon receipt of the PLAY request, the server MUST position the normal
play time to the beginning of the range specified in the received play time to the beginning of the range specified in the received
Range header and delivers stream data until the end of the range if Range header and deliver stream data until the end of the range if
given, or until a new PLAY request is received, else to the end of given, or until a new PLAY request is received, else to the end of
the media is reached. If no Range header is present in the PLAY the media is reached. If no Range header is present in the PLAY
request the server shall play from current pause point until the end request the server shall play from current pause point until the end
of media. The pause point defaults at start to the beginning of the of media. The pause point defaults at session start to the beginning
media. For media that is time-progressing and has no retention, the of the media. For media that is time-progressing and has no
pause point will always be set equal to NPT "now", i.e. current retention, the pause point will always be set equal to NPT "now",
playback point. The pause point may also be set to a particular i.e. current delivery point. The pause point may also be set to a
point in the media by the PAUSE method, see Section 13.6. The pause particular point in the media by the PAUSE method, see Section 13.6.
point for media that is currently playing is equal to the current The pause point for media that is currently playing is equal to the
media position. For time-progressing media with time-limited current media position. For time-progressing media with time-limited
retention, if the pause point represents a position that is older retention, if the pause point represents a position that is older
than what is retained by the server, the pause point will be moved to than what is retained by the server, the pause point will be moved to
the oldest retained. the oldest retained.
What range values is 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 super-set of all words the valid media range for the aggregate is the union of all of
of the media components in the aggregate. If a given range value the media components in the aggregate. If a given range value points
points outside of the media, the response MUST be the 457 (Invalid outside of the media, the response MUST be the 457 (Invalid Range)
Range) error code and include the Media-Range header (Section 16.29) error code and include the Media-Range header (Section 16.29) with
with the valid range for the media. For time progressing content the valid range for the media. Except for time progressing content
where the client request a start point prior to what is retained, the where the client request a start point prior to what is retained, the
start point is adjusted to the oldest retained content. For a start start point is adjusted to the oldest retained content. For a start
point that is beyond the media front edge, i.e. beyond the current point that is beyond the media front edge, i.e. beyond the current
value for "now", the server shall adjust the start value to the value for "now", the server shall adjust the start value to the
current front edge. The Range headers end point value may point current front edge. The Range headers end point value may point
beyond the current media edge. In that case the server shall deliver beyond the current media edge. In that case, the server shall
media from the requested (and possibly adjusted) start point until deliver media from the requested (and possibly adjusted) start point
the provided end-point, or the end of the media is reached prior to until the provided end-point, or the end of the media is reached
the specified stop point. Please note that if one simply want to prior to the specified stop point. Please note that if one simply
play from a particular start point until the end of media using an want to play from a particular start point until the end of media
Range header with an implicit stop point is recommended. using an Range header with an implicit stop point is recommended.
If a client request starting playing media at the end-point either
explicitly with a Range header or implicit by having a pause point
that is at the end of the media, a 457 (Invalid Range) error MUST be
sent and include the Media-Range header (Section 16.29). Below is
specified that the Range header also must be included, and will in
the case of Ready-State carry the pause point. Note that this also
applies if the pause point or requested start point is at the
begining of the media and a Scale header (Section 16.44) is included
with a negative value (playing backwards).
For media with random access properties a client may express its For media with random access properties a client may express its
preference on which policy for start point selection the server shall preference on which policy for start point selection the server shall
use. This is done by including the Seek-Style header (Section 16.45) use. This is done by including the Seek-Style header (Section 16.45)
in the PLAY request. in the PLAY request.
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 when 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 in a Range header MUST be included. pause point MUST be included in a Range header.
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
implicit start point (e.g. "npt=-30"). When used in a PLAY request, implicit start point (e.g. "npt=-30"). When used in a PLAY request,
the server treats this as a request to start/resume playback from the the server treats this as a request to start/resume delivery from the
current pause point, ending at the end time specified in the Range current pause point, ending at the end time specified in the Range
header. If the pause point is located later than the given end 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 below example will play seconds 10 through 25. It also request The example below will play seconds 10 through 25. It also request
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
Server MUST include a "Range" header in any PLAY response, even if no Servers MUST include a "Range" header in any PLAY response, even if
Range header was present in the request. The response MUST use the no Range header was present in the request. The response MUST use
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 response. It is RECOMMENDED that NPT is used if supported the SETUP response. It is RECOMMENDED that NPT is used if supported
by the media. by the media.
For any error response to a PLAY request, the server's response For any error response to a PLAY request, the server's response
depends on the current session state. If the session is in ready depends on the current session state. If the session is in ready
state, the current pause-point is returned using Range header with state, the current pause-point is returned using Range header with
skipping to change at page 70, line 20 skipping to change at page 69, line 30
A PLAY response MAY include a header(s) carrying synchronization A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see is needed. For RTP the RTP-Info header is specified, see
Section 16.43, and used in the following example. Section 16.43, and used in the following example.
Here is a simple example for a single audio stream where the client Here is a simple example for a single audio stream where the client
requests the media starting from 3.52 seconds and to the end. The requests the media starting from 3.52 seconds and to the end. The
server sends a 200 OK response with the actual play time which is 10 server sends a 200 OK response with the actual play time which is 10
m prior (3.51) and the RTP-Info header that contains the necessary ms prior (3.51) and the RTP-Info header that contains the necessary
parameters for the RTP stack. parameters for the RTP stack.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=3.52- Range: npt=3.52-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.51-324.39 Range: npt=3.51-324.39
Seek-Style: First-Prior Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.51 S->C: RTP Packet TS=2345962545 => NPT=3.51
Duration=0.16 seconds Media duration=0.16 seconds
The server reply with the actual start point that will be delivered. The server reply with the actual start point that will be delivered.
This may differ from the requested range if alignment of the This may differ from the requested range if alignment of the
requested range to valid frame boundaries is required for the media requested range to valid frame boundaries is required for the media
source. Note that some media streams in an aggregate may need to be source. Note that some media streams in an aggregate may need to be
delivered from even earlier points. Also, some media format have a delivered from even earlier points. Also, some media format have a
very long duration per individual data unit, therefore it might be very long duration per individual data unit, therefore it might be
necessary for the client to parse the data unit, and select where to necessary for the client to parse the data unit, and select where to
start. The server shall also indicate which policy it uses for start. The server shall also indicate which policy it uses for
selecting the actual start point by including a Seek-Style header. selecting the actual start point by including a Seek-Style header.
In the following example the client receives the first media packet In the following example the client receives the first media packet
that stretches all the way up and past the requested playtime. Thus, that stretches all the way up and past the requested playtime. Thus,
it is the client's decision if to render to the user the time between it is the client's decision if to render to the user the time between
3.52 and 7.05, or to skip it. In most cases it is probably most 3.52 and 7.05, or to skip it. In most cases it is probably most
suitable to not render that time period. suitable not to render that time period.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=7.05- User-Agent: PhonyClient/1.2 Range: npt=7.05- User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
skipping to change at page 71, line 38 skipping to change at page 70, line 48
can be issued without an intervening PAUSE request. Such a request can be issued without an intervening PAUSE request. Such a request
MUST replace the current PLAY action with the new one requested, i.e. MUST replace the current PLAY action with the new one requested, i.e.
being handle the same as the request was received in ready state. In being handle the same as the request was received in ready state. In
the case the range in Range header has a implicit start time the case the range in Range header has a implicit start time
(-endtime), the server MUST continue to play from where it currently (-endtime), the server MUST continue to play from where it currently
was until the specified end point. This is useful to change end at was until the specified end point. This is useful to change end at
another point than in the previous request. another point than in the previous request.
The following example plays the whole presentation starting at SMPTE The following example plays the whole presentation starting at SMPTE
time code 0:10:20 until the end of the clip. Note: The RTP-Info time code 0:10:20 until the end of the clip. Note: The RTP-Info
headers has been broken into several lines to fit the page. headers has been broken into several lines, where following lines
start with whitespace as allowed by the syntax.
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833 CSeq: 833
Session: 12345678 Session: 12345678
Range: smpte=0:10:20- Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 833 CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
skipping to change at page 72, line 46 skipping to change at page 71, line 46
13.4.2. Aggregated Sessions 13.4.2. Aggregated Sessions
PLAY requests can operate on sessions controlling a single media and PLAY requests can operate on sessions controlling a single media and
on aggregated sessions controlling multiple media. on aggregated sessions controlling multiple media.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server MUST response with error 460 (Only Aggregate control URI. A server MUST response with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
media. The media in an aggregate MUST be played in sync. If a media. The media in an aggregate MUST be played in sync. If a
client wants individual control of the media it needs to use separate client wants individual control of the media, it needs to use
RTSP sessions for each media. separate RTSP sessions for each media.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This procedure can reduce the without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has delay from start of session establishment until media play-out has
started with one round trip time. However, a client needs to be started with one round trip time. However, a client needs to be
aware that using this procedure will result in the playout of the aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e., server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request in after the processing of all the requests prior to the PLAY request in
the pipeline. This may not be the intended one due to failure of any the pipeline. This may not be the intended one due to failure of any
of the prior requests. However, a client can easily determine this of the prior requests. However, a client can easily determine this
based on the responses from those requests. In case of failure the based on the responses from those requests. In case of failure, the
client can halt the media playout using PAUSE and try to establish client can halt the media playout using PAUSE and try to establish
the intended state again before issuing another PLAY request. the intended state again before issuing another PLAY request.
13.4.3. Updating current PLAY Requests 13.4.3. Updating current PLAY Requests
Clients can issue PLAY requests while the stream is in PLAYING state Clients can issue PLAY requests while the stream is in PLAYING state
and thus updating their request. and 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
skipping to change at page 73, line 36 skipping to change at page 72, line 36
A total replacement is signalled by having the first range A total replacement is signalled by having the first range
specification have an explicit start value, e.g. npt=45- or specification have an explicit start value, e.g. npt=45- or
npt=45-60, in which case the server stops playout at the current npt=45-60, in which case the server stops playout at the current
playout point and then starts delivering media according to the Range playout point and then starts delivering media according to the Range
header. This is equivalent to having the client first send a PAUSE header. This is equivalent to having the client first send a PAUSE
and then a new play request that isn't based on the pause point. In and then a new play request that isn't based on the pause point. In
the case of continuation the first range specifier has an implicit the case of continuation the first range specifier has an implicit
start point and a explicit stop value (Z), e.g. npt=-60, which start point and a explicit stop value (Z), e.g. npt=-60, which
indicate that it MUST convert the range specifier being played prior indicate that it MUST convert the range specifier being played prior
to this PLAY request (X to Y) into (X to Z) and continue as this was to this PLAY request (X to Y) into (X to Z) and continue as this was
the request originally played. the request originally played. If the stop point is beyond the
current delivery point, the server SHALL immediatly pause delivery.
As the request has been completed succesfully it shall be responded
with 200 ok. A PLAY-Notify with end-of-stream is also sent to
indicate the actual stop point. The pause point is set to requested
stop point.
An example of this behavior. The server has received requests to An example of this behavior. The server has received requests to
play ranges 10 to 15. If the new PLAY request arrives at the server play ranges 10 to 15. If the new PLAY request arrives at the server
4 seconds after the previous one, it will take effect while the 4 seconds after the previous one, it will take effect while the
server still plays the first range (10-15). Thus changing the server still plays the first range (10-15). Thus changing the
behavior of this range to continue to play to 25 seconds, i.e. the behavior of this range to continue to play 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
skipping to change at page 75, line 20 skipping to change at page 74, line 20
o Random-Access set to Random Access; o Random-Access set to Random Access;
o Content Modifications set to dynamic; o Content Modifications set to dynamic;
o Retention set Unlimited or Time-Limited. o Retention set Unlimited or Time-Limited.
Playing on-demand media follows the general usage as described in Playing on-demand media follows the general usage as described in
Section 13.4.1 as long as the media has not been changed. Section 13.4.1 as long as the media has not been changed.
There are ways for the client to get informed about changed of media There are ways for the client to get informed about changes of media
resources in play state, if the resource was changed. The client resources in play state. The client will receive a PLAY_NOTIFY
will receive a PLAY_NOTIFY request with Notify-Reason header set to request with Notify-Reason header set to media-properties-update (see
media-properties-update (see Section 13.5.2). The client can use the Section 13.5.2. The client can use the value of the Media-Range to
value of the Media-Range to decide further actions, if the Media- decide further actions, if the Media-Range header is present in the
Range header is present in the PLAY_NOTIFY request. The second way PLAY_NOTIFY request. The second way is that the client issues a
is that the client issues a GET_PARAMETER request without a body but GET_PARAMETER request without a body but including a Media-Range
including a Media-Range header. The 200 OK response MUST include the header. The 200 OK response MUST include the current Media-Range
current Media-Range header (see Section 16.29). header (see Section 16.29).
13.4.6. Playing Live Media 13.4.6. Playing Live Media
Live media is indicated by the content of the Media-Properties header Live media is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 16.28):
o Random-Access set to no-seeking; o Random-Access set to no-seeking;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
skipping to change at page 76, line 24 skipping to change at page 75, line 24
recording is indicated by the content of the Media-Properties header recording is indicated by the content of the Media-Properties header
in the SETUP response by (see also Section 16.28): in the SETUP response by (see also Section 16.28):
o Random-Access set to random-access; o Random-Access set to random-access;
o Content Modifications set to Time-Progressing; o Content Modifications set to Time-Progressing;
o Retention set to Time-limited or Unlimited o Retention set to Time-limited or Unlimited
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with recording Section 16.29) for this type of media. For live media with
the Range header indicates the current playback time in the media and recording, the Range header indicates the current delivery point in
the Media-Range header indicates the currently available media window the media and the Media-Range header indicates the currently
around the current time. This window can cover recorded content in available media window around the current time. This window can
the past (seen from current time in the media) or recorded content in cover recorded content in the past (seen from current time in the
the future (seen from current time in the media). The server adjusts media) or recorded content in the future (seen from current time in
the play point to the requested border of the window, if the client the media). The server adjusts the delivery point to the requested
requests a play point that is located outside the recording windows, border of the window, if the client requests a delivery point that is
e.g., if requested to far in the past, the server selects the oldest located outside the recording windows, e.g., if requested to far in
range in the recording. The considerations in Section 13.5.3 apply, the past, the server selects the oldest range in the recording. The
if a client requests playback at Scale (Section 16.44) values other considerations in Section 13.5.3 apply, if a client requests delivery
than 1.0 (Normal playback rate) while playing live media with with Scale (Section 16.44) values other than 1.0 (Normal playback
recording. rate) while deliverying live media with recording.
13.4.8. Playing Live with Time-Shift 13.4.8. Playing Live with Time-Shift
Certain media server may offer time-shift services to their clients. Certain media server may offer time-shift services to their clients.
This time shift records a fixed interval in the past, i.e., a sliding This time shift records a fixed interval in the past, i.e., a sliding
window recording mechanism, but not past this interval. Clients can window recording mechanism, but not past this interval. Clients can
randomly access the media between now and the interval. This live randomly access the media between now and the interval. This live
media with recording is indicated by the content of the Media- media with recording is indicated by the content of the Media-
Properties header in the SETUP response by (see also Section 16.28): Properties header in the SETUP response by (see also Section 16.28):
skipping to change at page 77, line 17 skipping to change at page 76, line 17
The SETUP response 200 OK MUST include the Media-Range header (see The SETUP response 200 OK MUST include the Media-Range header (see
Section 16.29) for this type of media. For live media with recording Section 16.29) for this type of media. For live media with recording
the Range header indicates the current time in the media and the the Range header indicates the current time in the media and the
Media Range indicates a window around the current time. This window Media Range indicates a window around the current time. This window
can cover recorded content in the past (seen from current time in the can cover recorded content in the past (seen from current time in the
media) or recorded content in the future (seen from current time in media) or recorded content in the future (seen from current time in
the media). The server adjusts the play point to the requested the media). The server adjusts the play point to the requested
border of the window, if the client requests a play point that is border of the window, if the client requests a play point that is
located outside the recording windows, e.g., if requested too far in located outside the recording windows, e.g., if requested too far in
the past, the server selects the oldest range in the recording. The the past, the server selects the oldest range in the recording. The
considerations in Section 13.5.3 apply, if a client requests playback considerations in Section 13.5.3 apply, if a client requests delivery
at Scale (Section 16.44) values other than 1.0 (Normal playback rate) using a Scale (Section 16.44) value other than 1.0 (Normal playback
while playing live media with time-shift. rate) while delivering live media with time-shift.
13.5. PLAY_NOTIFY 13.5. PLAY_NOTIFY
The PLAY_NOTIFY method is issued by a server to inform a client about The PLAY_NOTIFY method is issued by a server to inform a client about
an asynchronously event for a session in play state. The Session an asynchronously 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.
skipping to change at page 80, line 22 skipping to change at page 79, line 22
Media-Range: npt=0-1:37:21.394 Media-Range: npt=0-1:37:21.394
Range: npt=1:15:49.873- Range: npt=1:15:49.873-
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 854
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
13.5.3. Scale-Change 13.5.3. Scale-Change
The server may be forced to change the rate, when a client request The server may be forced to change the rate, when a client request
playback at Scale (Section 16.44) values other than 1.0 (normal delivery using a Scale (Section 16.44) value other than 1.0 (normal
playback rate). For time progressing media with some retention, i.e. playback rate). For time progressing media with some retention, i.e.
the server stores already sent content, a client requesting to play the server stores already sent content, a client requesting to play
with Scale values larger than 1 may catch up with the front end of with Scale values larger than 1 may catch up with the front end of
the media. The server will then be unable to continue to provide the media. The server will then be unable to continue to provide
with content at Scale larger than 1 as content is only made available with content at Scale larger than 1 as content is only made available
by the server at Scale=1. Another case is when Scale < 1 and the by the server at Scale=1. Another case is when Scale < 1 and the
media retention is time-duration limited. In this case the playback media retention is time-duration limited. In this case the delivery
point can reach the oldest media unit available, and further playback point can reach the oldest media unit available, and further playback
at this scale becomes impossible as there will be no media available. at this scale becomes impossible as there will be no media available.
To avoid having the client loose any media, the scale will need to be To avoid having the client loose any media, the scale will need to be
adjusted to the same rate which the media is removed from the storage adjusted to the same rate which the media is removed from the storage
buffer, commonly scale = 1.0. buffer, commonly scale = 1.0.
Another case is when the content itself consist of spliced pieces or Another case is when the content itself consist of spliced pieces or
is dynamically updated. In these cases the server may be required to is dynamically updated. In these cases the server may be required to
change from one supported scale value (different than Scale=1.0) to change from one supported scale value (different than Scale=1.0) to
another. In this case the server will pick the closest value and another. In this case the server will pick the closest value and
skipping to change at page 84, line 34 skipping to change at page 83, line 34
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
13.7. TEARDOWN 13.7. TEARDOWN
13.7.1. Client to Server 13.7.1. Client to Server
The TEARDOWN client to server request stops the stream delivery for The TEARDOWN client to server request stops the stream delivery for
the given URI, freeing the resources associated with it. A TEARDOWN the given URI, freeing the resources associated with it. A TEARDOWN
request MAY be performed on either an aggregated or a media control request MAY be performed on either an aggregated or a media control
URI. However some restrictions apply depending on the current state. URI. However, some restrictions apply depending on the current
The TEARDOWN request MUST contain a Session header indicating what state. The TEARDOWN request MUST contain a Session header indicating
session the request applies to. what session the request applies to.
A TEARDOWN using the aggregated control URI or the media URI in a A TEARDOWN using the aggregated control URI or the media URI in a
session under non-aggregated control (single media session) MAY be session under non-aggregated control (single media session) MAY be
done in any state (Ready, and Play). A successful request MUST done in any state (Ready, and Play). A successful request MUST
result in that media delivery is immediately halted and the session result in that media delivery is immediately halted and the session
state is destroyed. This MUST be indicated through the lack of a state is destroyed. This MUST be indicated through the lack of a
Session header in the response. Session header in the response.
A TEARDOWN using a media URI in an aggregated session MAY only be A TEARDOWN using a media URI in an aggregated session MAY only be
done in Ready state. Such a request only removes the indicated media done in Ready state. Such a request only removes the indicated media
skipping to change at page 85, line 21 skipping to change at page 84, line 21
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 892 CSeq: 892
Server: PhonyServer 1.0 Server: PhonyServer 1.0
13.7.2. Server to Client 13.7.2. Server to Client
The server can send TEARDOWN requests in the server to client The server can send TEARDOWN requests in the server to client
direction to indicate that the server has been forced to terminate direction to indicate that the server has been forced to terminate
the ongoing session. This may happen for several reasons such as, the ongoing session. This may happen for several reasons, such as
server maintenance without available backup, or session have been server maintenance without available backup, or that the session has
inactive for extended periods of time. The reason is provided in the been inactive for extended periods of time. The reason is provided
Terminate-Reason header (Section 16.50). in the Terminate-Reason header (Section 16.50).
When a RTSP client has maintained a RTSP session that otherwise is When a RTSP client has maintained a RTSP session that otherwise is
inactive for an extended period of time the server may reclaim the inactive for an extended period of time the server may reclaim the
resources. That is done by issuing a REDIRECT request with the resources. That is done by issuing a REDIRECT request with the
Terminate-Reason set to "Session-Timeout". This MAY be done when the Terminate-Reason set to "Session-Timeout". This MAY be done when the
client has been inactive in the RTSP session for more than one client has been inactive in the RTSP session for more than one
Session Timeout period (Section 16.48). However, the server is Session Timeout period (Section 16.47). However, the server is
RECOMMENDED to not perform this operation until an extended period of RECOMMENDED to not perform this operation until an extended period of
inactivity has passed. The time period is considered extended when inactivity has passed. The time period is considered extended when
it is 10 times the Session Timeout period. Consideration of the it is 10 times the Session Timeout period. Consideration of the
application of the server and its content should be performed when application of the server and its content should be performed when
configuring what is considered as extended periods of time. configuring what is considered as extended periods of time.
In case the server needs to stop provide service to the established In case the server needs to stop providing service to the established
sessions and their is no server to point at in a REDIRECT request sessions and their is no server to point at in a REDIRECT request
TEARDOWN shall be used to terminate the session. This method can TEARDOWN shall be used to terminate the session. This method can
also be used when non-recoverable internal errors have happened and also be used when non-recoverable internal errors have happened and
the server has no other option then to terminate the sessions. the server has no other option then to terminate the sessions.
The TEARDOWN request is normally done on the session aggregate The TEARDOWN request is normally done on the session aggregate
control URI and MUST include the following headers; Session and control URI and MUST include the following headers; Session and
Terminate-Reason headers. The request only applies to the session Terminate-Reason headers. The request only applies to the session
identified in the Session header. The server may include a message identified in the Session header. The server may include a message
to the client's user with the "user-msg" parameter. to the client's user with the "user-msg" parameter.
skipping to change at page 86, line 30 skipping to change at page 85, line 30
the original server or the redirected server. the original server or the redirected server.
13.8. GET_PARAMETER 13.8. GET_PARAMETER
The GET_PARAMETER request retrieves the value of any specified The GET_PARAMETER request retrieves the value of any specified
parameter or parameters for a presentation or stream specified in the parameter or parameters for a presentation or stream specified in the
URI. If the Session header is present in a request, the value of a URI. If the Session header is present in a request, the value of a
parameter MUST be retrieved in the specified session context. There parameter MUST be retrieved in the specified session context. There
are two ways of specifying the parameters to be retrieved. The first are two ways of specifying the parameters to be retrieved. The first
is by including headers which have been defined such that you can use is by including headers which have been defined such that you can use
them for this purpose. Header for this purpose should allow empty, them for this purpose. Headers for this purpose should allow empty,
or stripped value parts to avoid having to specify bogus data when or stripped value parts to avoid having to specify bogus data when
indicating the desire to retrieve a value. The successful completion indicating the desire to retrieve a value. The successful completion
of the request should also be evident from any filled out values in of the request should also be evident from any filled out values in
the response. The Media-Range header (Section 16.29) is one such the response. The Media-Range header (Section 16.29) is one such
header. The other is to specify a message body that lists the header. The other way is to specify a message body that lists the
parameter(s) that are desirable to retrieve. The Content-Type header parameter(s) that are desired to be retrieved. The Content-Type
(Section 16.18) is used to specify which format the message body has. header (Section 16.18) is used to specify which format the message
body has.
The headers that MAY be used for retrieving their current value using The headers that MAY be used for retrieving their current value using
GET_PARAMETER are: GET_PARAMETER are:
o Accept-Ranges o Accept-Ranges
o Media-Range o Media-Range
o Media-Properties o Media-Properties
skipping to change at page 89, line 17 skipping to change at page 88, line 17
The REDIRECT method is issued by a server to inform a client that the The REDIRECT method is issued by a server to inform a client that the
service provided will be terminated and where a corresponding service service provided will be terminated and where a corresponding service
can be provided instead. This happens for different reasons. One is can be provided instead. This happens for different reasons. One is
that the server is being administrated such that it must stop that the server is being administrated such that it must stop
providing service. Thus the client is required to connect to another providing service. Thus the client is required to connect to another
server location to access the resource indicated by the Request-URI. server location to access the resource indicated by the Request-URI.
The REDIRECT request SHALL contain a Terminate-Reason header The REDIRECT request SHALL contain a Terminate-Reason header
(Section 16.50) to inform the client of the reason for the request. (Section 16.50) to inform the client of the reason for the request.
Additional parameters related to the reason may also be included. Additional parameters related to the reason may also be included.
The intention here is to allow an 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
skipping to change at page 91, line 14 skipping to change at page 90, line 14
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 old
session is still valid except for the host address. However the 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
skipping to change at page 92, line 12 skipping to change at page 91, line 12
CSeq: 732 CSeq: 732
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
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. in
conjunction with network address translators that block RTP traffic conjunction with network address translators that block RTP traffic
over UDP, it may be necessary to interleave RTSP messages and media over UDP, it may be necessary to interleave RTSP messages and media
stream data. This interleaving should generally be avoided unless stream data. This interleaving should generally be avoided unless
necessary since it complicates client and server operation and 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. carried over TCP. Interleaved data is not allowed inside RTSP
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 (24 decimal), followed by a one-byte channel identifier, sign (24 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
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 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
skipping to change at page 92, line 39 skipping to change at page 91, line 40
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 16.52). interleaved parameter (Section 16.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 a interval containing a second channel in the indicated by including a interval containing a second channel in the
interleaved parameter of the Transport header, see Section 16.52. If interleaved parameter of the Transport header, see Section 16.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 and higher than the RTP channel. The channels are bi-directional, using
therefore RTCP traffic are sent on the second channel in both the same ChannelD in both directions, and therefore RTCP traffic are
directions. sent on the second channel in both directions.
RTCP is sometime needed for synchronization when two or more RTCP is sometime needed for synchronization when two or more
streams are interleaved in such a fashion. Also, this provides a streams are interleaved in such a fashion. Also, this provides a
convenient way to tunnel RTP/RTCP packets through the TCP control convenient way to tunnel RTP/RTCP packets through the TCP control
connection when required by the network configuration and transfer connection when required by the network configuration and transfer
them onto UDP when possible. them onto UDP when possible.
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0 C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
skipping to change at page 94, line 46 skipping to change at page 93, line 46
The notation "3rr" indicates response codes from 300 to 399 inclusive The notation "3rr" indicates response codes from 300 to 399 inclusive
which are meant for redirection. The response code 304 is excluded which are meant for redirection. The response code 304 is excluded
from this set, as it is not used for redirection. from this set, as it is not used for redirection.
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the client. Mechanisms to determine topological proximity are beyond the
scope of this specification. scope of this specification.
An 3rr code MAY be used to respond to any request. It is RECOMMENDED A 3rr code MAY be used to respond to any request. It is RECOMMENDED
that they are used if necessary before a session is established, that they are used if necessary before a session is established,
i.e., in response to DESCRIBE or SETUP. However in cases where a i.e., in response to DESCRIBE or SETUP. However, in cases where a
server is not able to send a REDIRECT request to the client, the server is not able to send a REDIRECT request to the client, the
server MAY need to resort to using 3rr responses to inform a client server MAY need to resort to using 3rr responses to inform a client
with an established session about the need for redirecting the with an established session about the need for redirecting the
session. If an 3rr response is received for a request in relation to session. If a 3rr response is received for a request in relation to
an established session, the client SHOULD send a TEARDOWN request for an established session, the client SHOULD send a TEARDOWN request for
the session, and MAY reestablish the session using the resource the session, and MAY reestablish the session using the resource
indicated by the Location. indicated by the Location.
If the Location header is used in a response it MUST contain an If the Location header is used in a response it MUST contain an
absolute URI pointing out the media resource the client is redirected absolute URI pointing out the media resource the client is redirected
to, the URI MUST NOT only contain the host name. to, the URI MUST NOT only contain the host name.
15.3.1. 301 Moved Permanently 15.3.1. 301 Moved Permanently
skipping to change at page 101, line 27 skipping to change at page 100, line 27
15.4.28. 463 Destination Prohibited 15.4.28. 463 Destination Prohibited
The data transmission channel was not established because the server The data transmission channel was not established because the server
prohibited access to the client address. This error is most likely prohibited access to the client address. This error is most likely
the result of a client attempt to redirect media traffic to another the result of a client attempt to redirect media traffic to another
destination with a dest_addr parameter in the Transport header. destination with a dest_addr parameter in the Transport header.
15.4.29. 464 Data Transport Not Ready Yet 15.4.29. 464 Data Transport Not Ready Yet
The data transmission channel to the media destination is not yet The data transmission channel to the media destination is not yet
ready for carrying data. However the responding entity still expects ready for carrying data. However, the responding entity still
that the data transmission channel will be established at this point expects that the data transmission channel will be established at
in time. Note however that this may result in a permanent failure this point in time. Note, however, that this may result in a
like 462 "Destination Unreachable". permanent failure like 462 "Destination Unreachable".
An example when this error may occur is in the case a client sends a An example when this error may occur is in the case a client sends a
PLAY request to a server prior to ensuring that the TCP connections PLAY request to a server prior to ensuring that the TCP connections
negotiated for carrying media data was successful established (In negotiated for carrying media data was successful established (In
violation of this specification). The server would use this error violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment. to the failure of completing the connection establishment.
15.4.30. 465 Notification Reason Unknown 15.4.30. 465 Notification Reason Unknown
This indicates that the client has received a PLAY_NOTIFY This indicates that the client has received a PLAY_NOTIFY
(Section 13.5) with a Notify-Reason header (Section 16.31) unknown to (Section 13.5) with a Notify-Reason header (Section 16.31) unknown to
the client. the client.
15.4.31. 470 Connection Authorization Required 15.4.31. 470 Connection Authorization Required
The secured connection attempt need user or client authorization The secured connection attempt needs user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
15.4.32. 471 Connection Credentials not accepted 15.4.32. 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
15.4.33. 472 Failure to establish secure connection 15.4.33. 472 Failure to establish secure connection
skipping to change at page 104, line 14 skipping to change at page 103, line 14
16. Header Field Definitions 16. Header Field Definitions
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body | | method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+ +---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r | | DESCRIBE | C -> S | P,S | DES | r |
| | | | | | | | | | | |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r | | GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | | | | | | | |
| OPTIONS | C -> S | P,S | OPT | | | OPTIONS | C -> S, S -> C | P,S | OPT | |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| PAUSE | C -> S | P,S | PSE | | | PAUSE | C -> S | P,S | PSE | |
| | | | | | | | | | | |
| PLAY | C -> S | P,S | PLY | | | PLAY | C -> S | P,S | PLY | |
| | | | | | | | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R | | PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | | | | | | | |
| REDIRECT | S -> C | P,S | RDR | | | REDIRECT | S -> C | P,S | RDR | |
skipping to change at page 109, line 27 skipping to change at page 108, line 27
| | | | | | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | m | m | m | | Public | 501 | admr | m | m | m | m | m | m |
| | | | | | | | | | | | | | | | | | | |
| Range | R | | - | - | - | o | - | - | | Range | R | | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Range | r | | - | - | c | m | m | - | | Range | r | | - | - | c | m | m | - |
| | | | | | | | | | | | | | | | | | | |
| Terminate-Re | R | r | - | - | - | - | - | - | | Terminate-Re | R | r | - | - | - | - | - | - |
| ason | | | | | | | | | | ason | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Referer | R | | o | o | o | o | o | o | | Referrer | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Request- | R | | - | - | - | - | - | - | | Request- | R | | - | - | - | - | - | - |
| Status | | | | | | | | | | Status | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Require | R | | o | o | o | o | o | o | | Require | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 3rr,5 | | o | o | o | - | - | - | | Retry-After | 3rr,5 | | o | o | o | - | - | - |
| | 03 | | | | | | | | | | 03 | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | o | o | o | o | o | | Retry-After | 413 | | o | o | o | o | o | o |
skipping to change at page 112, line 39 skipping to change at page 111, line 39
| | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | - | | Public | 501 | admr | m | m | m | - |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT. GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT.
+------------------+-------------+-------+-----+-----+-----+-----+ +------------------+-------------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------+-------------+-------+-----+-----+-----+-----+ +------------------+-------------+-------+-----+-----+-----+-----+
| Range | R | | - | - | o | m | | Range | R | | o | - | o | m |
| | | | | | | | | | | | | | | |
| Terminate-Reason | R | r | - | - | m | - | | Terminate-Reason | R | r | - | - | m | - |
| | | | | | | | | | | | | | | |
| Referer | R | | o | o | o | - | | Referrer | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Request-Status | R | | - | - | - | m | | Request-Status | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
| Require | R | r | o | o | o | - | | Require | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Retry-After | 3rr,413,503 | | o | o | - | - | | Retry-After | 3rr,413,503 | | o | o | - | - |
| | | | | | | | | | | | | | | |
| Retry-After | 413 | | o | o | o | o | | Retry-After | 413 | | o | o | o | o |
| Scale | | | - | - | - | c | | Scale | | | - | - | - | c |
| | | | | | | | | | | | | | | |
| Seek-Style | | | - | - | - | - | | Seek-Style | | | - | - | - | - |
| | | | | | | | | | | | | | | |
| Session | R | r | o | o | o | m | | Session | R | r | o | o | o | m |
| | | | | | | | | | | | | | | |
| Session | r | r | c | c | o | m | | Session | r | r | c | c | o | m |
| | | | | | | | | | | | | | | |
| Server | R | r | o | o | o | - | | Server | R | r | o | o | o | - |
| | | | | | | | | | | | | | | |
| Server | r | r | o | o | - | - | | Server | r | r | o | o | - | - |
| | | | | | | | | | | | | | | |
| Speed | | | - | - | - | - |
| | | | | | | |
| Supported | R | adrm | o | o | o | - | | Supported | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Supported | r | adrm | c | c | c | - | | Supported | r | adrm | c | c | c | - |
| | | | | | | | | | | | | | | |
| Timestamp | R | adrm | o | o | o | - | | Timestamp | R | adrm | o | o | o | - |
| | | | | | | | | | | | | | | |
| Timestamp | c | adrm | m | m | m | - | | Timestamp | c | adrm | m | m | m | - |
| | | | | | | | | | | | | | | |
| Unsupported | r | arm | c | c | c | - | | Unsupported | r | arm | c | c | c | - |
| | | | | | | | | | | | | | | |
skipping to change at page 116, line 24 skipping to change at page 115, line 25
Note: This use of a prefix matching rule does not imply that Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is language tags are assigned to languages in such a way that it is
always true that if a user understands a language with a certain always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case. use of prefix tags if this is the case.
The language quality factor assigned to a language-tag by the Accept- The language quality factor assigned to a language-tag by the Accept-
Language field is the quality value of the longest language- range in Language field is the quality value of the longest language- range in
the field that matches the language-tag. If no language- range in the field that matches the language-tag. If no language-range in the
the field matches the tag, the language quality factor assigned is 0. field matches the tag, the language quality factor assigned is 0. If
If no Accept-Language header is present in the request, the server no Accept-Language header is present in the request, the server
SHOULD assume that all languages are equally acceptable. If an SHOULD assume that all languages are equally acceptable. If an
Accept-Language header is present, then all languages which are Accept-Language header is present, then all languages which are
assigned a quality factor greater than 0 are acceptable. assigned a quality factor greater than 0 are acceptable.
16.5. Accept-Ranges 16.5. Accept-Ranges
The Accept-Ranges request and response-header field allows indication The Accept-Ranges request and response-header field allows indication
of the format supported in the Range header. The client MUST include of the format supported in the Range header. The client MUST include
the header in SETUP requests to indicate which formats it support to the 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
skipping to change at page 122, line 31 skipping to change at page 121, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 : : DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 : : DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16.13. Content-Base 16.13. Content-Base
The Content-Base message-header field may be used to specify the base The Content-Base message-header field may be used to specify the base
URI for resolving relative URIs within the message body. URI for resolving relative URIs within the message body.
Content-Base: rtsp://media.example.com/movie/twister Content-Base: rtsp://media.example.com/movie/twister/
If no Content-Base field is present, the base URI of an message body If no Content-Base field is present, the base URI of an message body
is defined either by its Content-Location (if that Content-Location is defined either by its Content-Location (if that Content-Location
URI is an absolute URI) or the URI used to initiate the request, in URI is an absolute URI) or the URI used to initiate the request, in
that order of precedence. Note, however, that the base URI of the that order of precedence. Note, however, that the base URI of the
contents within the message-body may be redefined within that contents within the message-body may be redefined within that
message-body. message-body.
16.14. Content-Encoding 16.14. Content-Encoding
The Content-Encoding header field is used as a modifier to the media- The Content-Encoding header field is used as a modifier to the media-
skipping to change at page 125, line 16 skipping to change at page 124, line 16
16.19. CSeq 16.19. CSeq
The CSeq general-header field specifies the sequence number for an The CSeq general-header field specifies the sequence number for an
RTSP request-response pair. This field MUST be present in all RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given requests and responses. For every RTSP request containing the given
sequence number, the corresponding response will have the same sequence number, the corresponding response will have the same
number. Any retransmitted request MUST contain the same sequence number. Any retransmitted request MUST contain the same sequence
number as the original (i.e. the sequence number is not incremented number as the original (i.e. the sequence number is not incremented
for retransmissions of the same request). For each new RTSP request for retransmissions of the same request). For each new RTSP request
the CSeq value MUST be incremented by one. The initial sequence the CSeq value MUST be incremented by one. The initial sequence
number MAY be any number, however it is RECOMMENDED to start at 0. number MAY be any number, however, it is RECOMMENDED to start at 0.
Each sequence number series is unique between each requester and Each sequence number series is unique between each requester and
responder, i.e. the client has one series for its request to a server responder, i.e. the client has one series for its request to a server
and the server has another when sending request to the client. Each and the server has another when sending request to the client. Each
requester and responder is identified with its network address. requester and responder is identified with its network address.
Proxies that aggregate several sessions on the same transport will Proxies that aggregate several sessions on the same transport will
regularly need to renumber the CSeq header field in requests and regularly need to renumber the CSeq header field in requests and
responses to fulfill the rules for the header. responses to fulfill the rules for the header.
Example: Example:
skipping to change at page 128, line 43 skipping to change at page 127, line 43
If any of the message body tags match the message body tag of the If any of the message body tags match the message body tag of the
message body that would have been returned in the response to a message body that would have been returned in the response to a
similar DESCRIBE request (without the If-None-Match header) on that similar DESCRIBE request (without the If-None-Match header) on that
resource, or if "*" is given and any current entity exists for that resource, or if "*" is given and any current entity exists for that
resource, then the server MUST NOT perform the requested method, resource, then the server MUST NOT perform the requested method,
unless required to do so because the resource's modification date unless required to do so because the resource's modification date
fails to match that supplied in an If-Modified-Since header field in fails to match that supplied in an If-Modified-Since header field in
the request. Instead, if the request method was DESCRIBE, the server the request. Instead, if the request method was DESCRIBE, the server
SHOULD respond with a 304 (Not Modified) response, including the SHOULD respond with a 304 (Not Modified) response, including the
cache- related header fields (particularly MTag) of one of the cache-related header fields (particularly MTag) of one of the message
message bodies that matched. For all other request methods, the bodies that matched. For all other request methods, the server MUST
server MUST respond with a status of 412 (Precondition Failed). respond with a status of 412 (Precondition Failed).
See Section 18.1.3 for rules on how to determine if two message body See Section 18.1.3 for rules on how to determine if two message body
tags match. tags match.
If none of the message body tags match, then the server MAY perform If none of the message body tags match, then the server MAY perform
the requested method as if the If-None-Match header field did not the requested method as if the If-None-Match header field did not
exist, but MUST also ignore any If-Modified-Since header field(s) in exist, but MUST also ignore any If-Modified-Since header field(s) in
the request. That is, if no message body tags match, then the server the request. That is, if no message body tags match, then the server
MUST NOT return a 304 (Not Modified) response. MUST NOT return a 304 (Not Modified) response.
skipping to change at page 130, line 12 skipping to change at page 129, line 12
to a location other than the Request-URI for completion of the to a location other than the Request-URI for completion of the
request or identification of a new resource. For 3xx responses, the request or identification of a new resource. For 3xx responses, the
location SHOULD indicate the server's preferred URI for automatic location SHOULD indicate the server's preferred URI for automatic
redirection to the resource. The field value consists of a single redirection to the resource. The field value consists of a single
absolute URI. absolute URI.
Note: The Content-Location header field (Section 16.17) differs from Note: The Content-Location header field (Section 16.17) differs from
Location in that the Content-Location identifies the original Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location possible for a response to contain header fields for both Location
and Content-Location. Also see Section 18.2 for cache requirements and Content-Location. Also, see Section 18.2 for cache requirements
of some methods. of some methods.
16.28. Media-Properties 16.28. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests This general header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable to to indicate the media's properties that currently are applicable to
the RTSP session. PLAY_NOTIFY MAY be used to modify these properties the RTSP session. PLAY_NOTIFY MAY be used to modify these properties
at any point. However, the client SHOULD have received the update at any point. However, the client SHOULD have received the update
prior to any action related to the new media properties take affect. prior to that any action related to the new media properties take
For aggregated sessions the Media-Properties header will be returned affect. For aggregated sessions, the Media-Properties header will be
in each SETUP response. The header received in the latest response returned in each SETUP response. The header received in the latest
is the one that applies on the whole session from this point until response is the one that applies on the whole session from this point
any future update. The header MAY be included without value in until any future update. The header MAY be included without value in
GET_PARAMETER requests to the server with a Session header included GET_PARAMETER requests to the server with a Session header included
to query the current Media-Properties for the session. The responder to query the current Media-Properties for the session. The responder
MUST include the current session's media properties. MUST include the current session's media properties.
The media properties expressed by this header is the one applicable The media properties expressed by this header is the one applicable
to all media in the RTSP session. So for aggregated sessions the to all media in the RTSP session. For aggregated sessions, the
header expressed the combined media-properties. As a result header expressed the combined media-properties. As a result
aggregation of media MAY result in a change of the media properties, aggregation of media MAY result in a change of the media properties,
and thus the content of the Media-Properties header contained in and thus the content of the Media-Properties header contained in
subsequent SETUP responses. subsequent SETUP responses.
The header contains a list of property values that are applicable to The header contains a list of property values that are applicable to
the currently setup media or aggregate of media as indicated by the the currently setup media or aggregate of media as indicated by the
RTSP URI in the request. No ordering are enforced within the header. RTSP URI in the request. No ordering are enforced within the header.
Property values should be grouped into a single group that handles a Property values should be grouped into a single group that handles a
particular orthogonal property. Values or groups that express particular orthogonal property. Values or groups that express
skipping to change at page 131, line 46 skipping to change at page 130, line 46
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. 0.0
is a valid value as this indicates that no data is retained in is a valid value as this indicates that no data is retained in
a time-progressing session. 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. A values or ranges of scale values supported by the content in
range has a start and stop value separated by a colon. A range arbitary order. A range has a start and stop value separated
indicates that the content supports fine grained selection of by a colon. A range indicates that the content supports fine
scale values. Fine grained allows for steps at least as small grained selection of scale values. Fine grained allows for
as one tenth of a scale value. Negative values are supported. steps at least as small as one tenth of a scale value.
The value 0 have no meaning and must not be used. Negative values are supported. The value 0 have no meaning and
must not be used.
An Example of this header for first an on-demand content and then a Examples of this header for on-demand content and a live stream
live stream without recording. 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
16.29. Media-Range 16.29. Media-Range
skipping to change at page 132, line 36 skipping to change at page 131, line 36
The header MUST include range specifications for all time formats The header MUST include range specifications for all time formats
supported for the media, as indicated in Accept-Ranges header supported for the media, as indicated in Accept-Ranges header
(Section 16.5) when setting up the media. The server MAY include (Section 16.5) when setting up the media. The server MAY include
more than one range specification of any given time format to more than one range specification of any given time format to
indicate media that has non-continuous range. indicate media that has non-continuous range.
For media that has the Time-Progressing property, the Media-Range For media that has the Time-Progressing property, the Media-Range
values will only be valid for the particular point in time when it values will only be valid for the particular point in time when it
was issued. As wallclock progresses so will also the media range. was issued. As wallclock progresses so will also the media range.
However it shall be assumed that media time progress in direct However, it shall be assumed that media time progress 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.
16.30. MTag 16.30. MTag
The MTag response header MAY be included in DESCRIBE or SETUP The MTag response header MAY be included in DESCRIBE or SETUP
responses. The message body tags (Section 4.8) returned in a responses. The message body tags (Section 4.8) returned in a
DESCRIBE response, and the one in SETUP refers to the presentation, 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 the
"a=mtag" attribute in SDP, and in the response message, then both "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 16.23) and If-None-Match ( using the headers If-Match (Section 16.23) and If-None-Match (
Section 16.25). Section 16.25).
16.31. Notify-Reason 16.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
PLAY_NOTIFY request (see Section 13.5). PLAY_NOTIFY request (see Section 13.5).
16.32. Pipelined-Requests 16.32. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by previous request is to be executed in the context created by a previous
requests. The primary usage of this header is to allow pipelining of request(s). The primary usage of this header is to allow pipelining
SETUP requests so that any additional SETUP request after the first of SETUP requests so that any additional SETUP request after the
one does not need to wait for the session ID to be sent back to the first one does not need to wait for the session ID to be sent back to
requesting entity. The header contains a unique identifier that is the requesting entity. The header contains a unique identifier that
scoped by the persistent connection used to send the requests. is scoped by the persistent connection used to send the requests.
Upon receiving a request with the Pipelined-Requests the responding Upon receiving a request with the Pipelined-Requests the responding
entity MUST look up if there exist a binding between this Pipelined- entity MUST look up if there exist a binding between this Pipelined-
Requests identifier for the current persistent connection and an RTSP Requests identifier for the current persistent connection and an RTSP
session ID. If that exists then the received request is processed session ID. If that exists then the received request is processed
the same way as if it did contain the Session header with the looked the same way as if it did contain the Session header with the looked
up session ID. If there doesn't exist a mapping and no Session up session ID. If there doesn't exist a mapping and no Session
header is included in the request, the responding entity MUST create header is included in the request, the responding entity MUST create
a binding upon the successful completion of a session creating a binding upon the successful completion of a session creating
request, i.e. SETUP. If the request failed to create an RTSP request, i.e. SETUP. If the request failed to create an RTSP
skipping to change at page 134, line 5 skipping to change at page 133, line 5
both a Session header and the Pipelined-Requests header the both a Session header and the Pipelined-Requests header the
Pipelined-Requests MUST be ignored. Pipelined-Requests MUST be ignored.
Note: Based on the above definition at least the first request Note: Based on the above definition at least the first request
containing a new unique Pipelined-Requests will be required to be a containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may include the or request of any type using the RTSP session context may include the
Pipelined-Requests header. Pipelined-Requests header.
For all responses to request that contained the Pipelined-Requests, When responding to any request that contained the Pipelined-Requests
the Session header and the Pipelined-Requests MUST both be included, header the server MUST include also the Session header when a binding
assuming that it is allowed for that response and that the binding to a session context exist. A RTSP agent that knows the session ID
between the header values exist. Pipelined-Requests SHOULD NOT be SHOULD NOT use the Pipelined-Requests header in any request and only
used in requests after that the client has received the RTSP Session use the Session header. This as the Session identifier is persistent
ID. This as using the real session ID allows the request to be used across transport contexts, like TCP connections, which the Pipelined-
also in cases the persistent connection has been terminated and a new Requests identifier is not.
connection is needed.
It is the sender of the request that is responsible for using a It is the RTSP agent sending the request with a Pipelined-Requests
previously unused identifier within this transport connection scope header that has the responsibility for using a unique and previously
when a new RTSP session is to be created with this method. A server unused identifier within the the transport context. Currently only
side binding MUST be deleted upon the termination of the related RTSP TCP connection is defined as such transport context. A server MUST
session. Note: Although this definition would allow for reusing delete the Pipelined-Requests identifier and its binding to a session
previously used pipelining identifiers, this is NOT RECOMMENDED to upon the termination of that session. RTSP agents are RECOMMENDED to
allow for better error handling and logging. despite the previous mandate to no reuse identifiers to allow for
better error handling and logging.
RTSP Proxies may need to translate Pipelined-Requests identifier RTSP Proxies may need to translate Pipelined-Requests identifier
values from incoming request to outgoing to allow for aggregation of values from incoming request to outgoing to allow for aggregation of
requests onto a persistent connection. requests onto a persistent connection.
16.33. Proxy-Authenticate 16.33. Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and consists of a challenge that indicates the authentication scheme and
skipping to change at page 137, line 10 skipping to change at page 136, line 10
proxy. Modification of the Public response header field by the proxy. Modification of the Public response header field by the
intervening proxies ensures that the request sender gets an intervening proxies ensures that the request sender gets an
accurate response indicating the methods that can be used on the accurate response indicating the methods that can be used on the
target agent via the proxy chain. target agent via the proxy chain.
16.38. Range 16.38. Range
The Range header specifies a time range in PLAY (Section 13.4), PAUSE The Range header specifies a time range in PLAY (Section 13.4), PAUSE
(Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and
PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be
included in GET_PARAMETER request from he client to the server with included in GET_PARAMETER requests from the client to the server with
only a Range format and no value to request the current media only a Range format and no value to request the current media
position independent if the session is in playing or ready state in position, whether the session is in playing or ready state in the
the included format. The server SHALL if supporting that range included format. The server SHALL, if supporting the range format,
format respond with the current playing point or pause point as the respond with the current playing point or pause point as the start of
start of the range. If an explicit stop point was used in the the range. If an explicit stop point was used in the previous PLAY
previous PLAY request, then that value shall be included as stop request, then that value shall be included as stop point. Note that
point. Note that if the server is currently under any type of media if the server is currently under any type of media playback
playback manipulation affecting the interpretation of Range, like manipulation affecting the interpretation of Range, like Scale, that
Scale, that is also required to be included in any GET_PARAMETER is also required to be included in any GET_PARAMETER response to
response to provide complete information. provide complete information.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines smpte (Section 4.4), npt (Section 4.5), and clock defines smpte (Section 4.4), npt (Section 4.5), and clock
(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
skipping to change at page 138, line 46 skipping to change at page 137, line 46
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-0 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.
16.39. Referer 16.39. Referrer
The Referer 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
the Request-URI was obtained (the "referrer", although the header the Request-URI was obtained. The URI refers to that of the
field is misspelled.) The URI refers to that of the presentation presentation description, typically retrieved via HTTP. The Referrer
description, typically retrieved via HTTP. The Referer request- request-header allows a server to generate lists of back-links to
header allows a server to generate lists of back-links to resources resources for interest, logging, optimized caching, etc. It also
for interest, logging, optimized caching, etc. It also allows allows obsolete or mistyped links to be traced for maintenance. The
obsolete or mistyped links to be traced for maintenance. The Referer Referrer field MUST NOT be sent if the Request-URI was obtained from
field MUST NOT be sent if the Request-URI was obtained from a source a source that does not have its own URI, such as input from the user
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.
See [H15.1.3] for security considerations on Referer. See [H15.1.3] for security considerations on Referrer.
16.40. Retry-After 16.40. Retry-After
The Retry-After response-header field can be used with a 503 (Service The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. The user-agent is asked wait before issuing the redirected request. The
value of this field can be either an RTSP-date or an integer number value of this field can be either an RTSP-date or an integer number
of seconds (in decimal) after the time of the response. of seconds (in decimal) after the time of the response.
skipping to change at page 139, line 38 skipping to change at page 138, line 38
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
16.41. Request-Status 16.41. 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
how the PLAY request concluded, either in success or in failure. The how the PLAY request concluded, either in success or in failure. The
header carries a reference to the request is reports on using the header carries a reference to the request it reports on using the
CSeq number for the session indicated by the Session header in the CSeq number for the session indicated by the Session header in the
request. It provides both a numerical status code (according to request. It provides both a numerical status code (according to
Section 8.1.1) and a human readable reason phrase. Section 8.1.1) and a human readable reason phrase.
Example: Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable" Request-Status: cseq=63 status=500 reason="Media data unavailable"
16.42. Require 16.42. Require
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however the use of the other end-point supports certain features, however, the use of the
Supported (Section 16.49) is much more effective in this purpose. Supported (Section 16.49) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response MUST use the error code 551 (Option Not supported. The response MUST use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see Proxy-Require header functionality in respect to proxies see Proxy-Require header
(Section 16.35) with the exception of media modifying proxies. Media (Section 16.35) with the exception of media modifying proxies. Media
modifying proxies due to their nature of handling media in a way that modifying proxies due to their nature of handling media in a way that
is very similar to what a server, do need to understand also the is very similar to what a server, do need to understand also the
server features to correctly serve the client. server features to correctly serve the client.
skipping to change at page 141, line 17 skipping to change at page 140, line 17
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
synchronize the media streams using RTCP. This may have negative synchronize the media streams using RTCP. This may have negative
impact as the RTCP can be lost, and does not need to be impact as the RTCP can be lost, and does not need to be
particularly timely in their arrival. Also functionality as particularly timely in their arrival. Also functionality as
informing the client from which packet a seek has occurred is informing the client from which packet a seek has occurred is
affected. affected.
The RTP-Info MAY be included in SETUP responses to provide The RTP-Info MAY be included in SETUP responses to provide
synchronization information when changing transport parameters, see synchronization information when changing transport parameters, see
Section 13.3. The RTP-Info header MAY also be included in Section 13.3. The RTP-Info header and the Range header MAY be
GET_PARAMETER requests from client to server without any value to included in a GET_PARAMETER request from client to server without any
indicate a request for this information. In such a case the Range values to request the current playback point and corresponding.RTP
header MUST also be included in the request. The server SHALL synchronization information. When the RTP-Info header is included in
respond if the session is in playing state with the Range header a Request also the Range header MUST be included (Note, Range header
filled in with the current playback point and with the corresponding only MAY be used). The server respons SHALL include both the Range
RTP-Info values. header and the RTP-Info header. If the session is in playing state,
then the value of the Range header SHALL be filled in with the
current playback point and with the corresponding RTP-Info values.
If the server is another state, no values are included in the RTP-
Info header.
The header can carry the following parameters: The header can carry the following parameters:
url: Indicates the stream URI which for which the following RTP url: Indicates the stream URI which for which the following RTP
parameters correspond, this URI MUST be the same used in the parameters correspond, this URI MUST be the same used in the
SETUP request for this media stream. Any relative URI MUST use SETUP request for this media stream. Any relative URI MUST use
the Request-URI as base URI. This parameter MUST be present. the Request-URI as base URI. This parameter MUST be present.
ssrc: The Synchronization source (SSRC) that the RTP timestamp and ssrc: The Synchronization source (SSRC) that the RTP timestamp and
sequence number provide applies to. This parameter MUST be sequence number provide applies to. This parameter MUST be
skipping to change at page 142, line 51 skipping to change at page 142, line 13
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32 corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
16.44. Scale 16.44. Scale
A scale value of 1 indicates normal play at the normal forward A scale value of 1 indicates normal play at the normal forward
viewing rate. If not 1, the value corresponds to the rate with viewing rate. If not 1, the value corresponds to the rate with
respect to normal viewing rate. For example, a ratio of 2 indicates respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate ("fast forward") and a ratio of 0.5 twice the normal viewing rate ("fast forward") and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 indicates half the normal viewing rate. In other words, a ratio of 2
has content time increase at twice the playback time. For every has content time increase at twice the playback time. For every
second of elapsed (wallclock) time, 2 seconds of content will be second of elapsed (wallclock) time, 2 seconds of content time will be
delivered. A negative value indicates reverse direction. For delivered. A negative value indicates reverse direction. For
certain media transports this may require certain considerations to certain media transports this may require certain considerations to
work consistent, see Appendix C.1 for description on how RTP handles work consistent, see Appendix C.1 for description on how RTP handles
this. this.
The transmitted data rate SHOULD NOT be changed by selection of a The transmitted data rate SHOULD NOT be changed by selection of a
different scale value. The resulting bit-rate should be in different scale value. The resulting bit-rate should be reasonably
reasonably close to the nominal bit-rate of the content for Scale = close to the nominal bit-rate of the content for Scale = 1. The
1. The server has to actively manipulate the data when needed to server has to actively manipulate the data when needed to meet the
meet the bitrate constraints. Implementation of scale changes bitrate constraints. Implementation of scale changes depends on the
depends on the server and media type. For video, a server may, for server and media type. For video, a server may, for example, deliver
example, deliver only key frames or selected key frames. For audio, only key frames or selected key frames. For audio, it may time-scale
for example, it may time-scale the audio while preserving pitch or, the audio while preserving pitch or, less desirably, deliver
less desirably, deliver fragments of audio, or completely mute the fragments of audio, or completely mute the audio.
audio.
The server and content may restrict the range of scale values that it The server and content may restrict the range of scale values that it
supports. The supported values are indicated by the Media-Properties supports. The supported values are indicated by the Media-Properties
header (Section 16.28). The client SHOULD only indicate values header (Section 16.28). The client SHOULD only indicate values
indicated to be supported. However, as the values may change as the indicated to be supported. However, as the values may change as the
content progresses a requested value may no longer be valid when the content progresses a requested value may no longer be valid when the
request arrives. Thus an non-supported value in a request does not request arrives. Thus, a non-supported value in a request does not
generate an error, only forces the server to choose the closest generate an error, only forces the server to choose the closest
value. The response MUST always contain the actual scale value value. The response MUST always contain the actual scale value
chosen by the server. chosen by the server.
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
skipping to change at page 145, line 5 skipping to change at page 144, line 13
startup time or the media quality. The "Next" policy breaks the startup time or the media quality. The "Next" policy breaks the
normal definition of the Range header to enable a client to request normal definition of the Range header to enable a client to request
media with minimal overlap, although some may still occur for media with minimal overlap, although some may still occur for
aggregated sessions. RAP and First-Prior both fulfill the aggregated sessions. RAP and First-Prior both fulfill the
requirement of providing media from the requested range and forward. requirement of providing media from the requested range and forward.
However, unless RAP is used, the media quality for many media codecs However, unless RAP is used, the media quality for many media codecs
using predictive methods can be severely degraded unless additional using predictive methods can be severely degraded unless additional
data is available as, for example, already buffered, or through other data is available as, for example, already buffered, or through other
side channels. side channels.
16.46. Speed 16.46. Server
The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to
be within a given range with an upper and lower bound. The server
SHALL delivery at the highest possible speed within the range, but
not faster than the upper-bound, for which the underlying network
path can support the resulting transport data rates. As long as any
speed value within the given range can be provided the server SHALL
NOT modify the media quality. Only if the server is unable to
delivery media at the speed value provided by the lower bound shall
it reduce the media quality.
Implementation of the Speed functionality by the server is OPTIONAL.
The server can indicate its support through a feature-tag,
play.scale. The lack of a Speed header in the response is an
indication of lack of support of this functionality.
The speed parameter values are expressed as a positive decimal value,
e.g., a value of 2.0 indicates that data is to be delivered twice as
fast as normal. A speed value of zero is invalid. The range is
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
be possible to support. Therefore the server MAY modify the
requested values to the closest supported. The actual supported
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,
0.3-2.0, 1.0-2.5, 2.5-2.5 all has their usage.
Example:
Speed: 1.0 - 2.5
Use of this header changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where delivery of the
presentation at a higher or lower rate is desired. The main use
cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server
can react and adapt to the available bitrate.
16.47. Server
The Server response-header field contains information about the The Server response-header field contains information about the
software used by the origin server to handle the request. The field software used by the origin server to handle the request. The field
can contain multiple product tokens and comments identifying the can contain multiple product tokens and comments identifying the
server and any significant subproducts. The product tokens are server and any significant subproducts. The product tokens are
listed in order of their significance for identifying the listed in order of their significance for identifying the
application. application.
Example: Example:
Server: PhonyServer/1.0 Server: PhonyServer/1.0
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (Section 16.56). SHOULD include a Via field (Section 16.56).
16.48. Session 16.47. Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result RTSP session. An RTSP session is created by the server as a result
of a successful SETUP request and in the response the session of a successful SETUP request and in the response the session
identifier is given to the client. The RTSP session exist until identifier is given to the client. The RTSP session exist until
destroyed by a TEARDOWN, REDIRECT or timed out by the server. destroyed by a TEARDOWN, REDIRECT or timed out by the server.
The session identifier is chosen by the server (see Section 4.3) and The session identifier is chosen by the server (see Section 4.3) and
MUST be returned in the SETUP response. Once a client receives a MUST be returned in the SETUP response. Once a client receives a
session identifier, it MUST be included in any request related to session identifier, it MUST be included in any request related to
skipping to change at page 147, line 6 skipping to change at page 145, line 19
The session identifier is needed to distinguish several delivery The session identifier is needed to distinguish several delivery
requests for the same URI coming from the same client. requests for the same URI coming from the same client.
The response 454 (Session Not Found) MUST be returned if the session The response 454 (Session Not Found) MUST be returned if the session
identifier is invalid. identifier is invalid.
The header MAY include the session timeout period. If not explicitly The header MAY include the session timeout period. If not explicitly
provided this value is set to 60 seconds. As this affects how often provided this value is set to 60 seconds. As this affects how often
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 that 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 to frequent keep-alive messages and having low sensitivity in not to 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.
16.48. Speed
The Speed request-header field requests the server to deliver
specific amounts of nominal media time per unit of delivery time,
contingent on the server's ability and desire to serve the media
stream at the given speed. The client requests the delivery speed to
be within a given range with an upper and lower bound. The server
SHALL deliver at the highest possible speed within the range, but not
faster than the upper-bound, for which the underlying network path
can support the resulting transport data rates. As long as any speed
value within the given range can be provided the server SHALL NOT
modify the media quality. Only if the server is unable to delivery
media at the speed value provided by the lower bound shall it reduce
the media quality.
Implementation of the Speed functionality by the server is OPTIONAL.
The server can indicate its support through a feature-tag,
play.speed. The lack of a Speed header in the response is an
indication of lack of support of this functionality.
The speed parameter values are expressed as a positive decimal value,
e.g., a value of 2.0 indicates that data is to be delivered twice as
fast as normal. A speed value of zero is invalid. The range is
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
be possible to support. Therefore the server MAY modify the
requested values to the closest supported. The actual supported
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,
0.3-2.0, 1.0-2.5, 2.5-2.5 all have their usage.
Example:
Speed: 1.0 - 2.5
Use of this header changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where delivery of the
presentation at a higher or lower rate is desired. The main use
cases are buffer operations or local scale operations. Implementors
should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. To perform Speed operations the server needs to
ensure that the network path can support the resulting bit-rate.
Thus the media transport needs to support feedback so that the server
can react and adapt to the available bitrate.
16.49. Supported 16.49. Supported
The Supported header enumerates all the extensions supported by the The Supported header enumerates all the extensions supported by the
client or server using feature tags. The header carries the client or server using feature tags. The header carries the
extensions supported by the message sending entity. The Supported extensions supported by the message sending entity. The Supported
header MAY be included in any request. When present in a request, header MAY be included in any request. When present in a request,
the receiver MUST respond with its corresponding Supported header. the receiver MUST respond with its corresponding Supported header.
Note, also in 4xx and 5xx responses is the supported header included. Note that the supported headers is also included in 4xx and 5xx
responses.
The Supported header contains a list of feature-tags, described in The Supported header contains a list of feature-tags, described in
Section 4.7, that are understood by the client or server. Section 4.7, that are understood by the client or server.
Example: Example:
C->S: OPTIONS rtsp://example.com/ RTSP/2.0 C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech Supported: foo, bar, blech
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 148, line 47 skipping to change at page 148, line 9
destination address, compression, multicast time-to-live and destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
A Transport request header MAY contain a list of transport options A Transport request header MAY contain a list of transport options
acceptable to the client, in the form of multiple transport acceptable to the client, in the form of multiple transport
specification entries. Transport specifications are comma separated, specification entries. Transport specifications are comma separated,
listed in decreasing order of preference. Parameters may be added to listed in decreasing order of preference. Parameters may be added to
each transport specification, separated by a semicolon. The server each transport specification, separated by a semicolon. The server
MUST return a Transport response-header in the response to indicate MUST return a Transport response-header in the response to indicate
the values actually chosen if any. If not transport specification is the values actually chosen if any. If the transport specification is
supported no transport header is returned and the request MUST be not supported, no transport header is returned and the request MUST
responded using the status code 461 (Unsupported Transport) be responded using the status code 461 (Unsupported Transport)
(Section 15.4.26). In case more than one transport specification was (Section 15.4.26). In case more than one transport specification was
present in the request, the server MUST return the single (transport- present in the request, the server MUST return the single (transport-
spec) which was actually chosen if any. The number of transport-spec spec) which was actually chosen, if any. The number of transport-
entries is expected to be limited as the client will get guidance on spec entries is expected to be limited as the client will get
what configurations that are possible from the presentation guidance on what configurations that are possible from the
description. presentation description.
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.
skipping to change at page 152, line 17 skipping to change at page 151, line 24
which address and port to send so called "binding packets" from which address and port to send so called "binding packets" from
the receiver to the sender, thus creating a address binding in the receiver to the sender, thus creating a address binding in
the NAT that the sender to receiver packet flow can use. the NAT that the sender to receiver packet flow can use.
This information may also be available through SDP. This information may also be available through SDP.
However, since this is more a feature of transport than However, since this is more a feature of transport than
media initialization, the authoritative source for this media initialization, the authoritative source for this
information should be in the SETUP response. information should be in the SETUP response.
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not this session. Valid values are "PLAY" and "RECORD". If not
provided, the default is PLAY. The RECORD value was defined in provided, the default is "PLAY". The "RECORD" value was
RFC 2326 and is in this specification unspecified but reserved. defined in RFC 2326 and is in this specification unspecified
but reserved.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
used by the control stream, using the mechanism defined in used by the control stream, using the mechanism defined in
Section 14. The argument provides the channel number to be Section 14. The argument provides the channel number to be
used in the $ statement and MUST be present. This parameter used in the $ statement and MUST be present. This parameter
MAY be specified as a interval, e.g., interleaved=4-5 in cases MAY be specified as a interval, e.g., interleaved=4-5 in cases
where the transport choice for the media stream requires it, where the transport choice for the media stream requires it,
e.g. for RTP with RTCP. The channel number given in the e.g. for RTP with RTCP. The channel number given in the
request are only a guidance from the client to the server on request are only a guidance from the client to the server on
skipping to change at page 152, line 48 skipping to change at page 152, line 10
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live for IPv4. When included in requests the ttl: multicast time-to-live for IPv4. When included in requests the
value indicate the TTL value that the client request the server value indicate the TTL value that the client request the server
to use. In a response, the value actually being used by the to use. In a response, the value actually being used by the
server is returned. A server will need to consider what values server is returned. A server will need to consider what values
that are reasonable and also the authority of the user to set that are reasonable and also the authority of the user to set
this value. Corresponding function are not needed for IPv6 as this value. Corresponding functions are not needed for IPv6 as
the scoping is part of the address. the scoping is part of the address.
RTP-specific: RTP-specific:
These parameters are MAY only be used if the media transport protocol These parameters are MAY only be used if the media transport protocol
is RTP. is RTP.
ssrc: The ssrc parameter, if included in a SETUP response, indicates ssrc: The ssrc parameter, if included in a SETUP response, indicates
the RTP SSRC [RFC3550] value(s) that will be used by the media the RTP SSRC [RFC3550] value(s) that will be used by the media
server for RTP packets within the stream. It is expressed as server for RTP packets within the stream. It is expressed as
skipping to change at page 153, line 24 skipping to change at page 152, line 32
The ssrc parameter MUST NOT be specified in requests. The The ssrc parameter MUST NOT be specified in requests. The
functionality of specifying the ssrc parameter in a SETUP functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550[RFC3550]. If the parameter is specification of RTP in RFC 3550[RFC3550]. If the parameter is
included in the Transport header of a SETUP request, the server included in the Transport header of a SETUP request, the server
MAY ignore it, and choose appropriate SSRCs for the stream. MAY ignore it, and choose appropriate SSRCs for the stream.
The server MAY set the ssrc parameter in the Transport header The server MAY set the ssrc parameter in the Transport header
of the response. of the response.
The parameters defined below MAY only be used if the media transport The parameters setup and connection defined below MAY only be used if
protocol of the lower-level transport is connection-oriented (such as the media transport protocol of the lower-level transport is
TCP). However, these parameters MUST NOT be used when interleaving connection-oriented (such as TCP). However, these parameters MUST
data over the RTSP control connection. NOT be used when interleaving data over the RTSP control connection.
The third parameter, RTCP-mux, can be used also in the interleaved
mode.
setup: Clients use the setup parameter on the Transport line in a setup: Clients use the setup parameter on the Transport line in a
SETUP request, to indicate the roles it wishes to play in a TCP SETUP request, to indicate the roles it wishes to play in a TCP
connection. This parameter is adapted from [RFC4145]. We connection. This parameter is adapted from [RFC4145]. We
discuss the use of this parameter in RTP/AVP/TCP non- discuss the use of this parameter in RTP/AVP/TCP non-
interleaved transport in Appendix C.2.2; the discussion below interleaved transport in Appendix C.2.2; the discussion below
is limited to syntactic issues. Clients may specify the is limited to syntactic issues. Clients may specify the
following values for the setup parameter: ["active":] The following values for the setup parameter: ["active":] The
client will initiate an outgoing connection. ["passive":] The client will initiate an outgoing connection. ["passive":] The
client will accept an incoming connection. ["actpass":] The client will accept an incoming connection. ["actpass":] The
skipping to change at page 158, line 51 skipping to change at page 157, line 51
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy request that the firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client in necessary pinholes in the firewall is opened when a client in
the protected network want to access media streams on the the protected network want to access media streams on the
external side. This proxy can also limit the clients access to external side. This proxy can also limit the clients access to
certain type of content. This proxy can perform its function certain type of content. This proxy can perform its function
without redirecting the media between the server and client. without redirecting the media between the server and client.
However, in deployments with private address spaces this proxy However, in deployments with private address spaces this proxy
is likely to be combined with the access proxy. Anyway, the is likely to be combined with the access proxy. Anyway, the
functionality of this proxy is usually closely tied into functionality of this proxy is usually closely tied into
understand all aspects of how the media transport. understand all aspects of the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that tracks their employees usage of the network. corporations that tracks their employees usage of the network.
This type of proxy can perform its function without inserting This type of proxy can perform its function without inserting
itself or any other node in the media transport. This proxy itself or any other node in the media transport. This proxy
type can also accept unknown methods as it doesn't interfere type can also accept unknown methods as it doesn't interfere
with the clients requests. with the clients requests.
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificate chains with TLS as RTSP 2.0 allows the client to approve certificate chains
used for connection establishment from a proxy, see Section 19.3.2. used for connection establishment from a proxy, see Section 19.3.2.
However that trust model may not be suitable for all type of However, that trust model may not be suitable for all type of
deployment, and instead secured sessions do by-pass of the proxies. deployment, and instead secured sessions do by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters etc may fail in a proxy that protocols or profiles, new parameters etc may fail in a proxy that
isn't maintained. Thus resulting in blocking further development of isn't maintained. Thus resulting in blocking further development of
skipping to change at page 159, line 48 skipping to change at page 158, line 48
feature-tag representing the functionality needs to be included in feature-tag representing the functionality needs to be included in
the Proxy-Require header. Below are guidelines for analysis if the the Proxy-Require header. Below are guidelines for analysis if the
header needs to be understood. The transport header and its header needs to be understood. The transport header and its
parameters also shows that headers that are extensible and requires parameters also shows that headers that are extensible and requires
correct interpretation in the proxy also requires handling rules. correct interpretation in the proxy also requires handling rules.
When defining a new RTSP header it needs to be considered if RTSP When defining a new RTSP header it needs to be considered if RTSP
proxies are required to understand them to achieve correct proxies are required to understand them to achieve correct
functionality. Determining this is not easy as the functionality for functionality. Determining this is not easy as the functionality for
proxies are widely varied as can be understood from the above list of proxies are widely varied as can be understood from the above list of
functionality. When evaluating this one can dived the functionality functionality. When evaluating this, one can divide the
into three main categories: functionality into three main categories:
Media modifying: The caching and translator proxies are modifying Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request the actual media and therefore needs to understand also request
directed to the server that affects how the media is rendered. directed to the server that affects how the media is rendered.
Thus this type of proxies needs to also understand the server side Thus, this type of proxies needs to also understand the server
functionality. side functionality.
Transport modifying: The access and the security proxy both need to Transport modifying: The access and the security proxy both need to
understand the how the transport is performed, either for opening understand how the transport is performed, either for opening
pinholes or to translate the outer headers, e.g. IP and UDP. pinholes or to translate the outer headers, e.g. IP and UDP.
Non-modifying: The audit proxy is special in that it do not modify Non-modifying: The audit proxy is special in that it do not modify
the messages in other ways than to insert the Via header. That the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP message that makes it possible for this type to forward RTSP message that
contains different type of unknown methods, headers or header contains different type of unknown methods, headers or header
parameters. parameters.
Based on the above classification one should evaluate if ones Based on the above classification, one should evaluate if the new
functionality requires the Transport modifying type of proxies to functionality requires the Transport modifying type of proxies to
understand it or not. understand it or not.
18. Caching 18. Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
skipping to change at page 161, line 26 skipping to change at page 160, line 26
On receiving a SETUP or PLAY request, a proxy ascertains whether it On receiving a SETUP or PLAY request, a proxy ascertains whether it
has an up-to-date copy of the continuous media content and its has an up-to-date copy of the continuous media content and its
description. It can determine whether the copy is up-to-date by description. It can determine whether the copy is up-to-date by
issuing a SETUP or DESCRIBE request, respectively, and comparing the issuing a SETUP or DESCRIBE request, respectively, and comparing the
Last-Modified header with that of the cached copy. If the copy is Last-Modified header with that of the cached copy. If the copy is
not up-to-date, it modifies the SETUP transport parameters as not up-to-date, it modifies the SETUP transport parameters as
appropriate and forwards the request to the origin server. appropriate and forwards the request to the origin server.
Subsequent control commands such as PLAY or PAUSE then pass the proxy Subsequent control commands such as PLAY or PAUSE then pass the proxy
unmodified. The proxy delivers the continuous media data to the unmodified. The proxy delivers the continuous media data to the
client, while possibly making a local copy for later reuse. The client, while possibly making a local copy for later reuse. The
exact behavior allowed to the cache is given by the cache-response exact allowed behavior of the cache is given by the cache-response
directives described in Section 16.10. A cache MUST answer any directives described in Section 16.10. A cache MUST answer any
DESCRIBE requests if it is currently serving the stream to the DESCRIBE requests if it is currently serving the stream to the
requester, as it is possible that low-level details of the stream requester, as it is possible that low-level details of the stream
description may have changed on the origin-server. description may have changed on the origin-server.
Note that an RTSP cache, unlike the HTTP cache, is of the "cut- Note that an RTSP cache, unlike the HTTP cache, is of the "cut-
through" variety. Rather than retrieving the whole resource from the through" variety. Rather than retrieving the whole resource from the
origin server, the cache simply copies the streaming data as it origin server, the cache simply copies the streaming data as it
passes by on its way to the client. Thus, it does not introduce passes by on its way to the client. Thus, it does not introduce
additional latency. additional latency.
skipping to change at page 169, line 48 skipping to change at page 168, line 48
the "rtsp" URI), and the policy for the resource requires a secure the "rtsp" URI), and the policy for the resource requires a secure
channel, the server MUST redirect the client to the secure service by channel, the server MUST redirect the client to the secure service by
sending a 301 redirect response code together with the correct sending a 301 redirect response code together with the correct
Location URI (using the "rtsps" scheme). A user or client MAY Location URI (using the "rtsps" scheme). A user or client MAY
upgrade a non secured URI to a secured by changing the scheme from upgrade a non secured URI to a secured by changing the scheme from
"rtsp" to "rtsps". A server implementing support for "rtsps" MUST "rtsp" to "rtsps". A server implementing support for "rtsps" MUST
allow this. allow this.
It should be noted that TLS allows for mutual authentication (when It should be noted that TLS allows for mutual authentication (when
using both server and client certificates). Still, one of the more using both server and client certificates). Still, one of the more
common way TLS is used is to only provide server side authentication common ways TLS is used is to only provide server side authentication
(often to avoid client certificates). TLS is then used in addition (often to avoid client certificates). TLS is then used in addition
to HTTP authentication, providing transport security and server to HTTP authentication, providing transport security and server
authentication, while HTTP Authentication is used to authenticate the authentication, while HTTP Authentication is used to authenticate the
client. client.
RTSP includes the possibility to keep a TCP session up between the RTSP includes the possibility to keep a TCP session up between the
client and server, throughout the RTSP session lifetime. It may be client and server, throughout the RTSP session lifetime. It may be
convenient to keep the TCP session, not only to save the extra setup convenient to keep the TCP session, not only to save the extra setup
time for TCP, but also the extra setup time for TLS (even if TLS uses time for TCP, but also the extra setup time for TLS (even if TLS uses
the resume function, there will be almost two extra round trips). the resume function, there will be almost two extra round trips).
skipping to change at page 171, line 20 skipping to change at page 170, line 20
Section 16.2) is used, where the client can force the proxy/proxies Section 16.2) is used, where the client can force the proxy/proxies
to relay back the chain of certificates used to authenticate any to relay back the chain of certificates used to authenticate any
intermediate proxies as well as the server. Given the assumption intermediate proxies as well as the server. Given the assumption
that the proxies are viewed as trusted, it gives the user a that the proxies are viewed as trusted, it gives the user a
possibility to enforce policies to each trusted proxy of whether it possibility to enforce policies to each trusted proxy of whether it
should accept the next entity in the chain. should accept the next entity in the chain.
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 does not require to use it. The proxy MUST when and the end server are not require 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
suits that the proxy does not support. In case a proxy fails to suits 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
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
skipping to change at page 172, line 22 skipping to change at page 171, line 22
the messages is long). the messages is long).
With the "Any" and "Proxy" methods the proxy will apply the policy as With the "Any" and "Proxy" methods the proxy will apply the policy as
defined for respectively method. If the policy does not accept the defined for respectively method. If the policy does not accept the
credentials of the next hop, the entity MUST respond with a message credentials of the next hop, the entity MUST respond with a message
using status code 471 (Connection Credentials not accepted). using status code 471 (Connection Credentials not accepted).
An RTSP request in the direction server to client MUST NOT include An RTSP request in the direction server to client MUST NOT include
the Accept-Credential header. As for the non-secured communication, the Accept-Credential header. As for the non-secured communication,
the possibility for these requests depends on the presence of a the possibility for these requests depends on the presence of a
client established connection. However if the server to client client established connection. However, if the server to client
request is in relation to a session established over a TLS secured request is in relation to a session established over a TLS secured
channel, it MUST be sent in a TLS secured connection. That secured channel, it MUST be sent in a TLS secured connection. That secured
connection MUST also be the one used by the last client to server connection MUST also be the one used by the last client to server
request. If no such transport connection exist at the time when the request. If no such transport connection exist at the time when the
server desires to send the request, it silently fails. server desires to send the request, the server discard the message.
Further policies MAY be defined and registered, but should be done so Further policies MAY be defined and registered, but should be done so
with caution. with caution.
19.3.2. User approved TLS procedure 19.3.2. User approved TLS procedure
For the "User" method each proxy MUST perform the following procedure For the "User" method, each proxy MUST perform the following
for each RTSP request: procedure for each RTSP request:
o Setup the TLS session to the next hop if not already present (i.e. o Setup the TLS session to the next hop if not already present (i.e.
run the TLS handshake, but do not send the RTSP request). run the TLS handshake, but do not send the RTSP request).
o Extract the peer certificate chain for the TLS session. o Extract the peer certificate chain for the TLS session.
o Check if a matching identity and hash of the peer certificate is o Check if a matching identity and hash of the peer certificate is
present in the Accept-Credentials header. If present, send the present in the Accept-Credentials header. If present, send the
message to the next hop, and conclude these procedures. If not, message to the next hop, and conclude these procedures. If not,
go to the next step. go to the next step.
skipping to change at page 173, line 46 skipping to change at page 172, line 46
"192.0.2.5:4589" "192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org";sha-256; Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4= dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
One implication of this process is that the connection for secured One implication of this process is that the connection for secured
RTSP messages may take significantly more round-trip times for the RTSP messages may take significantly more round-trip times for the
first message. An complete extra message exchange between the proxy first message. An complete extra message exchange between the proxy
connecting to the next hop and the client results because of the connecting to the next hop and the client results because of the
process for approval for each hop. However after the first message process for approval for each hop. However, after the first message
exchange the remaining message should not be delayed, if each message exchange the remaining message should not be delayed, if each message
contains the chain of proxies that the requester accepts. The contains the chain of proxies that the requester accepts. The
procedure of including the credentials in each request rather than procedure of including the credentials in each request rather than
building state in each proxy, avoids the need for revocation building state in each proxy, avoids the need for revocation
procedures. procedures.
20. Syntax 20. Syntax
The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF)
as defined in RFC 5234 [RFC5234]. It uses the basic definitions as defined in RFC 5234 [RFC5234]. It uses the basic definitions
skipping to change at page 175, line 4 skipping to change at page 174, line 4
DIGIT = %x30-39 ; any US-ASCII digit "0".."9" DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127) ; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13 CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10) LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32) SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9) HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQ = %x22 ; US-ASCII double-quote mark (34) DQ = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92) BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) LWS = [CRLF] 1*( SP / HT ) ; Line-breaking White Space
SWS = [LWS] ; sep whitespace SWS = [LWS] ; Separating White Space
HCOLON = *( SP / HT ) ":" SWS HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@" tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQ / "," / ";" / ":" / BACKSLASH / DQ
/ "/" / "[" / "]" / "?" / "=" / "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT / "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E) / %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials> ; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQ *qdtext DQ ) quoted-string = ( DQ *qdtext DQ )
skipping to change at page 175, line 29 skipping to change at page 174, line 29
/ %x80-FF ; any OCTET except CTLs, "(" and ")" / %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ] generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string gen-value = token / host / quoted-string
safe = "$" / "-" / "_" / "." / "+" safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / "," extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")" rtsp-extra = "!" / "*" / "'" / "(" / ")"
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f" / "a" / "b" / "c" / "d" / "e" / "f"
LHEX = DIGIT / %x61-66 ;lowercase a-f LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; lowercase "a-f" Hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra
base64 = *base64-unit [base64-pad] base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=") base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/" base64-char = ALPHA / DIGIT / "+" / "/"
SLASH = SWS "/" SWS ; slash SLASH = SWS "/" SWS ; slash
skipping to change at page 176, line 25 skipping to change at page 175, line 25
LAQUOT = SWS "<" ; left angle quote LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
FLOAT = ["-"] 1*39DIGIT ["." 1*46DIGIT] FLOAT = ["-"] 1*12DIGIT ["." 1*9DIGIT]
POS-FLOAT = 1*39DIGIT ["." 1*46DIGIT] POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
20.2. RTSP Protocol Definition 20.2. RTSP Protocol Definition
20.2.1. Generic Protocol elements 20.2.1. Generic Protocol elements
RTSP-IRI = schemes ":" IRI-rest RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
skipping to change at page 180, line 11 skipping to change at page 179, line 11
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
20.2.2. Message Syntax 20.2.2. Message Syntax
RTSP-message = Request / Response ; RTSP/2.0 messages RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line Request = Request-Line
*((general-header *((general-header
/ request-header / request-header
/ message-header) CRLF) / message-header) CRLF)
CRLF CRLF
[ message-body ] [ message-body-data ]
Response = Status-Line Response = Status-Line
*((general-header *((general-header
/ response-header / response-header
/ message-header) CRLF) / message-header) CRLF)
CRLF CRLF
[ message-body ] [ message-body-data ]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" Method = "DESCRIBE"
/ "GET_PARAMETER" / "GET_PARAMETER"
/ "OPTIONS" / "OPTIONS"
/ "PAUSE" / "PAUSE"
/ "PLAY" / "PLAY"
/ "PLAY_NOTIFY" / "PLAY_NOTIFY"
skipping to change at page 180, line 40 skipping to change at page 179, line 40
/ "SETUP" / "SETUP"
/ "SET_PARAMETER" / "SET_PARAMETER"
/ "TEARDOWN" / "TEARDOWN"
/ extension-method / extension-method
extension-method = token extension-method = token
Request-URI = "*" / RTSP-REQ-URI Request-URI = "*" / RTSP-REQ-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
message-body = 1*OCTET message-body-data = 1*OCTET
Status-Code = "100" ; Continue Status-Code = "100" ; Continue
/ "200" ; OK / "200" ; OK
/ "301" ; Moved Permanently / "301" ; Moved Permanently
/ "302" ; Found / "302" ; Found
/ "303" ; See Other / "303" ; See Other
/ "304" ; Not Modified / "304" ; Not Modified
/ "305" ; Use Proxy / "305" ; Use Proxy
/ "400" ; Bad Request / "400" ; Bad Request
/ "401" ; Unauthorized / "401" ; Unauthorized
skipping to change at page 182, line 32 skipping to change at page 181, line 32
/ Authorization / Authorization
/ Bandwidth / Bandwidth
/ Blocksize / Blocksize
/ From / From
/ If-Match / If-Match
/ If-Modified-Since / If-Modified-Since
/ If-None-Match / If-None-Match
/ Notify-Reason / Notify-Reason
/ Proxy-Require / Proxy-Require
/ Range / Range
/ Referer / Referrer
/ Request-Status / Request-Status
/ Require / Require
/ Scale / Scale
/ Session / Session
/ Speed / Speed
/ Supported / Supported
/ Terminate-Reason / Terminate-Reason
/ Transport / Transport
/ User-Agent / User-Agent
/ extension-header / extension-header
skipping to change at page 187, line 18 skipping to change at page 186, line 18
/ "Dynamic" / "Dynamic"
/ "Time-Progressing" / "Time-Progressing"
/ "Unlimited" / "Unlimited"
/ ("Time-Limited" EQUAL utc-range-spec) / ("Time-Limited" EQUAL utc-range-spec)
/ ("Time-Duration" EQUAL POS-FLOAT) / ("Time-Duration" EQUAL POS-FLOAT)
/ ("Scales" EQUAL scale-value-list) / ("Scales" EQUAL scale-value-list)
/ media-prop-ext / media-prop-ext
media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)] media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)]
scale-value-list = DQ scale-entry *(COMMA scale-entry) DQ scale-value-list = DQ scale-entry *(COMMA scale-entry) DQ
scale-entry = scale-value / (scale-value COLON scale-value) scale-entry = scale-value / (scale-value COLON scale-value)
scale-value = ["-"] 1*8DIGIT ["." 1*8DIGIT] scale-value = FLOAT
Media-Range = "Media-Range" HCOLON [ranges-list] Media-Range = "Media-Range" HCOLON [ranges-list]
ranges-list = ranges-spec *(COMMA ranges-spec) ranges-list = ranges-spec *(COMMA ranges-spec)
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
skipping to change at page 188, line 40 skipping to change at page 187, line 40
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 / ":" )
Referer = "Referer" HCOLON RTSP-REQ-Ref Referrer = "Referrer" HCOLON RTSP-REQ-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 DQ Reason-Phrase DQ reason-info = "reason" EQUAL DQ Reason-Phrase DQ
Require = "Require" HCOLON feature-tag-list Require = "Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec
*(COMMA rtsp-info-spec)] *(COMMA rtsp-info-spec)]
rtsp-info-spec = stream-url 1*ssrc-parameter rtsp-info-spec = stream-url 1*ssrc-parameter
skipping to change at page 189, line 19 skipping to change at page 188, line 19
ri-parameter *(SEMI ri-parameter) ri-parameter *(SEMI ri-parameter)
ri-parameter = ("seq" EQUAL 1*DIGIT) ri-parameter = ("seq" EQUAL 1*DIGIT)
/ ("rtptime" EQUAL 1*DIGIT) / ("rtptime" EQUAL 1*DIGIT)
/ generic-param / generic-param
Retry-After = "Retry-After" HCOLON delta-seconds Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param ) [ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds) retry-param = ("duration" EQUAL delta-seconds)
/ generic-param / generic-param
Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] Scale = "Scale" HCOLON scale-value
Seek-Style = "Seek-Style" HCOLON Seek-S-values Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP" Seek-S-values = "RAP"
/ "First-Prior" / "First-Prior"
/ "Next" / "Next"
/ Seek-S-value-ext / Seek-S-value-ext
Seek-S-value-ext = token Seek-S-value-ext = token
Speed = "Speed" HCOLON POS-FLOAT MINUS POS-FLOAT Speed = "Speed" HCOLON POS-FLOAT MINUS POS-FLOAT
Server = "Server" HCOLON ( product / comment ) Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment)) *(LWS (product / comment))
product = token [SLASH product-version] product = token [SLASH product-version]
skipping to change at page 195, line 9 skipping to change at page 194, line 9
code 403 (Forbidden) upon receiving a single instance of code 403 (Forbidden) upon receiving a single instance of
behavior which is deemed a security risk. RTSP servers SHOULD behavior which is deemed a security risk. RTSP servers SHOULD
also be aware of attempts to probe the server for weaknesses also be aware of attempts to probe the server for weaknesses
and entry points and MAY arbitrarily disconnect and ignore and entry points and MAY arbitrarily disconnect and ignore
further requests clients which are deemed to be in violation of further requests clients which are deemed to be in violation of
local security policy. local security policy.
Scope of Multicast: If RTSP is used to control the transmission of Scope of Multicast: If RTSP is used to control the transmission of
media onto a multicast network it is need to consider the scope media onto a multicast network it is need to consider the scope
that delivery has. RTSP supports the TTL Transport header that delivery has. RTSP supports the TTL Transport header
parameter to indicate this scope. However such scope control parameter to indicate this scope. However, such scope control
is risk as it may be set to large and distribute media beyond is risk as it may be set to large and distribute media beyond
the intended scope. the intended scope.
TLS through proxies: If one uses the possibility to connect TLS in TLS through proxies: If one uses the possibility to connect TLS in
multiple legs (Section 19.3 one really needs to be aware of the multiple legs (Section 19.3 one really needs to be aware of the
trust model. That procedure requires full faith and trust in trust model. That procedure requires full faith and trust in
all proxies that one allows to connect through. They are man all proxies that one allows to connect through. They are man
in the middle and has access to all that goes on over the TLS in the middle and has access to all that goes on over the TLS
connection. Thus it is important to consider if that trust connection. Thus it is important to consider if that trust
model is acceptable in the actual application. model is acceptable in the actual application.
skipping to change at page 198, line 23 skipping to change at page 197, line 23
registration MUST indicate if the feature-tag applies to clients, registration MUST indicate if the feature-tag applies to clients,
servers, or proxies only or any combinations of these. Any servers, or proxies only or any combinations of these. Any
proprietary feature MUST have as the first part of the name a vendor proprietary feature MUST have as the first part of the name a vendor
tag, which identifies the organization. tag, which identifies the organization.
22.1.3. Registered entries 22.1.3. Registered entries
The following feature-tags are in this specification defined and The following feature-tags are in this specification defined and
hereby registered. The change control belongs to the IETF. hereby registered. The change control belongs to the IETF.
play.basic: The minimal implementation for playback operations play.basic: The minimal implementation for delivery and playback
according to this specification. Applies for both clients, operations according to this specification. Applies for both
servers and proxies. clients, servers and proxies.
play.scale: Support of scale operations for media playback. Applies play.scale: Support of scale operations for media playback. Applies
only for servers. only for servers.
play.speed: Support of the speed functionality for playback. play.speed: Support of the speed functionality for media delivery.
Applies only for servers. Applies only for servers.
setup.rtp.rtcp.mux Support of the RTP and RTCP multiplexing as
discussed in Appendix C.1.6.4.
22.2. RTSP Methods 22.2. RTSP Methods
22.2.1. Description 22.2.1. Description
What a method is, is described in section Section 13. Extending the What a method is, is described in section Section 13. Extending the
protocol with new methods allow for totally new functionality. protocol with new methods allow for totally new functionality.
22.2.2. Registering New Methods with IANA 22.2.2. Registering New Methods with IANA
A new method MUST be registered through an IETF Standards Action. A new method MUST be registered through an IETF Standards Action.
skipping to change at page 203, line 41 skipping to change at page 202, line 43
result of these changes. result of these changes.
22.7.3. Registered Values 22.7.3. Registered Values
This specification registers the 9 values listed in Section 16.28. This specification registers the 9 values listed in Section 16.28.
22.8. Notify-Reason header 22.8. Notify-Reason header
22.8.1. Description 22.8.1. Description
Notify-Reason values used to indicate why a notification was sent. Notify-Reason values are used for indicating the reason the
They may also imply that certain headers are required for the client notification was sent. Each reason has its associated rules on what
to act properly upon the information the notification carries. New headers and information that may or must be included in the
notification behaviors need to be described to result in notification. New notification behaviors need to be specified to
interoperable usage, thus a specification of each new value is enable interoperable usage, thus a specification of each new value is
required. required.
22.8.2. Registration Rules 22.8.2. Registration Rules
Registrations for new Notify-Reason value MUST fulfill the following Registrations for new Notify-Reason value MUST fulfill the following
requirements requirements
o Follow the Specification Required policy and get the approval of o Follow the Specification Required policy and get the approval of
the designated Expert. the designated Expert.
o Have a ABNF definition of the Notify reason value name that meets o Have a ABNF definition of the Notify reason value name that meets
"Notify-Reason-extension" definition "Notify-Reason-extension" definition
o A Contact Person for the Registration o A Contact Person for the Registration
o Description of which headers shall be included in the request and o Description of which headers shall be included in the request and
response, when it should be sent, and any effect it has on the response, when it should be sent, and any effect it has on the
skipping to change at page 206, line 13 skipping to change at page 205, line 21
This specification registers 2 parameter value pairs: This specification registers 2 parameter value pairs:
o seq o seq
o rtptime o rtptime
22.12. Seek-Style Policies 22.12. Seek-Style Policies
22.12.1. Description 22.12.1. Description
New seek policies may be registered, however a large number of these New seek policies may be registered, however, a large number of these
will complicate implementation substantially. The impact of unknown will complicate implementation substantially. The impact of unknown
policies is that the server will not honor the unknown and use the policies is that the server will not honor the unknown and use the
server default policy instead. server default policy instead.
22.12.2. Registration Rules 22.12.2. Registration Rules
Registrations of new Seek-Style polices MUST fulfill the following Registrations of new Seek-Style polices MUST fulfill the following
requirements requirements
o Follow the Specification Required policy. o Follow the Specification Required policy.
skipping to change at page 209, line 23 skipping to change at page 208, line 29
URI scheme name: rtsp URI scheme name: rtsp
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP). RTSP allows different operations on the Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However, the
operations that are currently defined are: Describing the operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving entity resource for the purpose of configuring the receiving entity
(DESCRIBE), configuring the delivery method and its addressing (DESCRIBE), configuring the delivery method and its addressing
(SETUP), controlling the delivery (PLAY and PAUSE), reading or (SETUP), controlling the delivery (PLAY and PAUSE), reading or
setting of resource related parameters (SET_PARAMETER and setting of resource related parameters (SET_PARAMETER and
GET_PARAMETER, and termination of the session context created GET_PARAMETER, and termination of the session context created
(TEARDOWN). (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and needs Encoding considerations: IRIs in this scheme are defined and needs
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
skipping to change at page 210, line 18 skipping to change at page 209, line 23
URI scheme name: rtsps URI scheme name: rtsps
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsps scheme is used to indicate resources URI scheme semantics: The rtsps scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over TLS. RTSP allows different operations on Protocol (RTSP) over TLS. RTSP allows different operations on
the resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is
the streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However,
the operations that are currently defined are: Describing the the operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving entity resource for the purpose of configuring the receiving entity
(DESCRIBE), configuring the delivery method and its addressing (DESCRIBE), configuring the delivery method and its addressing
(SETUP), controlling the delivery (PLAY and PAUSE), reading or (SETUP), controlling the delivery (PLAY and PAUSE), reading or
setting of resource related parameters (SET_PARAMETER and setting of resource related parameters (SET_PARAMETER and
GET_PARAMETER, and termination of the session context created GET_PARAMETER, and termination of the session context created
(TEARDOWN). (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and needs Encoding considerations: IRIs in this scheme are defined and needs
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
skipping to change at page 211, line 18 skipping to change at page 210, line 19
Status: Permanent Status: Permanent
URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme syntax: See Section 3.2 of RFC 2326.
URI scheme semantics: The rtspu scheme is used to indicate resources URI scheme semantics: The rtspu scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over unreliable datagram transport. RTSP Protocol (RTSP) over unreliable datagram transport. RTSP
allows different operations on the resource identified by the allows different operations on the resource identified by the
URI, but the primary purpose is the streaming delivery of the URI, but the primary purpose is the streaming delivery of the
resource to a client. However the operations that are resource to a client. However, the operations that are
currently defined are: Describing the resource for the purpose currently defined are: Describing the resource for the purpose
of configuring the receiving entity (DESCRIBE), configuring the of configuring the receiving entity (DESCRIBE), configuring the
delivery method and its addressing (SETUP), controlling the delivery method and its addressing (SETUP), controlling the
delivery (PLAY and PAUSE), reading or setting of resource delivery (PLAY and PAUSE), reading or setting of resource
related parameters (SET_PARAMETER and GET_PARAMETER, and related parameters (SET_PARAMETER and GET_PARAMETER, and
termination of the session context created (TEARDOWN). termination of the session context created (TEARDOWN).
Encoding considerations: IRIs in this scheme are defined and needs Encoding considerations: IRIs in this scheme are defined and needs
to be encoded as RTSP URIs when used within the RTSP protocol. to be encoded as RTSP URIs when used within the RTSP protocol.
That encoding is done according to RFC 3987. That encoding is done according to RFC 3987.
skipping to change at page 216, line 30 skipping to change at page 215, line 30
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide
to the IETF Trust", BCP 78, RFC 5378, November 2008.
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, "An 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-ietf-mmusic-rtsp-nat-07 (work in progress), draft-ietf-mmusic-rtsp-nat-08 (work in progress),
July 2008. July 2009.
[IETF-Trust-License-Policy]
IETF, "IETF TRUST Legal Provisions Relating to IETF
Documents", 2009.
[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 Draft Standard 13818-6, November 1995. ISO Draft Standard 13818-6, November 1995.
[ISO.8601.2000] [ISO.8601.2000]
International Organization for Standardization, "Data International Organization for Standardization, "Data
skipping to change at page 218, line 9 skipping to change at page 217, line 9
September 2005. September 2005.
[Stevens98] [Stevens98]
Stevens, W., "Unix Networking Programming - Volume 1, Stevens, W., "Unix Networking Programming - Volume 1,
second edition", 1998. second edition", 1998.
Appendix A. Examples Appendix A. Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that understanding of how functions of RTSP work. However, remember that
this is examples and the normative and syntax description in the these are examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the other sections takes precedence. Please also note that many of the
example contain syntax illegal line breaks to accommodate the example contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose. formatting restriction that the RFC series impose.
A.1. Media on Demand (Unicast) A.1. Media on Demand (Unicast)
The is an example of media on demand streaming of a media stored in a This is an example of media on demand streaming of a media stored in
container file. For purposes of this example, a container file is a a container file. For purposes of this example, a container file is
storage entity in which multiple continuous media types pertaining to a storage entity in which multiple continuous media types pertaining
the same end-user presentation are present. In effect, the container to the same end-user presentation are present. In effect, the
file represents an RTSP presentation, with each of its components container file represents an RTSP presentation, with each of its
being RTSP controlled media streams. Container files are a widely components being RTSP controlled media streams. Container files are
used means to store such presentations. While the components are a widely used means to store such presentations. While the
transported as independent streams, it is desirable to maintain a components are transported as independent streams, it is desirable to
common context for those streams at the server end. maintain a common context for those streams at the server end.
This enables the server to keep a single storage handle open This enables the server to keep a single storage handle open
easily. It also allows treating all the streams equally in case easily. It also allows treating all the streams equally in case
of any priorization of streams by the server. of any priorization of streams by the server.
It is also possible that the presentation author may wish to prevent It is also possible that the presentation author may wish to prevent
selective retrieval of the streams by the client in order to preserve selective retrieval of the streams by the client in order to preserve
the artistic effect of the combined media presentation. Similarly, the artistic effect of the combined media presentation. Similarly,
in such a tightly bound presentation, it is desirable to be able to in such a tightly bound presentation, it is desirable to be able to
control all the streams via a single control message using an control all the streams via a single control message using an
skipping to change at page 229, line 22 skipping to change at page 228, line 22
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971"; dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712 mode="PLAY";ssrc=EAB98712
CSeq: 2 CSeq: 2
Session: 2034820394 Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Begining-Only, Unmutable, Unlimited Media-Properties: Beginning-Only, Unmutable, Unlimited
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: 2034820394
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT Date: 23 Jan 1997 15:35:08 GMT
Session: 2034820394 Session: 2034820394
Range: npt=0-600 Range: npt=0-600
Seek-Style: RAP Seek-Style: RAP
RTP-Info: url="rtsp://foo.com/test.wav/streamid=0" RTP-Info: url="rtsp://foo.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123 ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command, and then the switch back Note the different URI in the SETUP command, and then the switch back
to the aggregate URI in the PLAY command. This makes complete sense to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but is less when there are multiple streams with aggregate control, but is less
than intuitive in the special case where the number of streams is than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI one. However, the server has declared that the aggregated control
in the SDP and therefore this is legal. URI in the SDP and therefore this is legal.
In this case, it is also required that servers accept implementations In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual that use the non-aggregated interpretation and use the individual
media URI, like this: media URI, like this:
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0 C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 2034820394 Session: 2034820394
skipping to change at page 230, line 47 skipping to change at page 229, line 47
Content-Length: 183 Content-Length: 183
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Supported: play.basic Supported: play.basic
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5 o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
t=0 0 t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16 c=IN IP4 233.252.0.54/16
a=control: rtsp://live.example.com/concert/audio a=control: rtsp://live.example.com/concert/audio
a=range:npt=0- a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast Transport: RTP/AVP;multicast
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast; Transport: RTP/AVP;multicast;
dest_addr="224.2.0.1:3456"/"224.2.0.1:3457";ttl=16 dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
Session: 0456804596 Session: 0456804596
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0 Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3 CSeq: 3
Session: 0456804596 Session: 0456804596
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
skipping to change at page 231, line 43 skipping to change at page 230, line 43
ssrc=0D12F123:seq=1473; rtptime=80000 ssrc=0D12F123:seq=1473; rtptime=80000
A.6. Capability Negotiation A.6. Capability Negotiation
This examples illustrate how the client and server determines their This examples illustrate how the client and server determines their
capability to support a special feature, in this case "play.scale". capability to support a special feature, in this case "play.scale".
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 playback (play.basic), the extended functionality supports the basic media delivery functions (play.basic), the
of time scaling of content (play.scale), and one "example.com" extended functionality of time scaling of content (play.scale), and
proprietary feature (com.example.flight). The client also learns the one "example.com" proprietary feature (com.example.flight). The
methods supported (Public header) by the server for the indicated client also learns the methods supported (Public header) by the
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 Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Server: PhonyServer/2.0 Server: PhonyServer/2.0
skipping to change at page 234, line 32 skipping to change at page 233, line 32
the requests and events that this state is allowed to act on. The the requests and events that this state is allowed to act on. The
events which is method names are, unless noted, requests with the events which is method names are, unless noted, requests with the
given method in the direction client to server (C->S). In some cases given method in the direction client to server (C->S). In some cases
there exist one or more requisite. The response column tells what there exist one or more requisite. The response column tells what
type of response actions should be performed. Possible actions that type of response actions should be performed. Possible actions that
is requested for an event includes: response codes, e.g. 200, headers is requested for an event includes: response codes, e.g. 200, headers
that MUST be included in the response, setting of state variables, or that MUST be included in the response, setting of state variables, or
setting of other session related parameters. The new state column setting of other session related parameters. The new state column
tells which state the state machine changes to. tells which state the state machine changes to.
The response to valid request meeting the requisites is normally a The response to a valid request meeting the requisites is normally a
2xx (SUCCESS) unless other noted in the response column. The 2xx (SUCCESS) unless other noted in the response column. The
exceptions need to be given a response according to the response exceptions need to be given a response according to the response
column. If the request does not meet the requisite, is erroneous or column. If the request does not meet the requisite, is erroneous or
some other type of error occur, the appropriate response code MUST be some other type of error occur, the appropriate response code MUST be
sent. If the response code is a 4xx the session state is unchanged. sent. If the response code is a 4xx the session state is unchanged.
A response code of 3rr will result in that the session is ended and A response code of 3rr will result in that the session is ended and
its state is changed to Init. A response code of 304 results in no its state is changed to Init. A response code of 304 results in no
state change. However there exist restrictions to when a 3rr state change. However, there exist restrictions to when a 3rr
response may be used. A 5xx response MUST NOT result in any change response may be used. A 5xx response MUST NOT result in any change
of the session state, except if the error is not possible to recover of the session state, except if the error is not possible to recover
from. A unrecoverable error MUST result the ending of the session. from. A unrecoverable error MUST result the ending of the session.
As it in the general case can't be determined if it was a As it in the general case can't be determined if it was a
unrecoverable error or not the client will be required to test. In unrecoverable error or not the client will be required to test. In
the case that the next request after a 5xx is responded with 454 the case that the next request after a 5xx is responded with 454
(Session Not Found) the client knows that the session has ended. (Session Not Found) the client knows that the session has ended.
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
skipping to change at page 235, line 30 skipping to change at page 234, line 30
| OPTIONS | | 200 | | OPTIONS | | 200 |
| | | | | | | |
| SET_PARAMETER | Valid parameter | 200, change value of parameter | | SET_PARAMETER | Valid parameter | 200, change value of parameter |
| | | | | | | |
| GET_PARAMETER | Valid parameter | 200, return value of 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 session or the state variables. However, some methods do change other
related parameters, for example SET_PARAMETER which will set the session related parameters, for example SET_PARAMETER which will set
parameter(s) specified in its body. Also all of these methods that the parameter(s) specified in its body. Also all of these methods
allows Session header will also update the keep-alive timer for the that allows Session header will also update the keep-alive timer for
session. the session.
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
| Action | Requisite | New State | Response | | Action | Requisite | New State | Response |
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
| SETUP | | Ready | NRM=1, RP=0.0 | | SETUP | | Ready | NRM=1, RP=0.0 |
| | | | | | | | | |
| SETUP | Needs Redirect | Init | 3rr Redirect | | SETUP | Needs Redirect | Init | 3rr Redirect |
| | | | | | | | | |
| S -> C: REDIRECT | No Session hdr | Init | Terminate all SES | | S -> C: REDIRECT | No Session hdr | Init | Terminate all SES |
+------------------+----------------+-----------+-------------------+ +------------------+----------------+-----------+-------------------+
skipping to change at page 238, line 15 skipping to change at page 237, line 15
contains an number of requests that has presentation URI as a contains an number of requests that has presentation URI as a
prerequisite on the Request-URI, this is due to the exclusion of non- prerequisite on the Request-URI, this is due to the exclusion of non-
aggregated stream control in sessions with more than one media aggregated stream control in sessions with more than one media
stream. stream.
To avoid inconsistencies between the client and server, automatic To avoid inconsistencies between the client and server, automatic
state transitions are avoided. This can be seen at for example "End state transitions are avoided. This can be seen at for example "End
of media" event when all media has finished playing, the session of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request MUST be sent still remain in Play state. An explicit PAUSE request MUST be sent
to change the state to Ready. It may appear that there exist an to change the state to Ready. It may appear that there exist an
automatic transitions in "RedP reached" and "PP reached", however automatic transitions in "RedP reached" and "PP reached", however,
they are requested and acknowledge before they take place. The time they are requested and acknowledge before they take place. The time
at which the transition will happen is known by looking at the range at which the transition will happen is known by looking at the range
header. If the client sends request close in time to these header. If the client sends request close in time to these
transitions it needs to be prepared for getting error message as the transitions it needs to be prepared for getting error message as the
state may or may not have changed. state may or may not have changed.
Appendix C. Media Transport Alternatives Appendix C. Media Transport Alternatives
This section defines how certain combinations of protocols, profiles This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
skipping to change at page 240, line 7 skipping to change at page 239, line 7
UDP [RFC0768]. 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 playback, 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.
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.
skipping to change at page 241, line 43 skipping to change at page 240, line 43
C.1.6. RTCP usage with RTSP C.1.6. RTCP usage with RTSP
RTCP has several usages when RTP is used for media transport as RTCP has several usages when RTP is used for media transport as
explained below. Due to that RTCP MUST be supported if an RTSP agent explained below. Due to that RTCP MUST be supported if an RTSP agent
handles RTP. handles RTP.
C.1.6.1. Media synchronization C.1.6.1. Media synchronization
RTCP provides media synchronization and clock drift compensation. RTCP provides media synchronization and clock drift compensation.
The initial media synchronization is available from RTP-Info header. The initial media synchronization is available from RTP-Info header.
However to be able to handle any clock drift between the media However, to be able to handle any clock drift between the media
streams, RTCP is needed. streams, RTCP is needed.
C.1.6.2. RTSP Session keep-alive C.1.6.2. RTSP Session keep-alive
RTCP traffic from the RTSP client to the RTSP server MUST function as RTCP traffic from the RTSP client to the RTSP server MUST function as
keep-alive. Which requires an RTSP server supporting RTP to use the keep-alive. Which requires an RTSP server supporting RTP to use the
received RTCP packets as indications that the client desires the received RTCP packets as indications that the client desires the
related RTSP session to be kept alive. related RTSP session to be kept alive.
C.1.6.3. Bit-rate adaption C.1.6.3. Bit-rate adaption
skipping to change at page 242, line 44 skipping to change at page 241, line 44
It is recommended that if the content and server supports RTP and It is recommended that if the content and server supports RTP and
RTCP multiplexing that this is indicated in the session description, RTCP multiplexing that this is indicated in the session description,
for example using the SDP attribute "a=rtcp-mux". If the SDP message for example using the SDP attribute "a=rtcp-mux". If the SDP message
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. Server and Client server will indicate if it supports RTCP-mux. Server and Client
SHOULD support RTP and RTCP multiplexing. SHOULD support RTP and RTCP multiplexing.
For capability exchange, an RTSP feature tag for RTP and RTCP
multiplexing is defined: "setup.rtp.rtcp.mux".
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.
One should however consider that this will result that all media One should, however, consider that this will result that 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
skipping to change at page 249, line 44 skipping to change at page 248, line 44
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 = 49, rtptime = 39200, NPT time = 14.9s S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
Upon the completion of the requested playback the server sends a Upon the completion of the requested delivery the server sends a
PLAY_NOFIFY PLAY_NOFIFY
S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0 S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
CSeq: 45 CSeq: 5
Notify-Reason: end-of-stream Notify-Reason: end-of-stream
Request-Status: cseq=4 status=200 reason="OK" Request-Status: cseq=4 status=200 reason="OK"
Range: npt=-15 Range: npt=-15
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=49;rtptime=39200 ssrc=0D12F123:seq=49;rtptime=39200
Session: abcdefgh Session: abcdefgh
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 854 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Upon the completion of the play range, the client follows up with a Upon the completion of the play range, the client follows up with a
request to PLAY from a new NPT. request to PLAY from a new NPT.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5 CSeq: 6
Session: abcdefg Session: abcdefg
Range: npt=18-20 Range: npt=18-20
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 5 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
. . . . . .
skipping to change at page 252, line 46 skipping to change at page 251, line 46
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 take server. After 20 seconds a PLAY is received by the server which take
15ms to process. The duration of time for which the session was 15ms to process. The duration of time for which the session was
paused is reflected in the RTP timestamp of the RTP packets sent 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.
Note: In RFC 2326 [RFC2326], this matter was not clearly defined and Note: In RFC 2326 [RFC2326], this matter was not clearly defined and
was misunderstood commonly. However for RTSP 2.0 it is expected that was misunderstood commonly. However, for RTSP 2.0 it is expected
this will be handled correctly and no exception handling will be that this will be handled correctly and no exception handling will be
required. required.
Note Further: To ensure correct media decoding and usually jitter- Note Further: To ensure correct media decoding and usually jitter-
buffer handling reseting some of the state when issuing a PLAY buffer handling reseting some of the state when issuing a PLAY
request is needed. request is needed.
C.5. RTSP / RTP Integration C.5. RTSP / RTP Integration
For certain datatypes, tight integration between the RTSP layer and For certain datatypes, tight integration between the RTSP layer and
the RTP layer will be necessary. This by no means precludes the the RTP layer will be necessary. This by no means precludes the
above restrictions. Combined RTSP/RTP media clients should use the above restrictions. Combined RTSP/RTP media clients should use the
RTP-Info field to determine whether incoming RTP packets were sent RTP-Info field to determine whether incoming RTP packets were sent
before or after a seek or before or after a PAUSE. before or after a seek or before or after a PAUSE.
C.6. Scaling with RTP C.6. Scaling with RTP
For scaling (see Section 16.44), RTP timestamps should correspond to For scaling (see Section 16.44), RTP timestamps should correspond to
the playback timing. For example, when playing video recorded at 30 the rendering timing. For example, when playing video recorded at 30
frames/second at a scale of two and speed (Section 16.46) of one, the frames/second at a scale of two and speed (Section 16.48) of one, the
server would drop every second frame to maintain and deliver video server would drop every second frame to maintain and deliver video
packets with the normal timestamp spacing of 3,000 per frame, but NPT packets with the normal timestamp spacing of 3,000 per frame, but NPT
would increase by 1/15 second for each video frame. would increase by 1/15 second for each video frame.
Note: The above scaling puts requirements on the media codec or a Note: The above scaling puts requirements on the media codec or a
media stream to support it. For example motion JPEG or other non- media stream to support it. For example motion JPEG or other non-
predictive video coding can easier handle the above example. predictive video coding can easier handle the above example.
C.7. Maintaining NPT synchronization with RTP timestamps C.7. Maintaining NPT synchronization with RTP timestamps
skipping to change at page 255, line 16 skipping to change at page 254, line 16
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. SDP as is provides no mechanism by which a client
can distinguish, without human guidance, between several media can distinguish, without human guidance, between several media
streams to be rendered simultaneously and a set of alternatives streams to be rendered simultaneously and a set of alternatives
(e.g., two audio streams spoken in different languages). However the (e.g., two audio streams spoken in different languages). However
SDP extension "Grouping of Media Lines in the Session Description ,the SDP extension "Grouping of Media Lines in the Session
Protocol (SDP)" [RFC3388] may provide such functionality depending on Description Protocol (SDP)" [RFC3388] may provide such functionality
need. Also future grouping semantics may in the future be developed. depending on need. Also future grouping semantics may in the future
be developed.
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 (RFC 4566 [RFC4566]): SDP (RFC 4566 [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
skipping to change at page 256, line 31 skipping to change at page 255, line 31
URI: "rtsp://example.com/container.mp4". Lets further assume this URI: "rtsp://example.com/container.mp4". Lets further assume this
URI is the base URI, and that there is a absolute media level URI: URI is the base URI, and that there is a absolute media level URI:
"rtsp://example.com/container.mp4/trackID=2". A relative media level "rtsp://example.com/container.mp4/trackID=2". A relative media level
URI that resolves in accordance with RFC 3986 [RFC3986] to the above URI that resolves in accordance with RFC 3986 [RFC3986] to the above
given media URI is: "container.mp4/trackID=2". It is usually not given media URI is: "container.mp4/trackID=2". It is usually not
desirable to need to include in or modify the SDP stored within the desirable to need to include in or modify the SDP stored within the
container file with the server local name of the container file. To 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 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/container.mp4/". "rtsp://example.com/container.mp4/".
Note: The usage of TrackID in the above is not an standardized Note: The usage of TrackID in the above is not an 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
skipping to change at page 258, line 33 skipping to change at page 257, line 33
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 contains media streams of the same durations, the presentations that contains media streams of the same durations, the
range attribute SHOULD only be used at session-level. In case of range attribute SHOULD only be used at session-level. In case of
different length the range attribute MUST be given at media level for different length the range attribute MUST be given at media level for
all media, and SHOULD NOT be given at session level. If the all media, and SHOULD NOT be given at session level. If the
attribute is present at both media level and session level the media attribute is present at both media level and session level the media
level values MUST be used. level values MUST be used.
Note: Usually one will specify the same length for all media, even if Note: Usually one will specify the same length for all media, even if
there isn't media available for the full duration on all media. there isn't media available for the full duration on all media.
However that requires that the server accepts PLAY requests within However, that requires that the server accepts PLAY requests within
that range. that range.
Servers MUST take care to provide RTSP Range (see Section 16.38) Servers MUST take care to provide RTSP Range (see Section 16.38)
values that are consistent with what is presented in the SDP for the values that are consistent with what is presented in the SDP for the
content. There is no reason for non dynamic content, like media content. There is no reason for non dynamic content, like media
clips provided on demand to have inconsistent values. Inconsistent clips provided on demand to have inconsistent values. Inconsistent
values between the SDP and the actual values for the content handled values between the SDP and the actual values for the content handled
by the server is likely to generate some failure, like 457 "Invalid by the server is likely to generate some failure, like 457 "Invalid
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
skipping to change at page 261, line 46 skipping to change at page 260, line 46
rtsp://example.com/movie/trackID=2 to set up the video and audio rtsp://example.com/movie/trackID=2 to set up the video and audio
streams, respectively. The URI rtsp://example.com/movie/, which is streams, respectively. The URI rtsp://example.com/movie/, which is
resolved from the "*", controls the whole presentation (movie). resolved from the "*", controls the whole presentation (movie).
A client is not required to issues SETUP requests for all streams A client is not required to issues 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. RTSP external SDP delivery D.4. RTSP external SDP delivery
There are some considerations that needs to be made when the session There are some considerations that need to be made when the session
description is delivered to client outside of RTSP, for example in description is delivered to the client outside of RTSP, for example
HTTP or email. via HTTP or email.
</