draft-ietf-mmusic-rfc2326bis-14.txt   draft-ietf-mmusic-rfc2326bis-15.txt 
Internet Engineering Task Force MMUSIC WG MMUSIC Working Group H. Schulzrinne
Internet Draft H. Schulzrinne Internet-Draft Columbia University
draft-ietf-mmusic-rfc2326bis-14.txt Columbia U. Intended status: Standards Track A. Rao
Dec 22, 2006 A. Rao Expires: December 27, 2007 Cisco
Expires: June, 2007 Cisco
R. Lanphier R. Lanphier
RealNetworks RealNetworks
Magnus Westerlund M. Westerlund
Ericsson Ericsson AB
A. Narasimhan A. Narasimhan
Overture Overture Computing Corp.
M. Stiemerling (Ed.)
NEC
June 25, 2007
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-15.txt
STATUS OF THIS MEMO Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memorandum defines RTSP version 2.0 which is a revision of the This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in RFC 2326. Proposed Standard RTSP version 1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1 Introduction ........................................ 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1 RTSP Specification Update ........................... 9 1.1. RTSP Specification Update . . . . . . . . . . . . . . . 8
1.2 Purpose ............................................. 9 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Notational Conventions .............................. 11 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10
1.3.1 RFC Editor Consideration ............................ 11 1.3.1. RFC Editor Consideration . . . . . . . . . . . . . . 10
1.4 Terminology ......................................... 11 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Protocol Properties ................................. 15 1.5. Protocol Properties . . . . . . . . . . . . . . . . . . 14
1.6 Extending RTSP ...................................... 16 1.6. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 15
1.7 Overall Operation ................................... 17 1.7. Overall Operation . . . . . . . . . . . . . . . . . . . 16
1.8 RTSP States ......................................... 18 1.8. RTSP States . . . . . . . . . . . . . . . . . . . . . . 17
1.9 Relationship with Other Protocols ................... 19 1.9. Relationship with Other Protocols . . . . . . . . . . . 18
2 RTSP Use Cases ...................................... 20 2. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 On-demand Playback of Stored Content ................ 20 2.1. On-demand Playback of Stored Content . . . . . . . . . . 19
2.2 Unicast distribution of Live Content ................ 21 2.2. Unicast distribution of Live Content . . . . . . . . . . 20
2.3 On-demand Playback using Multicast .................. 22 2.3. On-demand Playback using Multicast . . . . . . . . . . . 21
2.4 Inviting an RTSP server into a conference ........... 22 2.4. Inviting an RTSP server into a conference . . . . . . . 21
2.5 Live Content using Multicast ........................ 23 2.5. Live Content using Multicast . . . . . . . . . . . . . . 22
3 Protocol Parameters ................................. 24 3. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 24
3.1 RTSP Version ........................................ 24 3.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 24
3.2 RTSP IRI and URI .................................... 24 3.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 24
3.3 Session Identifiers ................................. 26 3.3. Session Identifiers . . . . . . . . . . . . . . . . . . 26
3.4 SMPTE Relative Timestamps ........................... 26 3.4. SMPTE Relative Timestamps . . . . . . . . . . . . . . . 26
3.5 Normal Play Time .................................... 27 3.5. Normal Play Time . . . . . . . . . . . . . . . . . . . . 26
3.6 Absolute Time ....................................... 27 3.6. Absolute Time . . . . . . . . . . . . . . . . . . . . . 27
3.7 Feature-tags ........................................ 28 3.7. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Entity Tags ......................................... 28 3.8. Entity Tags . . . . . . . . . . . . . . . . . . . . . . 28
4 RTSP Message ........................................ 28 4. RTSP Message . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Message Types ....................................... 29 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . 29
4.2 Message Headers ..................................... 29 4.2. Message Headers . . . . . . . . . . . . . . . . . . . . 29
4.3 Message Body ........................................ 29 4.3. Message Body . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Message Length ...................................... 29 4.4. Message Length . . . . . . . . . . . . . . . . . . . . . 29
5 General Header Fields ............................... 30 5. General Header Fields . . . . . . . . . . . . . . . . . . . . 31
6 Request ............................................. 30 6. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.1 Request Line ........................................ 31 6.1. Request Line . . . . . . . . . . . . . . . . . . . . . . 32
6.2 Request Header Fields ............................... 32 6.2. Request Header Fields . . . . . . . . . . . . . . . . . 34
7 Response ............................................ 32 7. Response . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1 Status-Line ......................................... 33 7.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . 36
7.1.1 Status Code and Reason Phrase ....................... 33 7.1.1. Status Code and Reason Phrase . . . . . . . . . . . 36
7.2 Response Header Fields .............................. 34 7.2. Response Header Fields . . . . . . . . . . . . . . . . . 39
8 Entity .............................................. 35 8. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.1 Entity Header Fields ................................ 37 8.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 42
8.2 Entity Body ......................................... 37 8.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 43
9 Connections ......................................... 37 9. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1 Reliability and Acknowledgements .................... 38 9.1. Reliability and Acknowledgements . . . . . . . . . . . . 44
9.2 Using Connections ................................... 39 9.2. Using Connections . . . . . . . . . . . . . . . . . . . 45
9.3 Closing Connections ................................. 40 9.3. Closing Connections . . . . . . . . . . . . . . . . . . 46
9.4 Timing Out Connections and RTSP Messages ............ 41 9.4. Timing Out Connections and RTSP Messages . . . . . . . . 47
9.5 Use of IPv6 ......................................... 41 9.5. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 47
10 Capability Handling ................................. 41 10. Capability Handling . . . . . . . . . . . . . . . . . . . . . 48
11 Method Definitions .................................. 43 11. Method Definitions . . . . . . . . . . . . . . . . . . . . . 50
11.1 OPTIONS ............................................. 44 11.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 51
11.2 DESCRIBE ............................................ 45 11.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 52
11.3 SETUP ............................................... 47 11.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.3.1 Changing Transport Parameters ....................... 50 11.3.1. Changing Transport Parameters . . . . . . . . . . . 56
11.4 PLAY ................................................ 50 11.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.5 PAUSE ............................................... 56 11.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.6 TEARDOWN ............................................ 58 11.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 65
11.7 GET_PARAMETER ....................................... 59 11.7. GETPARAMETER . . . . . . . . . . . . . . . . . . . . . . 66
11.8 SET_PARAMETER ....................................... 59 11.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 67
11.9 REDIRECT ............................................ 61 11.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 68
12 Embedded (Interleaved) Binary Data .................. 63 12. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 71
13 Status Code Definitions ............................. 65 13. Status Code Definitions . . . . . . . . . . . . . . . . . . . 73
13.1 Success 1xx ......................................... 65 13.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 73
13.1.1 100 Continue ........................................ 65 13.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 73
13.2 Success 2xx ......................................... 65 13.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 73
13.3 Redirection 3xx ..................................... 65 13.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 73
13.3.1 300 Multiple Choices ................................ 66 13.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 74
13.3.2 301 Moved Permanently ............................... 66 13.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 74
13.3.3 302 Found ........................................... 66 13.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 74
13.3.4 303 See Other ....................................... 67 13.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 74
13.3.5 304 Not Modified .................................... 67 13.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 74
13.3.6 305 Use Proxy ....................................... 67 13.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 75
13.4 Client Error 4xx .................................... 67 13.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 75
13.4.1 400 Bad Request ..................................... 68 13.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 75
13.4.2 405 Method Not Allowed .............................. 68 13.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 75
13.4.3 451 Parameter Not Understood ........................ 68 13.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 75
13.4.4 452 reserved ........................................ 68 13.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 75
13.4.5 453 Not Enough Bandwidth ............................ 68 13.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 76
13.4.6 454 Session Not Found ............................... 68 13.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 76
13.4.7 455 Method Not Valid in This State .................. 68 13.4.7. 455 Method Not Valid in This State . . . . . . . . . 76
13.4.8 456 Header Field Not Valid for Resource ............. 68 13.4.8. 456 Header Field Not Valid for Resource . . . . . . 76
13.4.9 457 Invalid Range ................................... 69 13.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 76
13.4.10 458 Parameter Is Read-Only .......................... 69 13.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 76
13.4.11 459 Aggregate Operation Not Allowed ................. 69 13.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 76
13.4.12 460 Only Aggregate Operation Allowed ................ 69 13.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 76
13.4.13 461 Unsupported Transport ........................... 69 13.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 77
13.4.14 462 Destination Unreachable ......................... 69 13.4.14. 462 Destination Unreachable . . . . . . . . . . . . 77
13.4.15 463 Destination Prohibited .......................... 69 13.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 77
13.4.16 464 Data Transport Not Ready Yet .................... 70 13.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 77
13.4.17 470 Connection Authorization Required ............... 70 13.4.17. 470 Connection Authorization Required . . . . . . . 77
13.4.18 471 Connection Credentials not accepted ............. 70 13.4.18. 471 Connection Credentials not accepted . . . . . . 77
13.5 Server Error 5xx .................................... 70 13.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 78
13.5.1 551 Option not supported ............................ 70 13.5.1. 551 Option not supported . . . . . . . . . . . . . . 78
14 Header Field Definitions ............................ 70 14. Header Field Definitions . . . . . . . . . . . . . . . . . . 79
14.1 Accept .............................................. 74 14.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 88
14.2 Accept-Credentials .................................. 75 14.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 88
14.3 Accept-Encoding ..................................... 75 14.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 89
14.4 Accept-Language ..................................... 77 14.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 89
14.5 Accept-Ranges ....................................... 77 14.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 89
14.6 Allow ............................................... 78 14.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 89
14.7 Authorization ....................................... 78 14.7. Authorization . . . . . . . . . . . . . . . . . . . . . 90
14.8 Bandwidth ........................................... 78 14.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 90
14.9 Blocksize ........................................... 78 14.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 90
14.10 Cache-Control ....................................... 79 14.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 90
14.11 Connection .......................................... 81 14.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 93
14.12 Connection-Credentials .............................. 81 14.12. Connection-Credentials . . . . . . . . . . . . . . . . . 93
14.13 Content-Base ........................................ 82 14.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 93
14.14 Content-Encoding .................................... 82 14.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 93
14.15 Content-Language .................................... 82 14.15. Content-Language . . . . . . . . . . . . . . . . . . . . 93
14.16 Content-Length ...................................... 82 14.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 94
14.17 Content-Location .................................... 82 14.17. Content-Location . . . . . . . . . . . . . . . . . . . . 94
14.18 Content-Type ........................................ 82 14.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 94
14.19 CSeq ................................................ 83 14.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 94
14.20 Date ................................................ 83 14.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 94
14.21 ETag ................................................ 83 14.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 95
14.22 Expires ............................................. 84 14.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 95
14.23 From ................................................ 85 14.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 96
14.24 If-Match ............................................ 85 14.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 96
14.25 If-Modified-Since ................................... 85 14.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 97
14.26 If-None-Match ....................................... 86 14.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 97
14.27 Last-Modified ....................................... 86 14.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 97
14.28 Location ............................................ 86 14.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 97
14.29 Proxy-Authenticate .................................. 86 14.29. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 97
14.30 Proxy-Authorization ................................. 86 14.30. Proxy-Authorization . . . . . . . . . . . . . . . . . . 97
14.31 Proxy-Require ....................................... 86 14.31. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 97
14.32 Proxy-Supported ..................................... 87 14.32. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 98
14.33 Public .............................................. 87 14.33. Public . . . . . . . . . . . . . . . . . . . . . . . . . 99
14.34 Range ............................................... 88 14.34. Range . . . . . . . . . . . . . . . . . . . . . . . . . 100
14.35 Referer ............................................. 90 14.35. Referer . . . . . . . . . . . . . . . . . . . . . . . . 101
14.36 Retry-After ......................................... 90 14.36. Retry-After . . . . . . . . . . . . . . . . . . . . . . 101
14.37 Require ............................................. 90 14.37. Require . . . . . . . . . . . . . . . . . . . . . . . . 101
14.38 RTP-Info ............................................ 91 14.38. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 102
14.39 Scale ............................................... 93 14.39. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 104
14.40 Speed ............................................... 94 14.40. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 105
14.41 Server .............................................. 95 14.41. Server . . . . . . . . . . . . . . . . . . . . . . . . . 106
14.42 Session ............................................. 95 14.42. Session . . . . . . . . . . . . . . . . . . . . . . . . 106
14.43 Supported ........................................... 96 14.43. Supported . . . . . . . . . . . . . . . . . . . . . . . 107
14.44 Timestamp ........................................... 97 14.44. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 108
14.45 Transport ........................................... 97 14.45. Transport . . . . . . . . . . . . . . . . . . . . . . . 108
14.46 Unsupported ......................................... 103 14.46. Unsupported . . . . . . . . . . . . . . . . . . . . . . 114
14.47 User-Agent .......................................... 104 14.47. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 114
14.48 Vary ................................................ 104 14.48. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 114
14.49 Via ................................................. 104 14.49. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 114
14.50 WWW-Authenticate .................................... 104 14.50. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 114
15 Proxies ............................................. 104 15. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
16 Caching ............................................. 105 16. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
17 Examples ............................................ 106 17. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 118
17.1 Media on Demand (Unicast) ........................... 106 17.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 118
17.2 Media on Demand (Unicast) ........................... 109 17.2. Media on Demand (Unicast) . . . . . . . . . . . . . . . 121
17.3 Single Stream Container Files ....................... 112 17.3. Single Stream Container Files . . . . . . . . . . . . . 123
17.4 Live Media Presentation Using Multicast ............. 114 17.4. Live Media Presentation Using Multicast . . . . . . . . 125
17.5 Capability Negotiation .............................. 115 17.5. Capability Negotiation . . . . . . . . . . . . . . . . . 126
18 Security Framework .................................. 116 18. Security Framework . . . . . . . . . . . . . . . . . . . . . 128
18.1 RTSP and HTTP Authentication ........................ 116 18.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 128
18.2 RTSP over TLS ....................................... 116 18.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 128
18.3 Security and Proxies ................................ 117 18.3. Security and Proxies . . . . . . . . . . . . . . . . . . 129
18.3.1 Accept-Credentials .................................. 118 18.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 130
18.3.2 User approved TLS procedure ......................... 119 18.3.2. User approved TLS procedure . . . . . . . . . . . . 131
19 Syntax .............................................. 121 19. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
19.1 Base Syntax ......................................... 121 19.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 133
19.2 RTSP Protocol Definition ............................ 123 19.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 135
19.2.1 Generic Protocol elements ........................... 123 19.2.1. Generic Protocol elements . . . . . . . . . . . . . 135
19.2.2 Message Syntax ...................................... 125 19.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 138
19.2.3 Header Syntax ....................................... 129 19.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 142
19.3 SDP extension Syntax ................................ 135 19.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 149
20 Security Considerations ............................. 135 20. Security Considerations . . . . . . . . . . . . . . . . . . . 150
20.1 Remote denial of Service Attack ..................... 137 20.1. Remote denial of Service Attack . . . . . . . . . . . . 152
21 IANA Considerations ................................. 138 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
21.1 Feature-tags ........................................ 139 21.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 154
21.1.1 Description ......................................... 139 21.1.1. Description . . . . . . . . . . . . . . . . . . . . 154
21.1.2 Registering New Feature-tags with IANA .............. 139 21.1.2. Registering New Feature-tags with IANA . . . . . . . 155
21.1.3 Registered entries .................................. 139 21.1.3. Registered entries . . . . . . . . . . . . . . . . . 155
21.2 RTSP Methods ........................................ 140 21.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 155
21.2.1 Description ......................................... 140 21.2.1. Description . . . . . . . . . . . . . . . . . . . . 155
21.2.2 Registering New Methods with IANA ................... 140 21.2.2. Registering New Methods with IANA . . . . . . . . . 155
21.2.3 Registered Entries .................................. 140 21.2.3. Registered Entries . . . . . . . . . . . . . . . . . 156
21.3 RTSP Status Codes ................................... 141 21.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 156
21.3.1 Description ......................................... 141 21.3.1. Description . . . . . . . . . . . . . . . . . . . . 156
21.3.2 Registering New Status Codes with IANA .............. 141 21.3.2. Registering New Status Codes with IANA . . . . . . . 156
21.3.3 Registered Entries .................................. 141 21.3.3. Registered Entries . . . . . . . . . . . . . . . . . 156
21.4 RTSP Headers ........................................ 141 21.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 156
21.4.1 Description ......................................... 141 21.4.1. Description . . . . . . . . . . . . . . . . . . . . 156
21.4.2 Registering New Headers with IANA ................... 141 21.4.2. Registering New Headers with IANA . . . . . . . . . 157
21.4.3 Registered entries .................................. 142 21.4.3. Registered entries . . . . . . . . . . . . . . . . . 157
21.5 Transport Header registries ......................... 142 21.5. Transport Header Registries . . . . . . . . . . . . . . 158
21.5.1 Transport Protocol Specification .................... 142 21.5.1. Transport Protocol Specification . . . . . . . . . . 158
21.5.2 Transport modes ..................................... 144 21.5.2. Transport modes . . . . . . . . . . . . . . . . . . 159
21.5.3 Transport Parameters ................................ 144 21.5.3. Transport Parameters . . . . . . . . . . . . . . . . 160
21.6 Cache Directive Extensions .......................... 145 21.6. Cache Directive Extensions . . . . . . . . . . . . . . . 160
21.7 Accept-Credentials .................................. 145 21.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 161
21.7.1 Accept-Credentials policies ......................... 145 21.7.1. Accept-Credentials policies . . . . . . . . . . . . 161
21.7.2 Accept-Credentials hash algorithms .................. 146 21.7.2. Accept-Credentials hash algorithms . . . . . . . . . 161
21.8 Range header formats ................................ 146 21.8. Range header formats . . . . . . . . . . . . . . . . . . 162
21.9 URI Schemes ......................................... 147 21.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 162
21.9.1 The rtsp URI Scheme ................................. 147 21.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 162
21.9.2 The rtsps URI Scheme ................................ 148 21.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 163
21.9.3 The rtspu URI Scheme ................................ 149 21.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 164
21.10 SDP attributes ...................................... 149 21.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 165
A RTSP Protocol State Machine ......................... 150 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 166
A.1 States .............................................. 151 22.1. Normative References . . . . . . . . . . . . . . . . . . 166
A.2 State variables ..................................... 151 22.2. Informative References . . . . . . . . . . . . . . . . . 168
A.3 Abbreviations ....................................... 151 Appendix A. RTSP Protocol State Machine . . . . . . . . . . . . 170
A.4 State Tables ........................................ 151 A.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 170
B Media Transport Alternatives ........................ 155 A.2. State variables . . . . . . . . . . . . . . . . . . . . 170
B.1 RTP ................................................. 155 A.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 170
B.1.1 AVP ................................................. 155 A.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 171
B.1.2 AVP/UDP ............................................. 155 Appendix B. Media Transport Alternatives . . . . . . . . . . . . 176
B.1.3 AVPF/UDP ............................................ 156 B.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 176
B.1.4 SAVP/UDP ............................................ 157 B.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 176
B.1.5 SAVPF/UDP ........................................... 157 B.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 176
B.2 RTP over TCP ........................................ 157 B.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 177
B.2.1 Interleaved RTP over TCP ............................ 157 B.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 178
B.2.2 RTP over independent TCP ............................ 158 B.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 178
B.2.3 Handling NPT Jumps in the RTP Media Layer ........... 161 B.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 178
B.2.4 Handling RTP Timestamps after PAUSE ................. 163 B.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 178
B.2.5 RTSP / RTP Integration .............................. 166 B.2.2. RTP over independent TCP . . . . . . . . . . . . . . 179
B.2.6 Scaling with RTP .................................... 166 B.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 182
B.2.7 Maintaining NPT synchronization with RTP B.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 184
timestamps ..................................................... 166 B.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 186
B.2.8 Continuous Audio .................................... 166 B.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 186
B.2.9 Multiple Sources in an RTP Session .................. 166 B.2.7. Maintaining NPT synchronization with RTP
B.2.10 Usage of SSRCs and the RTCP BYE Message During an timestamps . . . . . . . . . . . . . . . . . . . . . 187
RTSP Session ................................................... 166 B.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 187
B.3 Future Additions .................................... 167 B.2.9. Multiple Sources in an RTP Session . . . . . . . . . 187
C Use of SDP for RTSP Session Descriptions ............ 167 B.2.10. Usage of SSRCs and the RTCP BYE Message During an
C.1 Definitions ......................................... 168 RTSP Session . . . . . . . . . . . . . . . . . . . . 187
C.1.1 Control URI ......................................... 168 B.3. Future Additions . . . . . . . . . . . . . . . . . . . . 187
C.1.2 Media Streams ....................................... 169 Appendix C. Use of SDP for RTSP Session Descriptions . . . . . . 189
C.1.3 Payload Type(s) ..................................... 170 C.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 189
C.1.4 Format-Specific Parameters .......................... 170 C.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 189
C.1.5 Directionality of media stream ...................... 170 C.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 190
C.1.6 Range of Presentation ............................... 171 C.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 191
C.1.7 Time of Availability ................................ 172 C.1.4. Format-Specific Parameters . . . . . . . . . . . . . 191
C.1.8 Connection Information .............................. 172 C.1.5. Directionality of media stream . . . . . . . . . . . 191
C.1.9 Entity Tag .......................................... 172 C.1.6. Range of Presentation . . . . . . . . . . . . . . . 192
C.2 Aggregate Control Not Available ..................... 173 C.1.7. Time of Availability . . . . . . . . . . . . . . . . 193
C.3 Aggregate Control Available ......................... 174 C.1.8. Connection Information . . . . . . . . . . . . . . . 193
C.4 RTSP external SDP delivery .......................... 175 C.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 193
D Minimal RTSP implementation ......................... 175 C.2. Aggregate Control Not Available . . . . . . . . . . . . 194
D.1 Minimal Core Implementation ......................... 175 C.3. Aggregate Control Available . . . . . . . . . . . . . . 195
D.2 Recommended Core Implementation ..................... 176 C.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 196
D.3 The Basic Playback Feature Support .................. 176 Appendix D. Minimal RTSP Implementation . . . . . . . . . . . . 197
D.3.1 Client .............................................. 176 D.1. Minimal Core Implementation . . . . . . . . . . . . . . 197
D.3.2 Server .............................................. 177 D.2. Recommended Core Implementation . . . . . . . . . . . . 197
D.3.3 Proxy ............................................... 177 D.3. The Basic Playback Feature Support . . . . . . . . . . . 198
D.4 Secure Transport .................................... 178 D.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 198
E Requirements for Unreliable Transport of RTSP D.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 198
messages ....................................................... 178 D.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 199
F Backwards Compatibility Considerations .............. 179 D.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 199
F.1 Play Request in Play mode ........................... 179 Appendix E. Requirements for Unreliable Transport of RTSP . . . 200
F.2 Using Persistent Connections ........................ 180 Appendix F. Backwards Compatibility Considerations . . . . . . . 202
G Open Issues ......................................... 180 F.1. Play Request in Play mode . . . . . . . . . . . . . . . 202
H Changes ............................................. 181 F.2. Using Persistent Connections . . . . . . . . . . . . . . 202
H.1 Changes needing to be updated ..................... 187 Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 203
I Author Addresses .................................... 188 Appendix H. Changes . . . . . . . . . . . . . . . . . . . . . . 205
J Contributors ........................................ 188 H.1. Changes needing to be updated . . . . . . . . . . . . . 210
K Acknowledgements .................................... 189 Appendix I. Contributors . . . . . . . . . . . . . . . . . . . . 211
L Normative References ................................ 189 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 212
M Informative References .............................. 191 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 213
Intellectual Property and Copyright Statements . . . . . . . . . 215
1 Introduction 1. Introduction
1.1 RTSP Specification Update 1.1. RTSP Specification Update
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a
proposed standard defined in RFC 2326 [25]. The goal of this version proposed standard defined in [RFC2326]. The goal of this version is
is to correct the many flaws that have been identified in RTSP 1.0 to correct the many flaws that have been identified in RTSP 1.0 since
since its publication. The corrections are such that backwards its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was deemed the most compatibility was impossible. Thus a new version was deemed the most
appropriate solution to get a more functional protocol. There are no appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix H catalogs the changes of this plans to revise RTSP 1.0. Appendix H catalogs the changes of this
version in relation to RTSP 1.0. version in relation to RTSP 1.0.
RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at
specifying the RTSP core, functionality and rules for extensions, and specifying the RTSP core, functionality and rules for extensions, and
basic interaction with the media delivery protocol RTP. basic interaction with the media delivery protocol RTP [RFC3550].
Any other functionality would be need to be published as extension Any other functionality would be need to be published as extension
documents. This specification provides rules for such extensions and documents. This specification provides rules for such extensions and
defines registries to avoid naming collisions. defines registries to avoid naming collisions.
1.2 Purpose 1.2. Purpose
The Real-Time Streaming Protocol (RTSP) establishes and controls one The Real-Time Streaming Protocol (RTSP) establishes and controls one
or several time-synchronized streams of continuous media such as or several time-synchronized streams of continuous media such as
audio and video. Put simply, RTSP acts as a "network remote control" audio and video. Put simply, RTSP acts as a "network remote control"
for multimedia servers. for multimedia servers.
There is no notion of an RTSP connection in the protocol. Instead, an There is no notion of an RTSP connection in the protocol. Instead,
RTSP server maintains a session labeled by an identifier to associate an RTSP server maintains a session labeled by an identifier to
groups of media streams and their states. An RTSP session is not tied associate groups of media streams and their states. An RTSP session
to a transport-level connection such as a TCP connection. During a is not tied to a transport-level connection such as a TCP connection.
session, a client may open and close multiple reliable transport During a session, a client may open and close multiple reliable
connections to the server to issue RTSP requests for that session. transport connections to the server to issue RTSP requests for that
session.
This memorandum describes the use of RTSP over a reliable connection This memorandum describes the use of RTSP over a reliable connection
based transport level protocol such as TCP. RTSP may be implemented based transport level protocol such as TCP. RTSP may be implemented
over an unreliable connectionless transport protocol such as UDP. over an unreliable connectionless transport protocol such as UDP.
While nothing in RTSP precludes this, additional definition of this While nothing in RTSP precludes this, additional definition of this
problem area needs to be handled as an extension to the core problem area needs to be handled as an extension to the core
specification. specification.
The mechanisms of RTSP's operation over UDP were left out The mechanisms of RTSP's operation over UDP were left out of this
of this spec. because they were poorly defined in RFC 2326 spec. because they were poorly defined in [RFC2326] and the
[25] and the tradeoff in size and complexity of this tradeoff in size and complexity of this memorandum for a small
memorandum for a small gain in a limited problem space was gain in a limited problem space was not deemed justifiable.
not deemed justifiable.
The set of streams to be controlled in an RTSP session is defined by The set of streams to be controlled in an RTSP session is defined by
a presentation description. This memorandum does not define a format a presentation description. This memorandum does not define a format
for the presentation description. However appendix C describes how for the presentation description. However appendix C describes how
SDP [1] is used for this purpose. The streams controlled by RTSP may SDP [RFC4566] is used for this purpose. The streams controlled by
use RTP [2] for their data transport, but the operation of RTSP does RTSP may use RTP [RFC3550] for their data transport, but the
not depend on the transport mechanism used to carry continuous media. operation of RTSP does not depend on the transport mechanism used to
RTSP is intentionally similar in syntax and operation to HTTP/1.1 [3] carry continuous media. RTSP is intentionally similar in syntax and
so that extension mechanisms to HTTP can in most cases also be operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP
applied to RTSP. However, RTSP differs in a number of important can in most cases also be applied to RTSP. However, RTSP differs in
aspects from HTTP: a number of important aspects from HTTP:
o RTSP introduces a number of new methods and has a different * RTSP introduces a number of new methods and has a different
protocol identifier. protocol identifier.
o RTSP has the notion of a session built into the protocol. * RTSP has the notion of a session built into the protocol.
o An RTSP server needs to maintain state in almost all cases, as * An RTSP server needs to maintain state in almost all cases, as
opposed to the stateless nature of HTTP. opposed to the stateless nature of HTTP.
o Both an RTSP server and client can issue requests. * Both an RTSP server and client can issue requests.
o Data is usually carried out-of-band by a different protocol. * Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see Session descriptions returned in a DESCRIBE response (see
Section 11.2) and interleaving of RTP with RTSP over TCP are Section 11.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 12). exceptions to this rule (see Section 12).
o RTSP is defined to use ISO 10646 (UTF-8) rather than ISO * RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts 8859-1, consistent with HTML internationalization efforts
[26]. [RFC2070].
o The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 [3]
carries only the absolute path in the request and puts the
host name in a separate header field.
This makes "virtual hosting" easier, where a single * The Request-URI always contains the absolute URI. Because of
host with one IP address hosts several document trees. backward compatibility with a historical blunder, HTTP/1.1
[RFC2616] carries only the absolute path in the request and
puts the host name in a separate header field.
This makes "virtual hosting" easier, where a single host with
one IP address hosts several document trees.
The protocol supports the following operations: The protocol supports the following operations:
Retrieval of media from media server: The client can either Retrieval of media from media server: The client can either request
request a presentation description via RTSP DESCRIBE, HTTP a presentation description via RTSP DESCRIBE, HTTP or some
or some other method. If the presentation is being other method. If the presentation is being multicast, the
multicast, the presentation description contains the presentation description contains the multicast addresses and
multicast addresses and ports to be used for the continuous ports to be used for the continuous media. If the presentation
media. If the presentation is to be sent only to the client is to be sent only to the client via unicast, the client
via unicast, the client provides the destination. provides the destination.
Invitation of a media server to a conference: A media server can Invitation of a media server to a conference: A media server can be
be "invited" to join an existing conference to play back "invited" to join an existing conference to play back media
media into the presentation. This mode is useful, for into the presentation. This mode is useful, for example, in
example, in distributed teaching applications. Several distributed teaching applications. Several parties in the
parties in the conference may take turns "pushing the conference may take turns "pushing the remote control buttons".
remote control buttons". Note: This functionality will Note: This functionality will require RTSP external application
require RTSP external application level functionality. level functionality.
RTSP requests may be handled by proxies, tunnels and caches as in RTSP requests may be handled by proxies, tunnels and caches as in
HTTP/1.1 [3]. HTTP/1.1 [RFC2616].
1.3 Notational Conventions 1.3. Notational Conventions
Since many of the definitions and syntax are identical to HTTP/1.1, Since many of the definitions and syntax are identical to HTTP/1.1,
this specification only points to the section where they are defined this specification only points to the section where they are defined
rather than copying it. For brevity, [HX.Y] is to be taken to refer rather than copying it. For brevity, [HX.Y] is to be taken to refer
to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [3]). to Section X.Y of the current HTTP/1.1 specification ([RFC2616]).
All the mechanisms specified in this document are described in both All the mechanisms specified in this document are described in both
prose and the Augmented Backus-Naur form (ABNF) described in detail prose and the Augmented Backus-Naur form (ABNF) described in detail
in RFC 4234 [4]. in [RFC4234].
Indented and smaller-type paragraphs are used to provide informative Indented and smaller-type paragraphs are used to provide informative
background and motivation. This is intended to give readers who were background and motivation. This is intended to give readers who were
not involved with the formulation of the specification an not involved with the formulation of the specification an
understanding of why things are the way they are in RTSP. understanding of why things are the way they are in RTSP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5]. document are to be interpreted as described in [RFC2119].
The word, "unspecified" is used to indicate functionality or features The word, "unspecified" is used to indicate functionality or features
that are not defined in this specification. Such functionality cannot that are not defined in this specification. Such functionality
be used in a standardized manner without further definition in an cannot be used in a standardized manner without further definition in
extension specification to RTSP. an extension specification to RTSP.
1.3.1 RFC Editor Consideration 1.3.1. RFC Editor Consideration
Please replace RFC XXXX with the RFC number this specification Please replace RFC XXXX with the RFC number this specification
recieves. recieves.
Please replace RFC YYYY with the RFC number that SAVPF [6] receives. Please replace RFC YYYY with the RFC number that SAVPF
[I-D.ietf-avt-profile-savpf] receives.
1.4 Terminology 1.4. Terminology
Some of the terminology has been adopted from HTTP/1.1 [3]. Terms not Some of the terminology has been adopted from HTTP/1.1 [RFC2616].
listed here are defined as in HTTP/1.1. Terms not listed here are defined as in HTTP/1.1.
Aggregate control: The concept of controlling multiple streams Aggregate control: The concept of controlling multiple streams using
using a single timeline, generally maintained by the a single timeline, generally maintained by the server. A client,
server. A client, for example, uses aggregate control when for example, uses aggregate control when it issues a single play
it issues a single play or pause message to simultaneously or pause message to simultaneously control both the audio and
control both the audio and video in a movie. A session video in a movie. A session which is under aggregate control is
which is under aggregate control is referred to as an referred to as an aggregated session.
aggregated session.
Aggregate control URI: The URI used in an RTSP request to refer Aggregate control URI: The URI used in an RTSP request to refer to
to and control an aggregated session. It normally, but not and control an aggregated session. It normally, but not always,
always, corresponds to the presentation URI specified in corresponds to the presentation URI specified in the session
the session description. See Section 11.3 for more description. See Section 11.3 for more information.
information.
Conference: a multiparty, multimedia presentation, where "multi" Conference: A multiparty, multimedia presentation, where "multi"
implies greater than or equal to one. implies greater than or equal to one.
Client: The client requests media service from the media server. Client: The client requests media service from the media server.
Connection: A transport layer virtual circuit established Connection: A transport layer virtual circuit established between
between two programs for the purpose of communication. two programs for the purpose of communication.
Container file: A file which may contain multiple media streams Container file: A file which may contain multiple media streams
which often constitutes a presentation when played which often constitutes a presentation when played together. The
together. The concept of a container file is not embedded concept of a container file is not embedded in the protocol.
in the protocol. However, RTSP servers may offer aggregate However, RTSP servers may offer aggregate control on the media
control on the media streams within these files. streams within these files.
Continuous media: Data where there is a timing relationship Continuous media: Data where there is a timing relationship between
between source and sink; that is, the sink needs to source and sink; that is, the sink needs to reproduce the timing
reproduce the timing relationship that existed at the relationship that existed at the source. The most common examples
source. The most common examples of continuous media are of continuous media are audio and motion video. Continuous media
audio and motion video. Continuous media can be real-time can be real-time (interactive or conversational), where there is a
(interactive or conversational), where there is a "tight" "tight" timing relationship between source and sink, or streaming
timing relationship between source and sink, or streaming
(playback), where the relationship is less strict. (playback), where the relationship is less strict.
Entity: The information transferred as the payload of a request Entity: The information transferred as the payload of a request or
or response. An entity consists of meta-information in the response. An entity consists of meta-information in the form of
form of entity-header fields and content in the form of an entity-header fields and content in the form of an entity-body, as
entity-body, as described in Section 8. described in Section 8.
Feature-tag: A tag representing a certain set of functionality, Feature-tag: A tag representing a certain set of functionality, i.e.
i.e. a feature. a feature.
IRI: Internationalized Resource Identifier, is the same as an IRI: Internationalized Resource Identifier, is the same as an URI,
URI, with the exception that it allows characters from the with the exception that it allows characters from the whole
whole Universal Character Set (Unicode/ISO 10646), rather Universal Character Set (Unicode/ISO 10646), rather than the US-
than the US-ASCII only. See RFC 3987 [7] for more ASCII only. See [RFC3987] for more information.
information.
Live: Normally used to describe a presentation or session with Live: Normally used to describe a presentation or session with media
media coming from an ongoing event. This generally results coming from an ongoing event. This generally results in the
in the session having an unbound or only loosely defined session having an unbound or only loosely defined duration, and
duration, and sometimes no seek operations are possible. sometimes no seek operations are possible.
Media initialization: Datatype/codec specific initialization. Media initialization: Datatype/codec specific initialization. This
This includes such things as clock rates, color tables, includes such things as clock rates, color tables, etc. Any
etc. Any transport-independent information which is transport-independent information which is required by a client
required by a client for playback of a media stream occurs for playback of a media stream occurs in the media initialization
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 playback.
Media server: The server providing playback services for one or Media server: The server providing playback services for one or more
more media streams. Different media streams within a media streams. Different media streams within a presentation may
presentation may originate from different media servers. A originate from different media servers. A media server may reside
media server may reside on the same host or on a different on the same host or on a different host from which the
host from which the presentation is invoked. presentation is invoked.
Media server indirection: Redirection of a media client to a Media server indirection: Redirection of a media client to a
different media server. different media server.
(Media) stream: A single media instance, e.g., an audio stream (Media) stream: A single media instance, e.g., an audio stream or a
or a video stream as well as a single whiteboard or shared video stream as well as a single whiteboard or shared application
application group. When using RTP, a stream consists of all group. When using RTP, a stream consists of all RTP and RTCP
RTP and RTCP packets created by a source within an RTP packets created by a source within an RTP session.
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 structured sequence of octets matching the syntax defined in
in Section 19 and transmitted over a connection or a Section 19 and transmitted over a connection or a connectionless
connectionless transport. transport.
Non-Aggregated Control: Control of a single media stream. This Non-Aggregated Control: Control of a single media stream. This is
is only possible in RTSP sessions with a single media. only possible in RTSP sessions with a single media.
Participant: Member of a conference. A participant may be a Participant: Member of a conference. A participant may be a
machine, e.g., a playback server. machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the Presentation: A set of one or more streams presented to the client
client as a complete media feed and described by a as a complete media feed and described by a presentation
presentation description as defined below. Presentations description as defined below. Presentations with more than one
with more than one media stream are often handled in RTSP media stream are often handled in RTSP under aggregate control.
under aggregate control.
Presentation description: A presentation description contains Presentation description: A presentation description contains
information about one or more media streams within a information about one or more media streams within a presentation,
presentation, such as the set of encodings, network such as the set of encodings, network addresses and information
addresses and information about the content. Other IETF about the content. Other IETF protocols such as SDP ([RFC4566])
protocols such as SDP (RFC 4566 [1]) use the term "session" use the term "session" for a presentation. The presentation
for a presentation. The presentation description may take description may take several different formats, including but not
several different formats, including but not limited to the limited to the session description protocol format, SDP.
session description protocol format, SDP.
Response: An RTSP response. If an HTTP response is meant, that Response: An RTSP response. If an HTTP response is meant, that is
is indicated explicitly. indicated explicitly.
Request: An RTSP request. If an HTTP request is meant, that is Request: An RTSP request. If an HTTP request is meant, that is
indicated explicitly. indicated explicitly.
Request-URI: The URI used in a request to indicate the resource Request-URI: The URI used in a request to indicate the resource on
on which the request is to be performed. which the request is to be performed.
RTSP agent: Refers to either an RTSP client, an RTSP server, or RTSP agent: Refers to either an RTSP client, an RTSP server, or an
an RTSP Proxy. In this specification, there are many RTSP Proxy. In this specification, there are many capabilities
capabilities that are common to these three entities such that are common to these three entities such as the capability to
as the capability to send requests or receive responses. send requests or receive responses. This term will be used when
This term will be used when describing functionality that describing functionality that is applicable to all three of these
is applicable to all three of these entities. entities.
RTSP session: A stateful abstraction upon which the main control RTSP session: A stateful abstraction upon which the main control
methods of RTSP operate. An RTSP session is a server methods of RTSP operate. An RTSP session is a server entity; it
entity; it is created, maintained and destroyed by the is created, maintained and destroyed by the server. It is
server. It is established by an RTSP server upon the established by an RTSP server upon the completion of a successful
completion of a successful SETUP request (when a 200 OK SETUP request (when a 200 OK response is sent) and is labelled
response is sent) and is labelled with a session identifier with a session identifier at that time. The session exists until
at that time. The session exists until timed out by the timed out by the server or explicitly removed by a TEARDOWN
server or explicitly removed by a TEARDOWN request. An RTSP request. An RTSP session is a stateful entity; an RTSP server
session is a stateful entity; an RTSP server maintains an maintains an explicit session state machine (see Appendix A) where
explicit session state machine (see Appendix A) where most most state transitions are triggered by client requests. The
state transitions are triggered by client requests. The existence of a session implies the existence of state about the
existence of a session implies the existence of state about session's media streams and their respective transport mechanisms.
the session's media streams and their respective transport A given session can have one or more media streams associated with
mechanisms. A given session can have one or more media it. An RTSP server uses the session to aggregate control over
streams associated with it. An RTSP server uses the multiple media streams.
session to aggregate control over multiple media streams.
Transport initialization: The negotiation of transport Transport initialization: The negotiation of transport information
information (e.g., port numbers, transport protocols) (e.g., port numbers, transport protocols) between the client and
between the client and the server. the server.
URI: Universal Resource Identifier, see RFC 3986 [8]. The URIs URI: Universal Resource Identifier, see [RFC3986]. The URIs used in
used in RTSP are generally URLs as they give a location for RTSP are generally URLs as they give a location for the resource.
the resource. As URLs are a subset of URIs, they will be As URLs are a subset of URIs, they will be referred to as URIs to
referred to as URIs to cover also the cases when an RTSP cover also the cases when an RTSP URI would not be an URL.
URI would not be an URL.
URL: Universal Resource Locator, is an URI which identifies the URL: Universal Resource Locator, is an URI which identifies the
resource through its primary access mechanism, rather than resource through its primary access mechanism, rather than
identifying the resource by name or by some other identifying the resource by name or by some other attribute(s) of
attribute(s) of that resource. that resource.
1.5 Protocol Properties 1.5. Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to Extendable: New methods and parameters can be easily added to RTSP.
RTSP.
Easy to parse: RTSP can be parsed by standard HTTP or MIME Easy to parse: RTSP can be parsed by standard HTTP or MIME parsers.
parsers.
Secure: RTSP re-uses web security mechanisms, either at the Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, RFC 4346 [9]) or within the protocol transport level (TLS, [RFC4346]) or within the protocol itself.
itself. All HTTP authentication mechanisms such as basic All HTTP authentication mechanisms such as basic ([RFC2616]) and
(RFC 2616 [3]) and digest authentication (RFC 2617 [10]) digest authentication ([RFC2617]) are directly applicable.
are directly applicable.
Transport-independent: RTSP does not preclude the use of Transport-independent: RTSP does not preclude the use of unreliable
unreliable datagram protocol (UDP) (RFC 768 [11]) as it datagram protocol (UDP) ([RFC0768]) as it would be possible to
would be possible to implement application-level implement application-level reliability. The use of a
reliability. The use of a connectionless datagram protocol connectionless datagram protocol such as UDP requires additional
such as UDP requires additional definition that may be definition that may be provided as extensions to the core RTSP
provided as extensions to the core RTSP specification. The specification. The reliable stream protocol TCP ([RFC0793]) and
reliable stream protocol TCP (RFC 793 [12]) and the secured the secured reliable stream protocol TLS over TCP [RFC4346] are
reliable stream protocol TLS over TCP [9] are the currently the currently defined transport protocols for RTSP messages.
defined transport protocols for RTSP messages.
Media-delivery protocol independent: The operation of RTSP does Media-delivery protocol independent: The operation of RTSP does not
not depend on the transport mechanism used to carry depend on the transport mechanism used to carry continuous media.
continuous media. While most real-time media will use RTP While most real-time media will use RTP as a transport protocol,
as a transport protocol, RTSP does not preclude the use of RTSP does not preclude the use of other protocols such as MPEG-2
other protocols such as MPEG-2 [27]. The use of other [ISO.13818-1.2000]. The use of other protocols requires
protocols requires additional definition that may be additional definition that may be provided as extensions to the
provided as extensions to the core RTSP specification. core RTSP specification.
Multi-server capable: Each media stream within a presentation Multi-server capable: Each media stream within a presentation can
can reside on a different server. The client automatically reside on a different server. The client automatically
establishes several concurrent control sessions with the establishes several concurrent control sessions with the different
different media servers. Media synchronization in those media servers. Media synchronization in those cases is performed
cases is performed at the transport level. at the transport level.
Separation of stream control and conference initiation: Stream Separation of stream control and conference initiation: Stream
control is divorced from inviting a media server to a control is divorced from inviting a media server to a conference.
conference. In particular, SIP [28] or H.323 [29] may be In particular, SIP [RFC3261] or H.323 [ITU.H323.1996] may be used
used to invite a server to a conference; however, the exact to invite a server to a conference; however, the exact procedures
procedures are unspecified. are unspecified.
Suitable for professional applications: RTSP supports frame- Suitable for professional applications: RTSP supports frame- level
level accuracy through SMPTE time stamps to allow remote accuracy through SMPTE time stamps to allow remote digital
digital editing. editing.
Presentation description neutral: The protocol does not impose a Presentation description neutral: The protocol does not impose a
particular presentation description or metafile format and particular presentation description or metafile format and can
can convey the type of format to be used. However, the convey the type of format to be used. However, the presentation
presentation description is required to contain at least description is required to contain at least one RTSP URI.
one RTSP URI.
Proxy and firewall friendly: The protocol should be readily Proxy and firewall friendly: The protocol should be readily handled
handled by both application and transport-layer (SOCKS by both application and transport-layer (SOCKS [RFC1961])
[30]) firewalls. A firewall may need to understand the firewalls. A firewall may need to understand the SETUP method to
SETUP method to open a "hole" for the media stream. open a "hole" for the media stream.
HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so HTTP-friendly: Where sensible, RTSP reuses HTTP concepts, so that
that the existing infrastructure can be reused. This the existing infrastructure can be reused. This infrastructure
infrastructure includes PICS (Platform for Internet Content includes PICS (Platform for Internet Content Selection
Selection [31,32]) for associating labels with content. [W3C.REC-PICS-services] [W3C.REC-PICS-labels]) for associating
However, RTSP does not just add methods to HTTP since labels with content. However, RTSP does not just add methods to
controlling continuous media requires server state in most HTTP since controlling continuous media requires server state in
cases. most cases.
Appropriate server control: If a client can start a stream, it Appropriate server control: If a client can start a stream, it needs
needs to be able to stop a stream. Servers should not start to be able to stop a stream. Servers should not start streaming
streaming to clients in such a way that clients cannot stop to clients in such a way that clients cannot stop the stream.
the stream.
Transport negotiation: The client can negotiate the transport Transport negotiation: The client can negotiate the transport method
method prior to actually needing to process a continuous prior to actually needing to process a continuous media stream.
media stream.
1.6 Extending RTSP 1.6. Extending RTSP
Since not all media servers have the same functionality, media Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For servers by necessity will support different sets of requests. For
example: example:
o A server may not be capable of seeking (absolute positioning) o A server may not be capable of seeking (absolute positioning) if
if it is to support live events only. it is to support live events only.
o Some servers may not support setting stream parameters and o Some servers may not support setting stream parameters and thus
thus not support GET_PARAMETER and SET_PARAMETER. not support GET_PARAMETER and SET_PARAMETER.
o Some server may support an RTSP extension. o Some server may support an RTSP extension.
It is up to the creators of presentation descriptions not to ask the It is up to the creators of presentation descriptions not to ask the
impossible of a server. This situation is similar in HTTP/1.1 [3], impossible of a server. This situation is similar in HTTP/1.1
where the methods described in [H19.5] are not likely to be supported [RFC2616], where the methods described in [H19.5] are not likely to
across all servers. be supported across all servers.
RTSP can be extended in three ways, listed here in order of the RTSP can be extended in three ways, listed here in order of the
magnitude of changes supported: magnitude of changes supported:
o Existing methods can be extended with new parameters, e.g. o Existing methods can be extended with new parameters, e.g.
headers, as long as these parameters can be safely ignored by headers, as long as these parameters can be safely ignored by the
the recipient. If the client needs negative acknowledgement recipient. If the client needs negative acknowledgement when a
when a method extension is not supported, a tag corresponding method extension is not supported, a tag corresponding to the
to the extension may be added in the field of the Require or extension may be added in the field of the Require or Proxy-
Proxy-Require headers (see Section 14.37). Require headers (see Section 14.31).
o New methods can be added. If the recipient of the message does o New methods can be added. If the recipient of the message does
not understand the request, it MUST respond with error code not understand the request, it MUST respond with error code 501
501 (Not Implemented) so that the sender can avoid using this (Not Implemented) so that the sender can avoid using this method
method again. A client may also use the OPTIONS method to again. A client may also use the OPTIONS method to inquire about
inquire about methods supported by the server. The server MUST methods supported by the server. The server MUST list the methods
list the methods it supports using the Public response header. it supports using the Public response header.
o A new version of the protocol can be defined, allowing almost o A new version of the protocol can be defined, allowing almost all
all aspects (except the position of the protocol version aspects (except the position of the protocol version number) to
number) to change. A new version of the protocol MUST be change. A new version of the protocol MUST be registered through
registered through an IETF standard track document. an IETF standard track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of this available when performing a request. For detailed explanation of
see section 10. this see Section 10.
1.7 Overall Operation 1.7. Overall Operation
Each presentation and media stream is identified by an RTSP URI. The Each presentation and media stream is identified by an RTSP URI. The
overall presentation and the properties of the media the presentation overall presentation and the properties of the media the presentation
is composed of are defined by a presentation description file, the is composed of are defined by a presentation description file, the
format of which is outside the scope of this specification. The format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored HTTP or other means such as email and may not necessarily be stored
on the media server. on the media server.
For the purposes of this specification, a presentation description is For the purposes of this specification, a presentation description is
skipping to change at page 18, line 25 skipping to change at page 17, line 16
handling that particular media stream and names the stream stored on handling that particular media stream and names the stream stored on
that server. Several media streams can be located on different that server. Several media streams can be located on different
servers; for example, audio and video streams can be split across servers; for example, audio and video streams can be split across
servers for load sharing. The description also enumerates which servers for load sharing. The description also enumerates which
transport methods the server is capable of. transport methods the server is capable of.
Besides the media parameters, the network destination address and Besides the media parameters, the network destination address and
port need to be determined. Several modes of operation can be port need to be determined. Several modes of operation can be
distinguished: distinguished:
Unicast: The media is transmitted to the source of the RTSP Unicast: The media is transmitted to the source of the RTSP request
request or the requested destination, with the port number or the requested destination, with the port number chosen by the
chosen by the client. Alternatively, the media is client. Alternatively, the media is transmitted on the same
transmitted on the same reliable stream as RTSP. reliable stream as RTSP.
Multicast, server chooses address: The media server picks the Multicast, server chooses address: The media server picks the
multicast address and port. This is the typical case for a multicast address and port. This is the typical case for a live
live or near-media-on-demand transmission. or near-media-on-demand transmission.
Multicast, client chooses address: If the server is to Multicast, client chooses address: If the server is to participate
participate in an existing multicast conference, the in an existing multicast conference, the multicast address, port
multicast address, port and encryption key are given by the and encryption key are given by the conference description,
conference description, established by means outside the established by means outside the scope of this specification, for
scope of this specification, for example by a SIP created example by a SIP created conference.
conference.
1.8 RTSP States 1.8. RTSP States
RTSP controls a stream which may be sent via a separate protocol, RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may be independent of the control channel. For example, RTSP control may be
transported on a TCP connection while the media data is conveyed via transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime a single received by the media server. Also, during its lifetime a single
media stream may be controlled by RTSP requests issued sequentially media stream may be controlled by RTSP requests issued sequentially
on different TCP connections. Therefore, the server needs to maintain on different TCP connections. Therefore, the server needs to
"session state" to be able to correlate RTSP requests with a stream. maintain "session state" to be able to correlate RTSP requests with a
The state transitions are described in Appendix A. stream. The state transitions are described in Appendix A.
Many methods in RTSP do not contribute to state. However, the Many methods in RTSP do not contribute to state. However, the
following play a central role in defining the allocation and usage of following play a central role in defining the allocation and usage of
stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and stream resources on the server: SETUP, PLAY, PAUSE, REDIRECT, and
TEARDOWN. TEARDOWN.
SETUP: Causes the server to allocate resources for a stream and SETUP: Causes the server to allocate resources for a stream and
create an RTSP session. create an RTSP session.
PLAY: Starts data transmission on a stream allocated via SETUP. PLAY: Starts data transmission on a stream allocated via SETUP.
PAUSE: Temporarily halts a stream without freeing server PAUSE: Temporarily halts a stream without freeing server resources.
resources.
REDIRECT: Indicates that the session should be moved to a new REDIRECT: Indicates that the session should be moved to a new server
server or location or location
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field RTSP methods that contribute to state use the Session header field
(Section 14.42) to identify the RTSP session whose state is being (Section 14.43) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to manipulated. The server generates session identifiers in response to
SETUP requests (Section 11.3). SETUP requests (Section 11.3).
1.9 Relationship with Other Protocols 1.9. Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content interact with HTTP in that the initial contact with streaming content
will often be made through a web page. The current protocol will often be made through a web page. The current protocol
specification aims to allow different hand-off points between a web specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the server and the media server implementing RTSP. For example, the
presentation description can be retrieved using HTTP or RTSP, which presentation description can be retrieved using HTTP or RTSP, which
reduces round trips in web-browser-based scenarios, yet also allows reduces round trips in web-browser-based scenarios, yet also allows
for stand alone RTSP servers and clients which do not rely on HTTP at for stand alone RTSP servers and clients which do not rely on HTTP at
all. However, RTSP differs fundamentally from HTTP in that most data all. However, RTSP differs fundamentally from HTTP in that most data
delivery takes place out-of-band in a different protocol. HTTP is an delivery takes place out-of-band in a different protocol. HTTP is an
asymmetric protocol where the client issues requests and the server asymmetric protocol where the client issues requests and the server
responds. In RTSP, both the media client and media server can issue responds. In RTSP, both the media client and media server can issue
requests. RTSP requests are also stateful; they may set parameters requests. RTSP requests are also stateful; they may set parameters
and continue to control a media stream long after the request has and continue to control a media stream long after the request has
been acknowledged. been acknowledged.
Re-using HTTP functionality has advantages in at least two Re-using HTTP functionality has advantages in at least two areas,
areas, namely security and proxies. The requirements are namely security and proxies. The requirements are very similar, so
very similar, so having the ability to adopt HTTP work on having the ability to adopt HTTP work on caches, proxies and
caches, proxies and authentication is valuable. authentication is valuable.
RTSP assumes the existence of a presentation description format that RTSP assumes the existence of a presentation description format that
can express both static and temporal properties of a presentation can express both static and temporal properties of a presentation
containing several media streams. Session Description Protocol (SDP) containing several media streams. Session Description Protocol (SDP)
[1] is generally the format of choice; however, RTSP is not bound to [RFC4566] is generally the format of choice; however, RTSP is not
it. For data delivery, most real-time media will use RTP as a bound to it. For data delivery, most real-time media will use RTP as
transport protocol. While RTSP works well with RTP, it is not tied to a transport protocol. While RTSP works well with RTP, it is not tied
RTP. to RTP.
2 RTSP Use Cases 2. RTSP Use Cases
This section describes the most important and considered use cases This section describes the most important and considered use cases
for RTSP. They are listed in descending order of importance in for RTSP. They are listed in descending order of importance in
regards to ensuring that all necessary functionality is present. regards to ensuring that all necessary functionality is present.
This specification only fully supports usage of the two first. Also This specification only fully supports usage of the two first. Also
in these first two cases, there are special cases or exceptions that in these first two cases, there are special cases or exceptions that
are not supported without extensions, e.g. the redirection of media are not supported without extensions, e.g. the redirection of media
to another address than the controlling entity. to another address than the controlling entity.
2.1 On-demand Playback of Stored Content 2.1. On-demand Playback of Stored Content
An RTSP capable server stores content suitable for being streamed to An RTSP capable server stores content suitable for being streamed to
a client. A client desiring playback of any of the stored content a client. A client desiring playback of any of the stored content
uses RTSP to set up the media transport required to deliver the uses RTSP to set up the media transport required to deliver the
desired content. RTSP is then used to initiate, halt and manipulate desired content. RTSP is then used to initiate, halt and manipulate
the actual transmission (playout) of the content. RTSP is also the actual transmission (playout) of the content. RTSP is also
required to provide necessary description and synchronization required to provide necessary description and synchronization
information for the content. information for the content.
The above high level description can be broken down into a number of The above high level description can be broken down into a number of
functions that RTSP needs to be capable of. functions that RTSP needs to be capable of.
Presentation Description: Provide initialization information Presentation Description: Provide initialization information about
about the presentation (content); for example, which media the presentation (content); for example, which media codecs are
codecs are needed for the content. Other information that needed for the content. Other information that is important
is important includes the number of media stream the includes the number of media stream the presentation contains,
presentation contains, the transport protocols used for the the transport protocols used for the media streams, and
media streams, and identifiers for these media streams. identifiers for these media streams. This information is
This information is required before setup of the content is required before setup of the content is possible and to
possible and to determine if the client is even capable of determine if the client is even capable of using the content.
using the content.
This information need not be sent using RTSP; other This information need not be sent using RTSP; other external
external protocols can be used to transmit the transport protocols can be used to transmit the transport presentation
presentation descriptions. Two good examples are the use of descriptions. Two good examples are the use of HTTP [RFC2616]
HTTP [3] or email to fetch or receive presentation or email to fetch or receive presentation descriptions like SDP
descriptions like SDP [1]. [RFC4566]
Setup: Set up some or all of the media streams in a Setup: Set up some or all of the media streams in a presentation.
presentation. The setup itself consist of selecting the The setup itself consist of selecting the protocol for media
protocol for media transport and the necessary parameters transport and the necessary parameters for the protocol, like
for the protocol, like addresses and ports. addresses and ports.
Control of Transmission: After the necessary media streams have Control of Transmission: After the necessary media streams have been
been established the client can request the server to start established the client can request the server to start
transmitting the content. The client must be allowed to transmitting the content. The client must be allowed to start
start or stop the transmission of the content at arbitrary or stop the transmission of the content at arbitrary times.
times. The client must also be able to start the The client must also be able to start the transmission at any
transmission at any point in the timeline of the point in the timeline of the presentation.
presentation.
Synchronization: For media transport protocols like RTP [16] it Synchronization: For media transport protocols like RTP [RFC3550] it
might be beneficial to carry synchronization information might be beneficial to carry synchronization information within
within RTSP. This may be due to either the lack of inter- RTSP. This may be due to either the lack of inter-media
media synchronization within the protocol itself, or the synchronization within the protocol itself, or the potential
potential delay before the synchronization is established delay before the synchronization is established (which is the
(which is the case for RTP when using RTCP). case for RTP when using RTCP).
Termination Terminate the established contexts. Termination: Terminate the established contexts.
For this use case there are a number of assumptions about how it For this use case there are a number of assumptions about how it
works. These are: works. These are:
On-Demand content: The content is stored at the server and can On-Demand content: The content is stored at the server and can be
be accessed at any time during a time period when it is accessed at any time during a time period when it is intended
intended to be available. to be available.
Independent sessions: A server is capable of serving a number of Independent sessions: A server is capable of serving a number of
clients simultaneously, including from the same piece of clients simultaneously, including from the same piece of
content at different points in that presentations time- content at different points in that presentations time-line.
line.
Unicast Transport: Content for each individual client is Unicast Transport: Content for each individual client is transmitted
transmitted to them using unicast traffic. to them using unicast traffic.
It is also possible to redirect the media traffic to a different It is also possible to redirect the media traffic to a different
destination than that of the entity controlling the traffic. However, destination than that of the entity controlling the traffic.
allowing this without appropriate mechanisms for checking that the However, allowing this without appropriate mechanisms for checking
destination approves of this allows for distributed denial of service that the destination approves of this allows for distributed denial
attacks (DDoS). of service attacks (DDoS).
2.2 Unicast distribution of Live Content 2.2. Unicast distribution of Live Content
This use cases is similar to the above on-demand content case (see This use cases is similar to the above on-demand content case (see
section 2.1; the difference is the nature of the content itself. Section 2.1) the difference is the nature of the content itself.
Live content is continuously distributed as it becomes available from Live content is continuously distributed as it becomes available from
a source; i.e., the main difference from on-demand is that one starts a source; i.e., the main difference from on-demand is that one starts
distributing content before the end of it has become available to the distributing content before the end of it has become available to the
server. server.
In many cases the consumer of live content is only interested in In many cases the consumer of live content is only interested in
consuming what is actually happens "now"; i.e., very similar to consuming what is actually happens "now"; i.e., very similar to
broadcast TV. However in this case it is assumed that there exist no broadcast TV. However in this case it is assumed that there exist no
broadcast or multicast channel to the users, and instead the server broadcast or multicast channel to the users, and instead the server
functions as a distribution node, sending the same content to functions as a distribution node, sending the same content to
multiple receivers, using unicast traffic between server and client. multiple receivers, using unicast traffic between server and client.
This unicast traffic and the transport parameters are individually This unicast traffic and the transport parameters are individually
negotiated for each receiving client. negotiated for each receiving client.
Another aspect of live content is that it often has a very limited Another aspect of live content is that it often has a very limited
time of availability, as it is only is available for the duration of time of availability, as it is only is available for the duration of
the event the content covers. An example of such a live content could the event the content covers. An example of such a live content
be a music concert which lasts 2 hour and starts at a predetermined could be a music concert which lasts 2 hour and starts at a
time. Thus there is need to announce when and for how long the live predetermined time. Thus there is need to announce when and for how
content is available. long the live content is available.
2.3 On-demand Playback using Multicast 2.3. On-demand Playback using Multicast
It is possible to use RTSP to request that media be delivered to a It is possible to use RTSP to request that media be delivered to a
multicast group. The entity setting up the session (the controller) multicast group. The entity setting up the session (the controller)
will then control when and what media is delivered to the group. This will then control when and what media is delivered to the group.
use case has some potential for denial of service attacks by flooding This use case has some potential for denial of service attacks by
a multicast group. Therefore, a mechanism is needed to indicate that flooding a multicast group. Therefore, a mechanism is needed to
the group actually accepts the traffic from the RTSP server. indicate that the group actually accepts the traffic from the RTSP
server.
An open issue in this use case is how one ensures that all receivers An open issue in this use case is how one ensures that all receivers
listening to the multicast or broadcast receives the session listening to the multicast or broadcast receives the session
presentation configuring the receivers. presentation configuring the receivers.
2.4 Inviting an RTSP server into a conference 2.4. Inviting an RTSP server into a conference
If one has an established conference or group session, it is possible If one has an established conference or group session, it is possible
to have an RTSP server distribute media to the whole group. to have an RTSP server distribute media to the whole group.
Transmission to the group is simplest when controlled by a single Transmission to the group is simplest when controlled by a single
participant or leader of the conference. Shared control might be participant or leader of the conference. Shared control might be
possible, but would require further investigation and possibly possible, but would require further investigation and possibly
extensions. extensions.
This use case assumes that there exists either multicast or a This use case assumes that there exists either multicast or a
conference focus that redistribute media to all participants. conference focus that redistribute media to all participants.
This use case is intended to be able to handle the following This use case is intended to be able to handle the following
scenario: A conference leader or participant (hereafter called the scenario: A conference leader or participant (hereafter called the
controller) has some pre-stored content on an RTSP server that he controller) has some pre-stored content on an RTSP server that he
wants to share with the group. The controller sets up an RTSP session wants to share with the group. The controller sets up an RTSP
at the streaming server for this content and retrieves the session session at the streaming server for this content and retrieves the
description for the content. The destination for the media content session description for the content. The destination for the media
is set to the shared multicast group or conference focus. When content is set to the shared multicast group or conference focus.
desired by the controller, he/she can start and stop the transmission When desired by the controller, he/she can start and stop the
of the media to the conference group. transmission of the media to the conference group.
There are several issues with this use case that are not solved by There are several issues with this use case that are not solved by
this core specification for RTSP: this core specification for RTSP:
o To avoid an RTSP server from being an unknowing participant in Denial of service: To avoid an RTSP server from being an unknowing
a denial of service attack the server needs to be able to participant in a denial of service attack the server needs to
verify the destination's acceptance of the media. Such a be able to verify the destination's acceptance of the media.
mechanism to verify the approval of received media does not Such a mechanism to verify the approval of received media does
yet exist; instead, only policies can be used, which can be not yet exist; instead, only policies can be used, which can be
made to work in controlled environments. made to work in controlled environments.
o To enable a media receiver to correctly decode the content the Distributing the presentation description to all participants in the
media configuration information needs to be distributed group: To enable a media receiver to correctly decode the content
the media configuration information needs to be distributed
reliably to all participants. This will most likely require reliably to all participants. This will most likely require
support from an external protocol. support from an external protocol.
o If it is desired to pass control of the RTSP session between Passing control of the session: If it is desired to pass control of
the participants, some support will be required by an external the RTSP session between the participants, some support will be
protocol to exchange state information and possibly floor required by an external protocol to exchange state information
control of who is controlling the RTSP session. and possibly floor control of who is controlling the RTSP
session.
If there interest in this use case, further work is required on the If there interest in this use case, further work is required on the
necessary extensions. necessary extensions.
2.5 Live Content using Multicast 2.5. Live Content using Multicast
This use case in its simplest form does not require any use of RTSP This use case in its simplest form does not require any use of RTSP
at all; this is what multicast conferences being announced with SAP at all; this is what multicast conferences being announced with SAP
and SDP are intended to handle. However in use cases where more and SDP are intended to handle. However in use cases where more
advanced features like access control to the multicast session are advanced features like access control to the multicast session are
desired, RTSP could be used for session establishment. desired, RTSP could be used for session establishment.
A client desiring to join a live multicasted media session with A client desiring to join a live multicasted media session with
cryptographic (encryption) access control could use RTSP in the cryptographic (encryption) access control could use RTSP in the
following way. The source of the session announces the session and following way. The source of the session announces the session and
gives all interested an RTSP URI. The client connects to the server gives all interested an RTSP URI. The client connects to the server
and requests the presentation description, allowing configuration for and requests the presentation description, allowing configuration for
reception of the media. In this step it is possible for the client to reception of the media. In this step it is possible for the client
use secured transport and any desired level of authentication; for to use secured transport and any desired level of authentication; for
example, for billing or access control. An RTSP link also allows for example, for billing or access control. An RTSP link also allows for
load balancing between multiple servers. load balancing between multiple servers.
If these were the only goals, they could be achieved by simply using If these were the only goals, they could be achieved by simply using
HTTP. However, for cases where the sender likes to keep track of HTTP. However, for cases where the sender likes to keep track of
each individual receiver of a session, and possibly use the session each individual receiver of a session, and possibly use the session
as a side channel for distributing key-updates or other information as a side channel for distributing key-updates or other information
on a per-receiver basis, and the full set of receivers is not know on a per-receiver basis, and the full set of receivers is not know
prior to the session start, the state establishment that RTSP prior to the session start, the state establishment that RTSP
provides can be beneficial. In this case a client would establish an provides can be beneficial. In this case a client would establish an
RTSP session to the multicast group. The RTSP server will not RTSP session to the multicast group. The RTSP server will not
transmit any media, but instead will point to the multicast group. transmit any media, but instead will point to the multicast group.
The client and server will be able to keep the session alive for as The client and server will be able to keep the session alive for as
long as the receiver participates in the session thus enabling, for long as the receiver participates in the session thus enabling, for
example, the server to push updates to the client. example, the server to push updates to the client.
This use case will most likely not be able to be implemented without This use case will most likely not be able to be implemented without
some extensions to the server-to-client push mechanism. Here a method some extensions to the server-to-client push mechanism. Here a
like ANNOUNCE (see RFC 2326 [25] might be suitable; however, it will method like ANNOUNCE (see [RFC2326]) might be suitable; however, it
require a RTSP extension to revive the method. will require a RTSP extension to revive the method.
3 Protocol Parameters 3. Protocol Parameters
3.1 RTSP Version 3.1. RTSP Version
HTTP specification section [H3.1] applies, with "HTTP" replaced by HTTP specification section [H3.1] applies, with "HTTP" replaced by
"RTSP". This specification defines version 2.0 of RTSP. "RTSP". This specification defines version 2.0 of RTSP.
3.2 RTSP IRI and URI 3.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" and
"rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
defined in RTSP 1.0. The "rtspu" scheme indicates transport of the defined in RTSP 1.0. The "rtspu" scheme indicates transport of the
RTSP messages over unreliable transport (UDP). The syntax of "rtsp" RTSP messages over unreliable transport (UDP). The syntax of "rtsp"
and "rtsps" URIs has been changed from RTSP 1.0. and "rtsps" URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [7] that This specification also defines the format of the RTSP IRI [RFC3987]
can be used as RTSP resource identifiers and locators, in web pages, that can be used as RTSP resource identifiers and locators, in web
user interfaces, on paper, etc. However, the RTSP request message pages, user interfaces, on paper, etc. However, the RTSP request
format only allows usage of the absolute URI format. The RTSP IRI message format only allows usage of the absolute URI format. The
format SHALL use the rules and transformation for IRIs defined in RFC RTSP IRI format SHALL use the rules and transformation for IRIs
3987 [7]. This way RTSP 2.0 URIs for request can be produced from an defined in [RFC3987]. This way RTSP 2.0 URIs for request can be
RTSP IRI. produced from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
generic syntax defined in RFC 3986 [8] and RFC 3987 [7]: generic syntax defined in [RFC3986] and RFC [RFC3987]:
o An absolute URI requires the authority part; i.e., a host o An absolute URI requires the authority part; i.e., a host identity
identity must be provided. must be provided.
o Parameters in the path element are prefixed with the reserved o Parameters in the path element are prefixed with the reserved
separator ";". separator ";".
The RTSP URI and IRI is case sensitive, with the exception of those The RTSP URI and IRI is case sensitive, with the exception of those
parts that RFC 3986 [8] and RFC 3987 [7] defines as case-insensitive; parts that [RFC3986] and [RFC3987] defines as case-insensitive; for
for example, the scheme and host part. example, the scheme and host part.
The fragment identifier is used as defined in sections 3.5 and 4.3 of The fragment identifier is used as defined in sections 3.5 and 4.3 of
[8], i.e. the fragment is to be stripped from the URI by the [RFC3986], i.e. the fragment is to be stripped from the URI by the
requestor and not included in the request. The user agent also needs requestor and not included in the request. The user agent also needs
to interpret the value of the fragment based on the media type the to interpret the value of the fragment based on the media type the
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requestor's (usually the server) specific. The query is, from the requestor's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
The URI scheme "rtsp" requires that commands are issued via a The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme reliable protocol (within the Internet, TCP), while the scheme
"rtsps" identifies a reliable transport using secure transport (TLS "rtsps" identifies a reliable transport using secure transport (TLS
[9], see Section 18). [RFC4346], see Section (Section 18).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 SHALL be used. For the scheme part of the URI port number 554 SHALL be used. For the scheme
"rtsps", the TCP port 322 is registered and SHALL be assumed. "rtsps", the TCP port 322 is registered and SHALL be assumed.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs identifier, using the character set and escape conventions of URIs
(RFC 3986 [8]). URIs may refer to a stream or an aggregate of (RFC 3986 [RFC3986]). URIs may refer to a stream or an aggregate of
streams; i.e., a presentation. Accordingly, requests described in streams; i.e., a presentation. Accordingly, requests described in
Section 11 can apply to either the whole presentation or an Section (Section 11) can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations, and vice methods can only be applied to streams, not presentations, and vice
versa. versa.
For example, the RTSP URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
which can be controlled via RTSP requests issued over a TCP which can be controlled via RTSP requests issued over a TCP
connection to port 554 of host media.example.com connection to port 554 of host media.example.com.
Also, the RTSP URI: Also, the RTSP URI:
rtsp://media.example.com:554/twister rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio identifies the presentation "twister", which may be composed of audio
and video streams, but could also be something else like a random and video streams, but could also be something else like a random
media redirector. media redirector.
This does not imply a standard way to reference streams in This does not imply a standard way to reference streams in URIs.
URIs. The presentation description defines the hierarchical The presentation description defines the hierarchical
relationships in the presentation and the URIs for the relationships in the presentation and the URIs for the individual
individual streams. A presentation description may name a streams. A presentation description may name a stream "a.mov" and
stream "a.mov" and the whole presentation "b.mov". the whole presentation "b.mov".
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 This decoupling also allows presentation descriptions to be used
used with non-RTSP media control protocols simply by with non-RTSP media control protocols simply by replacing the
replacing the scheme in the URI. scheme in the URI.
3.3 Session Identifiers 3.3. Session Identifiers
Session identifiers are strings of any arbitrary length. A session Session identifiers are strings of any arbitrary length. A session
identifier MUST be chosen randomly and MUST be at least eight identifier MUST be chosen randomly and MUST be at least eight
characters long to make guessing it more difficult. (See Section 20.) characters long to make guessing it more difficult. (See
Section 20.)
3.4 SMPTE Relative Timestamps 3.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 is
"SMPTE 30 drop" format, with frame rate is 29.97 frames per second. with the origin at the start of the clip. The default smpte format
Other SMPTE codes MAY be supported (such as "SMPTE 25") through the is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
use of alternative use of "smpte-type". For SMPTE 30, the "frames" second. Other SMPTE codes MAY be supported (such as "SMPTE 25")
field in the time value can assume the values 0 through 29. The through the use of alternative use of "smpte-type". For SMPTE 30,
difference between 30 and 29.97 frames per second is handled by the "frames" field in the time value can assume the values 0 through
dropping the first two frame indices (values 00 and 01) of every 29. The difference between 30 and 29.97 frames per second is handled
by dropping the first two frame indices (values 00 and 01) of every
minute, except every tenth minute. If the frame and the subframe minute, except every tenth minute. If the frame and the subframe
values are zero, they may be omitted. Subframes are measured in one- values are zero, they may be omitted. Subframes are measured in one-
hundredth of a frame. hundredth of a frame.
Examples: Examples:
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
3.5 Normal Play Time 3.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) [33]. The timestamp consists of with the Network Time Protocol (NTP) [RFC1305]. The timestamp
a decimal fraction. The part left of the decimal may be expressed in consists of a decimal fraction. The part left of the decimal may be
either seconds or hours, minutes, and seconds. The part right of the expressed in either seconds or hours, minutes, and seconds. The part
decimal point measures fractions of a second. right of the decimal point measures 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. The special constant "now" is defined as the values are not defined. The special constant "now" is defined as the
current instant of a live event. It MAY only be used for live events, current instant of a live event. It MAY only be used for live
and SHALL NOT be used for on-demand (i.e., non-live) content. events, and SHALL NOT be used for on-demand (i.e., non-live) content.
NPT is defined as in DSM-CC [34]: "Intuitively, NPT is the clock the NPT is defined as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is
viewer associates with a program. It is often digitally displayed on the clock the viewer associates with a program. It is often
a VCR. NPT advances normally when in normal play mode (scale = 1), digitally displayed on a VCR. NPT advances normally when in normal
advances at a faster rate when in fast scan forward (high positive play mode (scale = 1), advances at a faster rate when in fast scan
scale ratio), decrements when in scan reverse (high negative scale forward (high positive scale ratio), decrements when in scan reverse
ratio) and is fixed in pause mode. NPT is (logically) equivalent to (high negative scale ratio) and is fixed in pause mode. NPT is
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 [35]. The npt-sec notation The syntax conforms to ISO 8601 [ISO.8601.2000]. The npt-sec
is optimized for automatic generation, the npt-hhmmss notation is optimized for automatic generation, the npt-hhmmss
notation for consumption by human readers. The "now" notation for consumption by human readers. The "now" constant
constant allows clients to request to receive the live feed allows clients to request to receive the live feed rather than the
rather than the stored or time-delayed version. This is stored or time-delayed version. This is needed since neither
needed since neither absolute time nor zero time are absolute time nor zero time are appropriate for this case.
appropriate for this case.
3.6 Absolute Time 3.6. Absolute Time
Absolute time is expressed as ISO 8601 [35] timestamps, using UTC Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
(GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
3.7 Feature-tags 3.7. Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require (Section 14.37), Proxy-Require RTSP. These tags are used in Require ( (Section 14.37)), Proxy-
(Section 14.31), Proxy-Supported (Section 14.32), Unsupported Require (Section 14.31), Proxy-Supported ( (Section 14.32)),
(Section 14.46), and Supported (Section 14.43) header fields. Unsupported ( (Section 14.46)), and header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies they applies too. servers or proxies they applies too.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA) (see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 21). IANA Section 21).
The usage of feature-tags is further described in section 10 that The usage of feature-tags is further described in Section 10 that
deals with capability handling. deals with capability handling.
3.8 Entity Tags 3.8. Entity Tags
Entity tags are opaque strings that are used to compare two entities Entity tags are opaque strings that are used to compare two entities
from the same resource, for example in caches or to optimize setup from the same resource, for example in caches or to optimize setup
after a redirect. Further explanation is present in [H3.11]. For an after a redirect. Further explanation is present in [H3.11]. For an
explanation of how to compare entity tags see [H13.3]. Entity tags explanation of how to compare entity tags see [H13.3]. Entity tags
can be carried in the ETag header (see section 14.21) or in SDP (see can be carried in the ETag header (see Section 14.21) or in SDP (see
section C.1.9). Appendix C.1.9).
Entity tags are used in RTSP to make some methods conditional. The Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see methods are made conditional through the inclusion of headers, see
14.24 and 14.26. Note that RTSP entity tags apply to the complete Section 14.24 and Section 14.26. Note that RTSP entity tags apply to
presentation; i.e., both the session description and the individual the complete presentation; i.e., both the session description and the
media streams. Thus entity tags can be used to verify at setup time individual media streams. Thus entity tags can be used to verify at
after a redirect that the same session description applies to the setup time after a redirect that the same session description applies
media at the new location using the If-Match header. to the media at the new location using the If-Match header.
4 RTSP Message 4. RTSP Message
RTSP is a text-based protocol and uses the ISO 10646 character set in RTSP is a text-based protocol and uses the ISO 10646 character set in
UTF-8 encoding (RFC 3629 [13]). Lines SHALL be terminated by CRLF. UTF-8 encoding (RFC 3629 [RFC3629]). Lines SHALL be terminated by
CRLF.
Text-based protocols make it easier to add optional Text-based protocols make it easier to add optional parameters in
parameters in a self-describing manner. Since the number of a self-describing manner. Since the number of parameters and the
parameters and the frequency of commands is low, processing frequency of commands is low, processing efficiency is not a
efficiency is not a concern. Text-based protocols, if done concern. Text-based protocols, if done carefully, also allow easy
carefully, also allow easy implementation of research implementation of research prototypes in scripting languages such
prototypes in scripting languages such as Tcl, Visual Basic as Tcl, Visual Basic and Perl.
and Perl.
The ISO 10646 character set avoids tricky character set switching, The ISO 10646 character set avoids tricky character set switching,
but is invisible to the application as long as US-ASCII is being but is invisible to the application as long as US-ASCII is being
used. This is also the encoding used for RTCP. ISO 8859-1 translates used. This is also the encoding used for RTCP [RFC3550]. ISO 8859-1
directly into Unicode with a high-order octet of zero. ISO 8859-1 translates directly into Unicode with a high-order octet of zero.
characters with the most-significant bit set are represented as ISO 8859-1 characters with the most-significant bit set are
1100001x 10xxxxxx. (See RFC 3629 [13]) represented as 1100001x 10xxxxxx. (See RFC 3629 [RFC3629])
Requests contain methods, the object the method is operating upon and Requests contain methods, the object the method is operating upon and
parameters to further describe the method. Methods are idempotent parameters to further describe the method. Methods are idempotent
unless otherwise noted. Methods are also designed to require little unless otherwise noted. Methods are also designed to require little
or no state maintenance at the media server. or no state maintenance at the media server.
4.1 Message Types 4.1. Message Types
See [H4.1]. See [H4.1].
4.2 Message Headers 4.2. Message Headers
See [H4.2]. See [H4.2].
4.3 Message Body 4.3. Message Body
See [H4.3] See [H4.3].
Unlike HTTP, the presence of a message-body in either a request or a Unlike HTTP, the presence of a message-body in either a request or a
response MUST be signaled by the inclusion of a Content-Length header response MUST be signaled by the inclusion of a Content-Length header
field (see section 14.16). field (see Section 14.16).
4.4 Message Length 4.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 1. Any response message which MUST NOT include a message body (such
(such as the 1xx, 204, and 304 responses) is always as the 1xx, 204, and 304 responses) is always terminated by the
terminated by the first empty line after the header fields, first empty line after the header fields, regardless of the
regardless of the entity-header fields present in the entity-header fields present in the message. (Note: An empty
message. (Note: An empty line is a line with nothing line is a line with nothing preceding the CRLF.)
preceding the CRLF.)
2. If a Content-Length header field (section 14.16) is 2. If a Content-Length header field (Section 14.16) is present, its
present, its value in bytes represents the length of the value in bytes represents the length of the message-body. If
message-body. If this header field is not present, a value this header field is not present, a value of zero is assumed.
of zero is assumed.
Unlike an HTTP message, an RTSP message MUST contain a Content-Length Unlike an HTTP message, an RTSP message MUST contain a Content-Length
header field whenever it contains a message body. Note that RTSP does header field whenever it contains a message body. Note that RTSP
not support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]). does not support the HTTP/1.1 "chunked" transfer coding (see
[H3.6.1]).
Given the moderate length of presentation descriptions Given the moderate length of presentation descriptions returned,
returned, the server should always be able to determine its the server should always be able to determine its length, even if
length, even if it is generated dynamically, making the it is generated dynamically, making the chunked transfer encoding
chunked transfer encoding unnecessary. unnecessary.
5 General Header Fields 5. General Header Fields
See [H4.5], except that the Pragma, Trailer, Transfer-Encoding, See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
Upgrade, and Warning headers are not defined. RTSP further defines Upgrade, and Warning headers are not defined. RTSP further defines
the CSeq, Proxy-Supported and Timestamp headers. The general headers the CSeq, Proxy-Supported and Timestamp headers. The general headers
are listed in table 1: are listed in Table 1:
Header Name Defined in Section +-----------------+--------------------+
___________________________________ | Header Name | Defined in Section |
Cache-Control Section 14.10 +-----------------+--------------------+
Connection Section 14.11 | Cache-Control | Section 14.10 |
CSeq Section 14.19 | | |
Date Section 14.20 | Connection | Section 14.11 |
Proxy-Supported Section 14.32 | | |
Supported Section 14.43 | CSeq | Section 14.19 |
Timestamp Section 14.44 | | |
Via Section 14.49 | Date | Section 14.20 |
| | |
| Proxy-Supported | Section 14.32 |
| | |
| Supported | Section 14.43 |
| | |
| Timestamp | Section 14.44 |
| | |
| Via | Section 14.49 |
+-----------------+--------------------+
Table 1: The General headers used in RTSP. Table 1: The general headers used in RTSP
6 Request 6. Request
A request message uses the format outlined below regardless of the A request message uses the format outlined below regardless of the
direction of a request, client to server or server to client: direction of a request, client to server or server to client:
o Request line, containing the method to be applied to the o Request line, containing the method to be applied to the resource,
resource, the identifier of the resource, and the protocol the identifier of the resource, and the protocol version in use;
version in use;
o Zero or more Header lines, that can be of the following types: o Zero or more Header lines, that can be of the following types:
general (Section 5), request (Section 6.2), or entity (section general (Section 5), request (Section 6.2), or entity
8.1); (Section 8.1);
o One empty line (CRLF) to indicate the end of the header section;
o One empty line (CRLF) to indicate the end of the header
section;
o Optionally a message body (entity), consisting of one or more o Optionally a message body (entity), consisting of one or more
lines. The length of the message body in bytes is indicated by lines. The length of the message body in bytes is indicated by
the Content-Length entity header. the Content-Length entity header.
6.1 Request Line 6.1. Request Line
The request line provides the key information about the request: The request line provides the key information about the request: what
what method, on what resources and using which RTSP version. The method, on what resources and using which RTSP version. The methods
methods that are defined by this specification are listed in Table 2. that are defined by this specification are listed in Table 2.
Method Defined In Section +---------------+--------------------+
_________________________________ | Method | Defined in Section |
DESCRIBE Section 11.2 +---------------+--------------------+
GET_PARAMETER Section 11.7 | DESCRIBE | Section 11.2 |
OPTIONS Section 11.1 | | |
PAUSE Section 11.5 | GET_PARAMETER | Section 11.7 |
PLAY Section 11.4 | | |
REDIRECT Section 11.9 | OPTIONS | Section 11.1 |
SETUP Section 11.3 | | |
SET_PARAMETER Section 11.8 | PAUSE | Section 11.5 |
TEARDOWN Section 11.6 | | |
| PLAY | Section 11.4 |
| | |
| REDIRECT | Section 11.9 |
| | |
| SETUP | Section 11.3 |
| | |
| SET_PARAMETER | Section 11.8 |
| | |
| TEARDOWN | Section 11.6 |
+---------------+--------------------+
Table 2: The RTSP Methods Table 2: The RTSP Methods
The syntax of the RTSP request line is the following: The syntax of the RTSP request line is the following:
<Method> SP <Request-URI> SP <RTSP-Version> CRLF <Method> <Request-URI> <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of Note: This syntax cannot be freely changed in future versions of
RTSP. This line needs to remain parsable by older RTSP RTSP. This line needs to remain parsable by older RTSP
implementations since it indicates the RTSP version of the message. implementations since it indicates the RTSP version of the message.
In contrast to HTTP/1.1 [3], RTSP requests identify the resource In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the
through an absolute RTSP URI (scheme, host, and port) (see section resource through an absolute RTSP URI (scheme, host, and port) (see
3.2) rather than just the absolute path. Section 3.2) rather than just the absolute path.
HTTP/1.1 requires servers to understand the absolute URI, HTTP/1.1 requires servers to understand the absolute URI, but
but clients are supposed to use the Host request header. clients are supposed to use the Host request header. This is
This is purely needed for backward-compatibility with purely needed for backward-compatibility with HTTP/1.0 servers, a
HTTP/1.0 servers, a consideration that does not apply to consideration that does not apply to RTSP.
RTSP.
An asterisk "*" can be used instead of an absolute URI in the An asterisk "*" can be used instead of an absolute URI in the
Request-URI part to indicate that the request does not apply to a Request-URI part to indicate that the request does not apply to a
particular resource, but to the server or proxy itself, and is only particular resource, but to the server or proxy itself, and is only
allowed when the request method does not necessarily apply to a allowed when the request method does not necessarily apply to a
resource. resource.
For example: For example:
OPTIONS * RTSP/2.0 OPTIONS * RTSP/2.0
skipping to change at page 32, line 25 skipping to change at page 34, line 17
An OPTIONS in this form will determine the capabilities of the server An OPTIONS in this form will determine the capabilities of the server
or the proxy that first receives the request. If the capability of or the proxy that first receives the request. If the capability of
the specific server needs to be determined, without regard to the the specific server needs to be determined, without regard to the
capability of an intervening proxy, the server should be addressed capability of an intervening proxy, the server should be addressed
explicitly with an absolute URI that contains the server's address. explicitly with an absolute URI that contains the server's address.
For example: For example:
OPTIONS rtsp://example.com RTSP/2.0 OPTIONS rtsp://example.com RTSP/2.0
6.2 Request Header Fields 6.2. Request Header Fields
The RTSP headers in Table 3 can be included in a request, as request The RTSP headers in Table Table 3 can be included in a request, as
headers, to modify the specifics of the request. Some of these request headers, to modify the specifics of the request. Some of
headers may also be used in the response to a request, as response these headers may also be used in the response to a request, as
headers, to modify the specifics of a response (Section 7.2). response headers, to modify the specifics of a response
(Section 7.2).
+--------------------+--------------------+
| Header | Defined in Section |
+--------------------+--------------------+
| Accept | Section 14.1 |
| | |
| Accept-Credentials | Section 14.2 |
| | |
| Accept-Encoding | Section 14.3 |
| | |
| Accept-Language | Section 14.4 |
| | |
| Authorization | Section 14.7 |
| | |
| Bandwidth | Section 14.8 |
| | |
| Blocksize | Section 14.9 |
| | |
| From | Section 14.23 |
| | |
| If-Match | Section 14.24 |
| | |
| If-Modified-Since | Section 14.25 |
| | |
| If-None-Match | Section 14.26 |
| | |
| Proxy-Require | Section 14.31 |
| | |
| Range | Section 14.34 |
| Referer | Section 14.35 |
| | |
| Require | Section 14.37 |
| | |
| Scale | Section 14.39 |
| | |
| Session | Section 14.42 |
| | |
| Speed | Section 14.40 |
| | |
| Supported | Section 14.43 |
| | |
| Transport | Section 14.45 |
| | |
| User-Agent | Section 14.47 |
+--------------------+--------------------+
Table 3: The RTSP request headers
Detailed headers definition are provided in Section 14. Detailed headers definition are provided in Section 14.
New request headers may be defined. If the receiver of the request is New request headers may be defined. If the receiver of the request
required to understand the request header, the request MUST include a is required to understand the request header, the request MUST
corresponding feature tag in a Require or Proxy-Require header to include a corresponding feature tag in a Require or Proxy-Require
ensure the correct processing of the header. header to ensure the correct processing of the header.
7 Response 7. Response
[H6] applies except that HTTP-Version is replaced by RTSP-Version. [H6] applies except that HTTP-Version is replaced by RTSP-Version.
Also, RTSP defines additional status codes and does not define some Also, RTSP defines additional status codes and does not define some
of the HTTP codes. The valid response codes and the methods they can of the HTTP codes. The valid response codes and the methods they can
be used with are listed in Table 4. be used with are listed in Table 4.
After receiving and interpreting a request message, the recipient After receiving and interpreting a request message, the recipient
Header Defined in Section
______________________________________
Accept Section 14.1
Accept-Credentials Section 14.2
Accept-Encoding Section 14.3
Accept-Language Section 14.4
Authorization Section 14.7
Bandwidth Section 14.8
Blocksize Section 14.9
From Section 14.23
If-Match Section 14.24
If-Modified-Since Section 14.25
If-None-Match Section 14.26
Proxy-Require Section 14.31
Range Section 14.34
Referer Section 14.35
Require Section 14.37
Scale Section 14.39
Session Section 14.42
Speed Section 14.40
Supported Section 14.43
Transport Section 14.45
User-Agent Section 14.47
Table 3: The RTSP request headers
responds with an RTSP response message. responds with an RTSP response message.
7.1 Status-Line 7.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
final CRLF sequence. final CRLF sequence.
<RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF
7.1.1 Status Code and Reason Phrase 7.1.1. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. These codes are fully
defined in Section 13. The Reason-Phrase is intended to give a short defined in Section 13. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason- user. The client is not required to examine or display the Reason-
Phrase. Phrase.
The first digit of the Status-Code defines the class of response. The The first digit of the Status-Code defines the class of response.
last two digits do not have any categorization role. There are 5 The last two digits do not have any categorization role. There are 5
values for the first digit: values for the first digit:
o 1xx: Informational - Request received, continuing process 1xx: Informational - Request received, continuing process
o 2xx: Success - The action was successfully received,
understood, and accepted
o 3rr: Redirection - Further action needs to be taken in order 2xx: Success - The action was successfully received, understood, and
to complete the request accepted
o 4xx: Client Error - The request contains bad syntax or cannot 3rr: Redirection - Further action needs to be taken in order to
be fulfilled complete the request
o 5xx: Server Error - The server failed to fulfill an apparently 4xx: Client Error - The request contains bad syntax or cannot be
valid request fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid
request
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
RTSP/2.0, and an example set of corresponding Reason-Phrases, are RTSP/2.0, and an example set of corresponding Reason-Phrases, are
presented in table 4. The reason phrases listed here are only presented in Table 4. The reason phrases listed here are only
recommended; they may be replaced by local equivalents without recommended; they may be replaced by local equivalents without
affecting the protocol. Note that RTSP adopts most HTTP/1.1 [3] affecting the protocol. Note that RTSP adopts most HTTP/1.1
status codes and adds RTSP-specific status codes starting at x50 to [RFC2616] status codes and adds RTSP-specific status codes starting
avoid conflicts with newly defined HTTP status codes. at x50 to avoid conflicts with newly defined HTTP status codes.
RTSP status codes are extensible. RTSP applications are not required RTSP status codes are extensible. RTSP applications are not required
to understand the meaning of all registered status codes, though such to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
readable information which will explain the unusual status. readable information which will explain the unusual status.
7.2 Response Header Fields +------+-------------------------------------+-----------------+
| Code | Reason | Method |
+------+-------------------------------------+-----------------+
| 100 | Continue | all |
| | | |
| | | |
| 200 | OK | all |
| | | |
| | | |
| 300 | Multiple Choices | all |
| | | |
| 301 | Multiple Choices | all |
| | | |
| 301 | Moved Permanently | all |
| | | |
| 302 | Found | all |
| | | |
| 303 | See Other | all |
| | | |
| 305 | Use Proxy | all |
| | | |
| | | |
| 400 | Bad Request | all |
| 401 | Unauthorized | all |
| | | |
| 402 | Payment Required | all |
| | | |
| 403 | Forbidden | all |
| | | |
| 404 | Not Found | all |
| | | |
| 405 | Method Not Allowed | all |
| | | |
| 406 | Not Acceptable | all |
| | | |
| 407 | Proxy Authentication Required | all |
| | | |
| 408 | Request Timeout | all |
| | | |
| 410 | Gone | all |
| | | |
| 411 | Length Required | all |
| | | |
| 412 | Precondition Failed | DESCRIBE, SETUP |
| | | |
| 413 | Request Entity Too Large | all |
| | | |
| 414 | Request-URI Too Long | all |
| | | |
| 415 | Unsupported Media Type | all |
| | | |
| 451 | Parameter Not Understood | SET_PARAMETER |
| | | |
| 452 | reserved | n/a |
| | | |
| 453 | Not Enough Bandwidth | SETUP |
| | | |
| 454 | Session Not Found | all |
| | | |
| 455 | Method Not Valid In This State | all |
| | | |
| 456 | Header Field Not Valid | all |
| | | |
| 457 | Invalid Range | PLAY, PAUSE |
| | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER |
| | | |
| 459 | Aggregate Operation Not Allowed | all |
| | | |
| 460 | Only Aggregate Operation Allowed | all |
| | | |
| 461 | Unsupported Transport | all |
| | | |
| 462 | Destination Unreachable | all |
| | | |
| 463 | Destination Prohibited | SETUP |
| | | |
| 464 | Data Transport Not Ready Yet | PLAY |
| | | |
| 470 | Connection Authorization Required | all |
| | | |
| 471 | Connection Credentials not accepted | all |
| | | |
| | | |
| 500 | Internal Server Error | all |
| | | |
| 501 | Not Implemented | all |
| | | |
| 502 | Bad Gateway | all |
| | | |
| 503 | Service Unavailable | all |
| | | |
| 504 | Gateway Timeout | all |
| | | |
| 505 | RTSP Version Not Supported | all |
| | | |
| 551 | Option not support | all |
+------+-------------------------------------+-----------------+
Table 4: Status codes and their usage with RTSP methods
7.2. Response Header Fields
The response-header fields allow the request recipient to pass The response-header fields allow the request recipient to pass
additional information about the response which cannot be placed in additional information about the response which cannot be placed in
the Status-Line. These header fields give information about the the Status-Line. These header fields give information about the
server and about further access to the resource identified by the server and about further access to the resource identified by the
Request-URI. All headers currently classified as response headers are Request-URI. All headers currently classified as response headers
listed in table 5. are listed in Table 5.
Header Defined in Section +------------------------+--------------------+
__________________________________________ | Header | Defined in Section |
Accept-Credentials Section 14.2 +------------------------+--------------------+
Accept-Ranges Section 14.5 | Accept-Credentials | Section 14.2 |
Connection-Credentials Section 14.12 | | |
ETag Section 14.21 | Accept-Ranges | Section 14.5 |
Location Section 14.28 | | |
Proxy-Authenticate Section 14.29 | Connection-Credentials | Section 14.12 |
Public Section 14.33 | | |
Range Section 14.34 | ETag | Section 14.21 |
Retry-After Section 14.36 | | |
RTP-Info Section 14.38 | Location | Section 14.28 |
Scale Section 14.39 | | |
Session Section 14.42 | Proxy-Authenticate | Section 14.29 |
Server Section 14.41 | | |
Speed Section 14.40 | Public | Section 14.33 |
Transport Section 14.45 | | |
Unsupported Section 14.46 | Range | Section 14.34 |
Vary Section 14.48 | | |
WWW-Authenticate Section 14.50 | Retry-After | Section 14.36 |
| | |
| RTP-Info | Section 14.38 |
| | |
| Scale | Section 14.39 |
| | |
| Session | Section 14.42 |
| | |
| Server | Section 14.41 |
| | |
| Speed | Section 14.40 |
| | |
| Transport | Section 14.45 |
| | |
| Unsupported | Section 14.46 |
| | |
| Vary | Section 14.48 |
| | |
| WWW-Authenticate | Section 14.50 |
+------------------------+--------------------+
Table 5: The RTSP response headers Table 5: The RTSP response headers
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However the usage combination with a change in the protocol version. However the usage
of feature-tags in the request allows the responding party to learn of feature-tags in the request allows the responding party to learn
the capability of the receiver of the response. New or experimental the capability of the receiver of the response. New or experimental
header fields MAY be given the semantics of response-header fields if header fields MAY be given the semantics of response-header fields if
all parties in the communication recognize them to be response-header all parties in the communication recognize them to be response-header
fields. Unrecognized header fields in responses are treated as fields. Unrecognized header fields in responses are treated as
entity-header fields. entity-header fields.
8 Entity 8. Entity
Request and Response messages MAY transfer an entity if not otherwise Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers. responses will only include the entity-headers.
The SET_PARAMETER and GET_PARAMETER request and response, and The SETPARAMETER and GETPARAMETER request and response, and DESCRIBE
DESCRIBE response MAY have an entity. All 4xx and 5xx responses MAY response MAY have an entity. All 4xx and 5xx responses MAY also have
Code Reason Method an entity.
__________________________________________________________
100 Continue all
__________________________________________________________
200 OK all
__________________________________________________________
300 Multiple Choices all
301 Moved Permanently all
302 Found all
303 See Other all
305 Use Proxy all
__________________________________________________________
400 Bad Request all
401 Unauthorized all
402 Payment Required all
403 Forbidden all
404 Not Found all
405 Method Not Allowed all
406 Not Acceptable all
407 Proxy Authentication Required all
408 Request Timeout all
410 Gone all
411 Length Required all
412 Precondition Failed DESCRIBE, SETUP
413 Request Entity Too Large all
414 Request-URI Too Long all
415 Unsupported Media Type all
451 Parameter Not Understood SET_PARAMETER
452 reserved n/a
453 Not Enough Bandwidth SETUP
454 Session Not Found all
455 Method Not Valid In This State all
456 Header Field Not Valid all
457 Invalid Range PLAY, PAUSE
458 Parameter Is Read-Only SET_PARAMETER
459 Aggregate Operation Not Allowed all
460 Only Aggregate Operation Allowed all
461 Unsupported Transport all
462 Destination Unreachable all
463 Destination Prohibited SETUP
464 Data Transport Not Ready Yet PLAY
470 Connection Authorization Required all
471 Connection Credentials not accepted all
__________________________________________________________
500 Internal Server Error all
501 Not Implemented all
502 Bad Gateway all
503 Service Unavailable all
504 Gateway Timeout all
505 RTSP Version Not Supported all
Table 4: Status codes and their usage with RTSP methods
also have an entity.
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 entity. or the server, depending on who sends and who receives the entity.
8.1 Entity Header Fields 8.1. Entity Header Fields
Entity-header fields define meta-information about the entity-body Entity-header fields define meta-information about the entity-body
or, if no body is present, about the resource identified by the or, if no body is present, about the resource identified by the
request. The entity header fields are listed in table 8.1. request. The entity header fields are listed in Table 6.
Header Defined in Section +------------------+--------------------+
____________________________________ | Header | Defined in Section |
Allow Section 14.6 +------------------+--------------------+
Content-Base Section 14.13 | Allow | Section 14.6 |
Content-Encoding Section 14.14 | | |
Content-Language Section 14.15 | Content-Base | Section 14.13 |
Content-Length Section 14.16 | | |
Content-Location Section 14.17 | Content-Encoding | Section 14.14 |
Content-Type Section 14.18 | | |
Expires Section 14.22 | Content-Language | Section 14.15 |
Last-Modified Section 14.27 | | |
| Content-Length | Section 14.16 |
| | |
| Content-Location | Section 14.17 |
| | |
| Content-Type | Section 14.18 |
| | |
| Expires | Section 14.22 |
| | |
| Last-Modified | Section 14.27 |
+------------------+--------------------+
Table 6: The RTSP entity headers Table 6: The RTSP entity headers
The extension-header mechanism allows additional entity-header fields The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies. fields SHOULD be ignored by the recipient and forwarded by proxies.
8.2 Entity Body 8.2. Entity Body
See [H7.2] with the addition that an RTSP message with an entity body See [H7.2] with the addition that an RTSP message with an entity body
MUST include the Content-Type and Content-Length headers. MUST include the Content-Type and Content-Length headers.
9 Connections 9. 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 o persistent - a transport connection is used for several request/
request/response transactions; response transactions;
o transient - a transport connection is used for a single
request/response transaction. o transient - a transport connection is used for a single request/
response transaction.
RFC 2326 attempted to specify an optional mechanism for transmitting RFC 2326 attempted to specify an optional mechanism for transmitting
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce complexity for interoperable implementations. In an attempt to reduce
and scope, and due to lack of interest, RTSP 2.0 does not attempt to complexity and scope, and due to lack of interest, RTSP 2.0 does not
define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests SHALL NOT be sent to multicast groups since no RTSP requests SHALL NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header (Section 14.19), which Certain RTSP headers, such as the CSeq header Section 14.19), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see section responses to requests if the requests are pipelined (see
9.2). It is also useful in proxies for keeping track of the different Section 9.2). It is also useful in proxies for keeping track of the
requests when aggregating several client requests on a single TCP different requests when aggregating several client requests on a
connection. single TCP connection.
9.1 Reliability and Acknowledgements 9.1. Reliability and Acknowledgements
When RTSP messages are transmitted using reliable transport When RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication provide reliability. The RTSP implementation may use any indication
of reception acknowledgement of the message from the underlying of reception acknowledgement of the message from the underlying
transport protocols to optimize the RTSP behavior. transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport such as TCP and If both the underlying reliable transport such as TCP and the RTSP
the RTSP application retransmit requests, each packet loss application retransmit requests, each packet loss or message loss
or message loss may result in two retransmissions. The may result in two retransmissions. The receiver typically cannot
receiver typically cannot take advantage of the take advantage of the application-layer retransmission since the
application-layer retransmission since the transport stack transport stack will not deliver the application-layer
will not deliver the application-layer retransmission retransmission before the first attempt has reached the receiver.
before the first attempt has reached the receiver. If the If the packet loss is caused by congestion, multiple
packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the retransmissions at different layers will exacerbate the
congestion. congestion.
Lack of acknowledgement of an RTSP request should be handled within Lack of acknowledgement of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 9.4). below (Section 9.4).
9.2 Using Connections 9.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST support message exchange). Implementations of this specification MUST
RTSP over TCP. The scheme of the RTSP URI (Section 3.2) indicates the support RTSP over TCP. The scheme of the RTSP URI (Section 3.2)
default port that the server will listen on. indicates the default port that the server will listen on.
A server MUST handle both persistent and transient connections. A server MUST handle both persistent and transient connections.
Transient connections facilitate mechanisms for fault Transient connections facilitate mechanisms for fault tolerance.
tolerance. They also allow for application layer mobility. They also allow for application layer mobility. A server and
A server and client pair that support transient connections client pair that support transient connections can survive the
can survive the loss of a TCP connection; e.g., due to a loss of a TCP connection; e.g., due to a NAT timeout. When the
NAT timeout. When the client has discovered that the TCP client has discovered that the TCP connection has been lost, it
connection has been lost, it can set up a new one when can set up a new one when there is need to communicate again.
there is need to communicate again.
A persistent connection MAY be used for all transactions between the A persistent connection MAY be used for all transactions between the
server and client, including messages for multiple RTSP sessions. server and client, including messages for multiple RTSP sessions.
However a persistent connection MAY also be closed after a few However a persistent connection MAY also be closed after a few
message exchanges. For example, a client may use a persistent message exchanges. For example, a client may use a persistent
connection for the initial SETUP and PLAY message exchanges in a connection for the initial SETUP and PLAY message exchanges in a
session and then close the connection. Later, when the client wishes session and then close the connection. Later, when the client wishes
to send a new request, such as a PAUSE for the session, a new to send a new request, such as a PAUSE for the session, a new
connection would be opened. This connection may either be transient connection would be opened. This connection may either be transient
or persistent. 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 This saves connection resources on the server. It also reduces
reduces complexity by and enabling the server to maintain complexity by and enabling the server to maintain less state about
less state about its sessions and connections. its sessions and connections.
Unlike HTTP, RTSP allows a server to send requests to a client. Unlike HTTP, RTSP allows a server to send requests to a client.
However, this can be supported only if a client establishes a However, this can be supported only if a client establishes a
persistent connection with the server. In cases where a persistent persistent connection with the server. In cases where a persistent
connection does not exist between a server and its client, due to the connection does not exist between a server and its client, due to the
lack of a signalling channel the server may be forced to drop an RTSP lack of a signalling channel the server may be forced to drop an RTSP
session without notifying the client. An example of such a case is session without notifying the client. An example of such a case is
when the server desires to send a REDIRECT request for an RTSP when the server desires to send a REDIRECT request for an RTSP
session to the client but is not able to do so because it cannot session to the client but is not able to do so because it cannot
reach the client. reach the client.
Without a persistent connection between the client and the Without a persistent connection between the client and the server,
server, the media server has no reliable way of reaching the media server has no reliable way of reaching the client.
the client. Also, this is the only way that requests from a Also, this is the only way that requests from a server to its
server to its client are likely to traverse firewalls. client are likely to traverse firewalls.
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 (i.e., send multiple requests connections MAY "pipeline" its requests (i.e., send multiple requests
without waiting for each response). A server MUST send its responses without waiting for each response). A server MUST send its responses
to those requests in the order that the requests were received. to those requests in the order that the requests were received.
9.3 Closing Connections 9.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 close managed through the connection. The server, however, SHOULD NOT
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 14.42). A server SHOULD NOT connection have been timed out (Section 14.42). 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 This is to ensure that the client has time to issue a SETUP for a
for a new session on the existing connection after having new session on the existing connection after having torn the last
torn the last one down. 10 seconds should give the client one down. 10 seconds should give the client ample opportunity get
ample opportunity get its message to the server. 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 Certain error responses such as "460 Only Aggregate Operation
Operation Allowed" (Section 13.4.12) are used for Allowed" (Section 13.4.12) are used for negotiating capabilities
negotiating capabilities of a server with respect to of a server with respect to content or other factors. In such
content or other factors. In such cases, it is inefficient cases, it is inefficient for the server to close a connection on
for the server to close a connection on an error response. an error response. Also, such behavior would prevent
Also, such behavior would prevent implementation of implementation of advanced/special types of requests or result in
advanced/special types of requests or result in extra extra overhead for the client when testing for new features. On
overhead for the client when testing for new features. On the flip side, keeping connections open after sending an error
the flip side, keeping connections open after sending an response poses a Denial of Service security risk (Section 20).
error response poses a Denial of Service security risk
(Section 20).
If a server initiates a connection close while the client is If a server initiates a connection close while the client is
attempting to send a new request, the client will have to close its attempting to send a new request, the client will have to close its
current connection, establish a new connection and send its request current connection, establish a new connection and send its request
over the new connection. over the new connection.
An RTSP message should not be terminated by closing the connection. An RTSP message should not be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 4. Section Section 4.
9.4 Timing Out Connections and RTSP Messages 9.4. Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
Similarly, the sender of a request (requestor) SHOULD wait for a Similarly, the sender of a request (requestor) SHOULD wait for a
sufficient time for a response before concluding that the responder sufficient time for a response before concluding that the responder
will not be acting upon its request. will not be acting upon its request.
A responder SHOULD respond to all requests within 5 seconds. If the A responder SHOULD respond to all requests within 5 seconds. If the
responder recognizes that processing of a request will take longer responder recognizes that processing of a request will take longer
than 5 seconds, it SHOULD send a 100 (Continue) response as soon as than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
skipping to change at page 41, line 41 skipping to change at page 47, line 41
A requestor SHOULD wait at least 10 seconds for a response before A requestor SHOULD wait at least 10 seconds for a response before
concluding that the responder will not be responding to its request. concluding that the responder will not be responding to its request.
After receiving a 100 response, the requestor SHOULD continue waiting After receiving a 100 response, the requestor SHOULD continue waiting
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume that the responder receiving any response, the requestor MAY assume that the responder
is unresponsive and abort the connection. is unresponsive and abort the connection.
A requestor SHOULD wait longer than 10 seconds for a response if it A requestor SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requestor is capable of determining the RTT of the responder. The requestor is capable of determining the RTT of the
request/response cycle using the Timestamp header (section 14.44) in request/response cycle using the Timestamp header (Section 14.44) in
any RTSP request. any RTSP request.
9.5 Use of IPv6 9.5. 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.
10 Capability Handling 10. Capability Handling
This section describes the capability handling mechanism available in This section describes the capability handling mechanism available in
RTSP which allows RTSP to be extended. Extensions to this version of RTSP which allows RTSP to be extended. Extensions to this version of
the protocol are basically done in two ways. First, new headers can the protocol are basically done in two ways. First, new headers can
be added. Secondly, new methods can be added. The capability handling be added. Secondly, new methods can be added. The capability
mechanism is designed to handle both cases. handling mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover wether it is supported. This is done by issuing a method to discover wether it is supported. This is done by issuing a
OPTIONS request to the other party. Depending on the URI it will OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST contain in general, or simply the next hop. The OPTIONS response MUST
a Public header which declares all methods supported for the contain a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
the client could simply try the method. If the receiver of the the client could simply try the method. If the receiver of the
request does not support the method it will respond with an error request does not support the method it will respond with an error
code indicating the the method is either not implemented (501) or code indicating the the method is either not implemented (501) or
does not apply for the resource (405). The choice between the two does 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
skipping to change at page 42, line 38 skipping to change at page 48, line 42
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 playback
implementation. implementation.
Feature-tags are used to determine wether the client, server or proxy Feature-tags are used to determine wether the client, server or proxy
supports the functionality that is necessary to achieve the desired supports the functionality that is necessary to achieve the desired
service. To determine support of a feature-tag, several different service. To determine support of a feature-tag, several different
headers can be used, each explained below: headers can be used, each explained below:
Supported: The supported header is used to determine the Supported: The supported header is used to determine the complete
complete set of functionality that both client and server set of functionality that both client and server have. The
have. The intended usage is to determine before one needs intended usage is to determine before one needs to use a
to use a functionality that it is supported. It can be used functionality that it is supported. It can be used in any
in any method, however OPTIONS is the most suitable one as method, however OPTIONS is the most suitable one as it at the
it at the same time determines all methods that are same time determines all methods that are implemented. When
implemented. When sending a request the requestor declares sending a request the requestor declares all its capabilities
all its capabilities by including all supported feature- by including all supported feature-tags. This results in that
tags. This results in that the receiver learns the the receiver learns the requestors feature support. The
requestors feature support. The receiver then includes its receiver then includes its set of features in the response.
set of features in the response.
Proxy-Supported: The Proxy-Supported header is used similar to Proxy-Supported: The Proxy-Supported header is used similar to the
the Supported header, but instead of giving the supported Supported header, but instead of giving the supported
functionality of the client or server it provides both the functionality of the client or server it provides both the
requestor and the responder a view of what functionality requestor and the responder a view of what functionality the
the proxy chain between the two supports. Proxies are proxy chain between the two supports. Proxies are required to
required to add this header whenever the Supported header add this header whenever the Supported header is present, but
is present, but proxies may independently of the requestor proxies may independently of the requestor add it.
add it.
Require: The Require header can be included in any request where Require: The Require header can be included in any request where the
the end-point, i.e. the client or server, is required to end-point, i.e. the client or server, is required to understand
understand the feature to correctly perform the request. the feature to correctly perform the request. This can, for
This can, for example, be a SETUP request where the server example, be a SETUP request where the server is required to
is required to understand a certain parameter to be able to understand a certain parameter to be able to set up the media
set up the media delivery correctly. Ignoring this delivery correctly. Ignoring this parameter would not have the
parameter would not have the desired effect and is not desired effect and is not acceptable. Therefore the end-point
acceptable. Therefore the end-point receiving a request receiving a request containing a Require MUST negatively
containing a Require MUST negatively acknowledge any acknowledge any feature that it does not understand and not
feature that it does not understand and not perform the perform the request. The response in cases where features are
request. The response in cases where features are not not supported are 551 (Option Not Supported). Also the
supported are 551 (Option Not Supported). Also the features that are not supported are given in the Unsupported
features that are not supported are given in the header in the response.
Unsupported header in the response.
Proxy-Require: This method has the same purpose and workings as Proxy-Require: This method has the same purpose and workings as
Require except that it only applies to proxies and not the Require except that it only applies to proxies and not the end-
end-point. Features that needs to be supported by both point. Features that needs to be supported by both proxies and
proxies and end-point needs to be included in both the end-point needs to be included in both the Require and Proxy-
Require and Proxy-Require header. Require header.
Unsupported: This header is used in a 551 error response, to Unsupported: This header is used in a 551 error response, to
indicate which feature(s) that was not supported. Such a indicate which feature(s) that was not supported. Such a
response is only the result of the usage of the Require response is only the result of the usage of the Require and/or
and/or Proxy-Require header where one or more feature where Proxy-Require header where one or more feature where not
not supported. This information allows the requestor to supported. This information allows the requestor to make the
make the best of situations as it knows which features are best of situations as it knows which features are not
not supported. supported.
11 Method Definitions 11. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names SHALL NOT New methods may be defined in the future. Method names SHALL NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 24) and MUST be a token as defined
by the ABNF [4] in the syntax chapter 19. The methods are summarized by the ABNF [RFC4234] in the syntax chapter Section 19. The methods
in Table 7. are summarized in Table 7.
Note on Table 7: GET_PARAMETER is recommended, but not +--------------+-----------+--------+---------------+---------------+
method direction object Server req. Client req. | method | direction | object | Server req. | Client req. |
___________________________________________________________________ +--------------+-----------+--------+---------------+---------------+
DESCRIBE C -> S P,S recommended recommended | DESCRIBE | C -> S | P,S | recommended | recommended |
GET_PARAMETER C -> S, S -> C P,S optional optional | | | | | |
OPTIONS C -> S, S -> C P,S R=Req, Sd=Opt Sd=Req, R=Opt | GETPARAMETER | C -> S | P,S | optional | optional |
PAUSE C -> S P,S required required | | | | | |
PLAY C -> S P,S required required | | S -> C | | | |
REDIRECT S -> C P,S optional required | | | | | |
SETUP C -> S S required required | OPTIONS | C -> S | P,S | R=Req, Sd=Opt | Sd=Req, R=Opt |
SET_PARAMETER C -> S, S -> C P,S required optional | | | | | |
TEARDOWN C -> S P,S required required | | S -> C | | | |
| | | | | |
| PAUSE | C -> S | P,S | required | required |
| | | | | |
| PLAY | C -> S | P,S | required | required |
| | | | | |
| REDIRECT | S -> C | P,S | optional | required |
| | | | | |
| SETUP | C -> S | S | required | required |
| | | | | |
| SETPARAMETER | C -> S | P,S | required | optional |
| | | | | |
| | S -> C | | | |
| | | | | |
| TEARDOWN | C -> S | P,S | 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
required. For example, a fully functional server can be Note on Table 7: GETPARAMETER is recommended, but not required.
built to deliver media without any parameters. For example, a fully functional server can be built to deliver
SET_PARAMETER is required however due to its usage for media without any parameters. SETPARAMETER is required however
keep-alive. PAUSE is now required due to that it is the due to its usage for keep-alive. PAUSE is now required due to
only way of getting out of the state machines play state that it is the only way of getting out of the state machines play
without terminating the whole session. 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.
11.1 OPTIONS 11.1. OPTIONS
The semantics of the RTSP OPTIONS method is equivalent to that of the The semantics of the RTSP OPTIONS method is equivalent to that of the
HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is HTTP OPTIONS method described in [H9.2]. In RTSP however, OPTIONS is
bi-directional, in that a client can request it to a server and vice bi-directional, in that a client can request it to a server and vice
versa. A client MUST implement the capability to send an OPTIONS versa. A client MUST implement the capability to send an OPTIONS
request and a server or a proxy MUST implement the capability to request and a server or a proxy MUST implement the capability to
respond to an OPTIONS request. The client, server or proxy MAY also respond to an OPTIONS request. The client, server or proxy MAY also
implement the converse of their required capability. implement the converse of their required capability.
An OPTIONS request may be issued at any time. Such a request does not An OPTIONS request may be issued at any time. Such a request does
modify the session state. However, it may prolong the session not modify the session state. However, it may prolong the session
lifespan (see below). The URI in an OPTIONS request determines the lifespan (see below). The URI in an OPTIONS request determines the
scope of the request and the corresponding response. If the Request- scope of the request and the corresponding response. If the Request-
URI refers to a specific media resource on a given host, the scope is URI refers to a specific media resource on a given host, the scope is
limited to the set of methods supported for that media resource by limited to the set of methods supported for that media resource by
the indicated RTSP agent. A Request-URI with only the host address the indicated RTSP agent. A Request-URI with only the host address
limits the scope to the specified RTSP agent's general capabilities limits the scope to the specified RTSP agent's general capabilities
without regard to any specific media. If the Request-URI is an without regard to any specific media. If the Request-URI is an
asterisk ("*"), the scope is limited to the general capabilities of asterisk ("*"), the scope is limited to the general capabilities of
the next hop (i.e. the RTSP agent in direct communication with the the next hop (i.e. the RTSP agent in direct communication with the
request sender). request sender).
skipping to change at page 45, line 21 skipping to change at page 51, line 46
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 14.42. An OPTIONS request intended for signalling, see Section 14.42. 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 45, line 44 skipping to change at page 52, line 21
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
Supported: play.basic, implicit-play, gzipped-messages Supported: play.basic, implicit-play, gzipped-messages
Server: PhonyServer/1.1 Server: PhonyServer/1.1
Note that some of the feature-tags in Require and Proxy-Require are Note that some of the feature-tags in Require and Proxy-Require are
fictional features. fictional features.
11.2 DESCRIBE 11.2. DESCRIBE
The DESCRIBE method is used to retrieve the description of a The DESCRIBE method is used to retrieve the description of a
presentation or media object from a server. The Request-URI of the presentation or media object from a server. The Request-URI of the
DESCRIBE request identifies the media resource of interest. The DESCRIBE request identifies the media resource of interest. The
client MAY include the Accept header in the request to list the client MAY include the Accept header in the request to list the
description formats that it understands. The server SHALL respond description formats that it understands. The server SHALL respond
with a description of the requested resource and return the with a description of the requested resource and return the
description in the entity of the response. The DESCRIBE reply- description in the entity of the response. The DESCRIBE reply-
response pair constitutes the media initialization phase of RTSP. response pair constitutes the media initialization phase of RTSP.
skipping to change at page 46, line 39 skipping to change at page 53, line 32
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
c=IN IP4 224.2.17.12/127 c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 t=2873397496 2873404696
a=recvonly a=recvonly
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
m=application 32416 UDP WB m=application 32416 UDP WB
a=orient:portrait a=orient:portrait
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 NOT information for the resource(s) that it describes. Servers SHOULD
use the DESCRIBE response as a means of media indirection by having NOT use the DESCRIBE response as a means of media indirection by
the description point at another server, instead usage of 3rr having the description point at another server, instead usage of 3rr
responses are recommended. responses are recommended.
By forcing a DESCRIBE response to contain all media By forcing a DESCRIBE response to contain all media initialization
initialization for the set of streams that it describes, for the set of streams that it describes, and discouraging the use
and discouraging the use of DESCRIBE for media indirection, of DESCRIBE for media indirection, any looping problems can be
any looping problems can be avoided that might have avoided that might have resulted from other approaches.
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.)
skipping to change at page 47, line 27 skipping to change at page 54, line 14
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.
11.3 SETUP 11.3. SETUP
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in three used for the streamed media. The SETUP method may be used in three
different cases; Create an RTSP session, add a media to a session, different cases; Create an RTSP session, add a media to a session,
and change the transport parameters of already set up media stream. and change the transport parameters of already set up media stream.
When in PLAY state, using SETUP to create or add media to a session When in PLAY state, using SETUP to create or add media to a session
when in PLAY state is unspecified. Otherwise SETUP can be used in all when in PLAY state is unspecified. Otherwise SETUP can be used in
three states; INIT, and READY, for both purposes and in PLAY to all three states; INIT, and READY, for both purposes and in PLAY to
change the transport parameters. change the transport parameters.
The Transport header, see section 14.45, specifies the transport The Transport header, see Section 14.45, specifies the transport
parameters acceptable to the client for data transmission; the parameters acceptable to the client for data transmission; the
response will contain the transport parameters selected by the response will contain the transport parameters selected by the
server. This allows the client to enumerate in priority order the server. This allows the client to enumerate in priority order the
transport mechanisms and parameters acceptable to it, while the transport mechanisms and parameters acceptable to it, while the
server can select the most appropriate. It is expected that the server can select the most appropriate. It is expected that the
session description format used will enable the client to select a session description format used will enable the client to select a
limited number possible configurations that are offered to the server limited number possible configurations that are offered to the server
to choose from. All transport related parameters shall be included in to choose from. All transport related parameters shall be included
the Transport header, the use of other headers for this purpose is in the Transport header, the use of other headers for this purpose is
discouraged due to middle boxes such as firewalls, or NATs. discouraged due to middle boxes such as firewalls, or NATs.
For the benefit of any intervening firewalls, a client SHALL indicate For the benefit of any intervening firewalls, a client SHALL indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization Since SETUP includes all transport initialization information,
information, firewalls and other intermediate network firewalls and other intermediate network devices (which need this
devices (which need this information) are spared the more information) are spared the more arduous task of parsing the
arduous task of parsing the DESCRIBE response, which has DESCRIBE response, which has been reserved for media
been reserved for media initialization. initialization.
The client SHALL include the Accept-Ranges header in the request The client SHALL include the Accept-Ranges header in the request
indicating all supported unit formats in the Range header. This indicating all supported unit formats in the Range header. This
allows the server to know which format it may use in future session allows the server to know which format it may use in future session
related responses, such as PLAY response without any range in the related responses, such as PLAY response without any range in the
request. If the client does not support a time format necessary for request. If the client does not support a time format necessary for
the presentation the server SHALL respond using 456 (Header Field Not the presentation the server SHALL respond using 456 (Header Field Not
Valid for Resource) and include the Accept-Ranges header with the Valid for Resource) and include the Accept-Ranges header with the
range unit formats supported for the resource. range unit formats supported for the resource.
In a SETUP response the server SHALL include the Accept-Ranges header In a SETUP response the server SHALL include the Accept-Ranges header
(see section 14.5 to indicate which time formats that are acceptable (see Section 14.5) to indicate which time formats that are acceptable
to use for this media resource. to use for this media resource.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302 CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589";
src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; src_addr="192.0.2.241:6256"/"192.0.2.241:6257";
ssrc=2A3F93ED ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
containing the media resource "rtsp://example.com/foo/bar/baz.rm". containing the media resource "rtsp://example.com/foo/bar/baz.rm".
The transport parameters acceptable to the client is either The transport parameters acceptable to the client is either RTP/AVP/
RTP/AVP/UDP (UDP per default) to be received on client port 4588 and UDP (UDP per default) to be received on client port 4588 and 4589 or
4589 or RTP/AVP interleaved on the RTSP control channel. The server RTP/AVP interleaved on the RTSP control channel. The server selects
selects the RTP/AVP/UDP transport and adds the ports it will send and the RTP/AVP/UDP transport and adds the ports it will send and
received RTP and RTCP from, and the RTP SSRC that will be used by the received RTP and RTCP from, and the RTP SSRC that will be used by the
server. server.
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 13.4.11). An error 459 (Aggregate Operation Not Allowed) (see Section 13.4.11).
Aggregate control URI MUST be used to control an aggregated session. An Aggregate control URI MUST be used to control an aggregated
This URI MUST be different from the stream control URIs of the session. This URI MUST be different from the stream control URIs of
individual media streams included in the aggregate. The Aggregate the individual media streams included in the aggregate. The
control URI is to be specified by the session description if the Aggregate control URI is to be specified by the session description
server supports aggregated control and aggregated control is desired if the server supports aggregated control and aggregated control is
for the session. However even if aggregated control is offered the desired for the session. However even if aggregated control is
client MAY chose to not set up the session in aggregated control. If offered the client MAY chose to not set up the session in aggregated
an Aggregate control URI is not specified in the session description, control. If an Aggregate control URI is not specified in the session
it is normally an indication that non-aggregated control should be description, it is normally an indication that non-aggregated control
used. The SETUP of media streams in an aggregate which has not been should be used. The SETUP of media streams in an aggregate which has
given an aggregated control URI is unspecified. not been given an aggregated control URI is unspecified.
While the session ID sometimes has enough information for While the session ID sometimes has enough information for
aggregate control of a session, the Aggregate control URI aggregate control of a session, the Aggregate control URI is still
is still important for some methods such as SET_PARAMETER important for some methods such as SETPARAMETER where the control
where the control URI enables the resource in question to URI enables the resource in question to be easily identified. The
be easily identified. The Aggregate control URI is also Aggregate control URI is also useful for proxies, enabling them to
useful for proxies, enabling them to route the request to route the request to the appropriate server, and for logging,
the appropriate server, and for logging, where it is useful where it is useful to note the actual resource that a request was
to note the actual resource that a request was operating operating on.
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 14.42. Signs of liveness for an RTSP further discussion see Section 14.42. Signs of liveness for an RTSP
session are: session are:
o Any RTSP request from a client(s) which includes a Session o Any RTSP request from a client(s) which includes a Session header
header with that session's ID. with that session's ID.
o If RTP is used as a transport for the underlying media o If RTP is used as a transport for the underlying media streams, an
streams, an RTCP sender or receiver report from the client(s) RTCP sender or receiver report from the client(s) for any of the
for any of the media streams in that RTSP session. RTCP Sender media streams in that RTSP session. RTCP Sender Reports may for
Reports may for example be received in sessions where the example be received in sessions where the server is invited into a
server is invited into a conference session and is as valid conference session and is as valid for keep-alive.
for keep-alive.
If a SETUP request on a session fails for any reason, the session If a SETUP request on a session fails for any reason, the session
state, as well as transport and other parameters for associated state, as well as transport and other parameters for associated
streams SHALL remain unchanged from their values as if the SETUP streams SHALL remain unchanged from their values as if the SETUP
request had never been received by the server. request had never been received by the server.
11.3.1 Changing Transport Parameters 11.3.1. Changing Transport Parameters
A client MAY issue a SETUP request for a stream that is already set A client MAY issue a SETUP request for a stream that is already set
up or playing in the session to change transport parameters, which a up or playing in the session to change transport parameters, which a
server MAY allow. If it does not allow changing of parameters, it server MAY allow. If it does not allow changing of parameters, it
MUST respond with error 455 (Method Not Valid In This State). Reasons MUST respond with error 455 (Method Not Valid In This State).
to support changing transport parameters, is to allow for application Reasons to support changing transport parameters, is to allow for
layer mobility and flexibility to utilize the best available application layer mobility and flexibility to utilize the best
transport as it becomes available. If a client receives a 455 when available transport as it becomes available. If a client receives a
trying to change transport parameters while the server is in play 455 when trying to change transport parameters while the server is in
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 vise 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 SHALL include the Range to indicate while in Play state, the server SHALL 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 SHALL also include the RTP-Info RTP is used for delivery, the server SHALL 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 the change has taken place. If both RTP-Info and Range is included in
response the "rtp_time" parameter and range MUST be for the the response the "rtp_time" parameter and range MUST be for the
corresponding time, i.e. be used in the same way as for PLAY to corresponding time, i.e. be used in the same way as for PLAY to
ensure the correct synchronization information is available. ensure the correct synchronization information is 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.
11.4 PLAY 11.4. PLAY
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. PLAY requests are valid when the mechanism specified in SETUP. PLAY requests are valid when the
session is in READY or PLAY states. A PLAY request MUST include a session is in READY or PLAY states. A PLAY request MUST include a
Session header to indicate which session the request applies to. Session header to indicate which session the request applies to.
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 can procedure can reduce the without awaiting their responses. This can 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 an client needs to be aware started with one round trip time. However an client needs to be
that using this procedure will result in the playout of the server aware that using this procedure will result in the playout of the
state established at the time of processing the PLAY, i.e. after the server state established at the time of processing the PLAY, i.e.
processing of all the requests prior to the PLAY request in the after the processing of all the requests prior to the PLAY request in
pipeline. This may not be the intended one due to failure of any of the pipeline. This may not be the intended one due to failure of any
the prior requests. However a client easily determine this based on of the prior requests. However a client easily determine this based
the responses from those requests. In case of failure the client can on the responses from those requests. In case of failure the client
halt the media playout using PAUSE and try to establish the intended can halt the media playout using PAUSE and try to establish the
state again before issuing another PLAY request. intended state again before issuing another PLAY request.
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 SHALL responde with error 460 (Only Aggregate control URI. A server SHALL responde 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 SHALL be played in sync. If a client media. The media in an aggregate SHALL be played in sync. If a
want individual control of the media it needs to use separate RTSP client want individual control of the media it needs to use separate
sessions for each media. RTSP sessions for each media.
The PLAY request SHALL position the normal play time to the beginning The PLAY request SHALL position the normal play time to the beginning
of the range specified by the Range header and delivers stream data of the range specified by the Range header and delivers stream data
until the end of the range if given, else to the end of the media is until the end of the range if given, else to the end of the media is
reached. To allow for precise composition multiple ranges MAY be reached. To allow for precise composition multiple ranges MAY be
specified in one PLAY Request. The range values are valid if all specified in one PLAY Request. The range values are valid if all
given ranges are part of any media within the aggregate. If a given given ranges are part of any media within the aggregate. If a given
range value points outside of the media, the response SHALL be the range value points outside of the media, the response SHALL be the
457 (Invalid Range) error code. 457 (Invalid Range) error code.
skipping to change at page 52, line 10 skipping to change at page 58, line 36
See the description of the PAUSE request for further examples. See the description of the PAUSE request for further examples.
A PLAY request without a Range header is legal. It SHALL start A PLAY request without a Range header is legal. It SHALL start
playing a stream from the beginning (npt=0-) unless the stream has playing a stream from the beginning (npt=0-) unless the stream has
been paused or is currently playing. If a stream has been paused via been paused or is currently playing. If a stream has been paused via
PAUSE, stream delivery resumes at the pause point. If a stream is PAUSE, stream delivery resumes at the pause point. If a stream is
currently playing, the new PLAY begins at the current stream currently playing, the new PLAY begins at the current stream
position. The stream SHALL play until the end of the media. position. The stream SHALL play until the end of the media.
The Range header MUST NOT contain a time parameter. The usage of time The Range header MUST NOT contain a time parameter. The usage of
in PLAY method has been deprecated. If a request with time parameter time in PLAY method has been deprecated. If a request with time
is received the server SHOULD respond with a 457 (Invalid Range) to parameter is received the server SHOULD respond with a 457 (Invalid
indicate that the time parameter is not supported. Range) to indicate that the time parameter is not supported.
Server MUST include a "Range" header in any PLAY response. The Server MUST include a "Range" header in any PLAY response. The
response MUST use the same format as the request's range header response MUST use the same format as the request's range header
contained. If no Range header was in the request, the NPT time format contained. If no Range header was in the request, the NPT time
SHOULD be used unless the client showed support for an other format format SHOULD be used unless the client showed support for an other
more appropriate. Also for a session with live media streams the format more appropriate. Also for a session with live media streams
Range header MUST indicate a valid time. It is RECOMMENDED that the Range header MUST indicate a valid time. It is RECOMMENDED that
normal play time is used, either the "now" indicator, for example normal play time is used, either the "now" indicator, for example
"npt=now-", or the time since session start as an open interval, e.g. "npt=now-", or the time since session start as an open interval, e.g.
"npt=96.23-". An absolute time value (clock) for the corresponding "npt=96.23-". An absolute time value (clock) for the corresponding
time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock time MAY be given, i.e. "clock=20030213T143205Z-". The UTC clock
format SHOULD only be used if client has shown support for it. format SHOULD only be used if client has shown support for it.
For an on-demand stream, the server MUST reply with the actual range For an on-demand stream, the server MUST reply with the actual range
that will be played back, i.e. for which duration any media (having that will be played back, i.e. for which duration any media (having
content at this time) is delivered. This may differ from the content at this time) is delivered. This may differ from the
requested range if alignment of the requested range to valid frame requested range if alignment of the requested range to valid frame
skipping to change at page 53, line 4 skipping to change at page 59, line 29
Session: 12345678 Session: 12345678
Range: npt=7.05- Range: npt=7.05-
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration: 4.15 seconds Duration: 4.15 seconds
In this example the client receives the first media packet that In this example the client receives the first media packet that
stretches all the way up and past the requested playtime. Thus, it is stretches all the way up and past the requested playtime. Thus, it
the client's decision if to render to the user the time between 3.52 is the client's decision if to render to the user the time between
and 7.05, or to skip it. In most cases it is probably most suitable 3.52 and 7.05, or to skip it. In most cases it is probably most
to not render that time period. suitable to not render that time period.
For live media sources it might be impossible to specify from which For live media sources it might be impossible to specify from which
point in time all media streams carrying active content can actually point in time all media streams carrying active content can actually
be delivered. Therefore a server MAY specify a start time (or now-) be delivered. Therefore a server MAY specify a start time (or now-)
in the range header, for which not all media will be available from. in the range header, for which not all media will be available from.
If no range is specified in the request, the start position SHALL If no range is specified in the request, the start position SHALL
still be returned in the reply. If the medias that are part of an still be returned in the reply. If the medias that are part of an
aggregate has different lengths, the PLAY request SHALL be performed aggregate has different lengths, the PLAY request SHALL be performed
as long as the given range is valid for any media, for example the as long as the given range is valid for any media, for example the
longest media. Media will be sent whenever it is available for the longest media. Media will be sent whenever it is available for the
given play-out point. given play-out point.
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 section is needed. For RTP the RTP-Info header is specified, see
14.38. Section 14.38.
After playing the desired range, the presentation does NOT transition After playing the desired range, the presentation does NOT transition
to the READY state, media delivery simply stops. A PAUSE request MUST to the READY state, media delivery simply stops. A PAUSE request
be issued before the stream enters the READY state. A PLAY request MUST be issued before the stream enters the READY state. A PLAY
while the stream is still in the PLAYING state is legal, and can be request while the stream is still in the PLAYING state is legal, and
issued without an intervening PAUSE request. Such a request SHALL can be issued without an intervening PAUSE request. Such a request
replace the current PLAY action with the new one requested, i.e. SHALL replace the current PLAY action with the new one requested,
being handle the same as the request was received in ready state. In i.e. being handle the same as the request was received in ready
the case the first time range in Range header has a open start time state. In the case the first time range in Range header has a open
(-endtime), the server SHALL continue to play from where it currently start time (-endtime), the server SHALL continue to play from where
was until the specified end point. This is useful to change ongoing it currently was until the specified end point. This is useful to
playback to play another sequence, or end at another point than in change ongoing playback to play another sequence, or end at another
the previous request. point than in the previous 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 when
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 SHALL be included. pause point in a Range header SHALL be included.
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
skipping to change at page 55, line 6 skipping to change at page 61, line 28
All range specifiers in this specification allow for ranges with All range specifiers in this specification allow for ranges with
unspecified begin times (e.g. "npt=-30"). When used in a PLAY unspecified begin times (e.g. "npt=-30"). When used in a PLAY
request, the server treats this as a request to start/resume playback request, the server treats this as a request to start/resume playback
from the current pause point, ending at the end time specified in the from the current pause point, ending at the end time specified in the
Range header. If the pause point is located later than the given end Range header. If the pause point is located later than the given end
value, a 457 (Invalid Range) response SHALL be given. value, a 457 (Invalid Range) response SHALL be given.
The possibility to replace a current PLAY request with a new one The possibility to replace a current PLAY request with a new one
replaces two RTSP 1.0 functions: replaces two RTSP 1.0 functions:
o The queued play functionality described in RFC 2326 [25] is o The queued play functionality described in RFC 2326 [RFC2326] is
removed and multiple ranges can be used to achieve a similar removed and multiple ranges can be used to achieve a similar
functionality. functionality.
o The use of PLAY for keep-alive signaling, i.e. PLAY request o The use of PLAY for keep-alive signaling, i.e. PLAY request
without a range header in PLAY state, has also been without a range header in PLAY state, has also been deprecated.
deprecated. Instead a client can use, SET_PARAMETER Instead a client can use, SETPARAMETER (recommended) or OPTIONS
(recommended) or OPTIONS (allowed) for keep alive. (allowed) for keep alive.
An example of using PLAY request to change the behavior, if a server An example of using PLAY request to change the behavior, if a server
has received requests to play ranges 10 to 15 and then 13 to 20 (that has received requests to play ranges 10 to 15 and then 13 to 20 (that
is, overlapping ranges), a PLAY request 4 seconds after the first is, overlapping ranges), a PLAY request 4 seconds after the first
would take effect while the server plays the first range. Thus would take effect while the server plays the first range. Thus
changing the behavior to continue to play to 25 seconds, i.e. the changing the behavior to continue to play to 25 seconds, i.e. the
played range equal play with range: npt=10-25. If the second PLAY played range equal play with range: npt=10-25. If the second PLAY
request would arrive after the second range in the first range was request would arrive after the second range in the first range was
playing, then the equivalent request would be play with playing, then the equivalent request would be play with range:npt=10-
range:npt=10-15,npt=13-25. 15,npt=13-25.
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Range: npt=10-15, npt=13-20 Range: npt=10-15, npt=13-20
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
skipping to change at page 56, line 10 skipping to change at page 62, line 37
CSeq: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=14-15, npt=13-25 Range: npt=14-15, npt=13-25
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
Session: 12345678 Session: 12345678
11.5 PAUSE 11.5. PAUSE
The PAUSE request causes the stream delivery to immediately be The PAUSE request causes the stream delivery to immediately be
interrupted (halted). A PAUSE request MUST be done with the interrupted (halted). A PAUSE request MUST be done with the
aggregated control URI for aggregated sessions, resulting in all aggregated control URI for aggregated sessions, resulting in all
media being halted, or the media URI for non-aggregated sessions. media being halted, or the media URI for non-aggregated sessions.
Any attempt to do muting of a single media with an PAUSE request in Any attempt to do muting of a single media with an PAUSE request in
an aggregated session SHALL be responded with error 460 (Only an aggregated session SHALL be responded with error 460 (Only
Aggregate Operation Allowed). After resuming playback, Aggregate Operation Allowed). After resuming playback,
synchronization of the tracks MUST be maintained. Any server synchronization of the tracks MUST be maintained. Any server
resources are kept, though servers MAY close the session and free resources are kept, though servers MAY close the session and free
skipping to change at page 57, line 39 skipping to change at page 65, line 5
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=21-30 Range: npt=21-30
Session: 12345678 Session: 12345678
If a client issues a PAUSE request and the server acknowledges and If a client issues a PAUSE request and the server acknowledges and
enters the READY state, the proper server response, if the player enters the READY state, the proper server response, if the player
issues another PAUSE, is still 200 OK. The 200 OK response MUST issues another PAUSE, is still 200 OK. The 200 OK response MUST
include the Range header with the current pause point. See examples include the Range header with the current pause point. See examples
below: below:
Examples:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 834 CSeq: 834
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
skipping to change at page 58, line 14 skipping to change at page 65, line 25
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36 Range: npt=45.76-98.36
11.6 TEARDOWN 11.6. TEARDOWN
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 state.
The TEARDOWN request SHALL contain a Session header indicating what The TEARDOWN request SHALL contain a Session header indicating what
session the request applies to. 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
skipping to change at page 59, line 5 skipping to change at page 66, line 13
Example: Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0 C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892 CSeq: 892
Session: 12345678 Session: 12345678
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
11.7 GET_PARAMETER 11.7. GETPARAMETER
The GET_PARAMETER request retrieves the value of a parameter or The GETPARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URI. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
The method MAY also be used without a body (entity). If the this The method MAY also be used without a body (entity). If the this
request is successful, i.e. a 200 OK response is received, then the request is successful, i.e. a 200 OK response is received, then the
keep-alive timer has been updated. Any non-required header present in keep-alive timer has been updated. Any non-required header present
such a request may or may not been processed. To allow a client to in such a request may or may not been processed. To allow a client
determine if any such header has been processed, it is necessary to to determine if any such header has been processed, it is necessary
use a feature-tag and the Require header. Due to this reason it is to use a feature-tag and the Require header. Due to this reason it
RECOMMENDED that any parameters to be retrieved are sent in the body, is RECOMMENDED that any parameters to be retrieved are sent in the
rather than using any header. body, rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
packets_received packets_received
jitter jitter
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 431 CSeq: 431
Content-Length: 38 Content-Length: 38
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
The "text/parameters" section is only an example type for a body
carrying parameters.
The "text/parameters" section is only an example type for a 11.8. SET_PARAMETER
body carrying parameters.
11.8 SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a body (entity). It is the method MAY also be used without a body (entity). It is the
RECOMMENDED method to use in request sent for the sole purpose of RECOMMENDED method to use in request sent for the sole purpose of
updating the keep-alive timer. If this request is successful, i.e. a updating the keep-alive timer. If this request is successful, i.e. a
200 OK response is received, then the keep-alive timer has been 200 OK response is received, then the keep-alive timer has been
updated. Any non-required header present in such a request may or may updated. Any non-required header present in such a request may or
not been processed. To allow a client to determine if any such header may not been processed. To allow a client to determine if any such
has been processed, it is necessary to use a feature tag and the header has been processed, it is necessary to use a feature tag and
Require header. Due to this reason it is RECOMMENDED that any the Require header. Due to this reason it is RECOMMENDED that any
parameters are sent in the body, rather than using any header. parameters are sent in the body, rather than using any header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
request contains several parameters, the server MUST only act on the request contains several parameters, the server MUST only act on the
request if all of the parameters can be set successfully. A server request if all of the parameters can be set successfully. A server
MUST allow a parameter to be set repeatedly to the same value, but it MUST allow a parameter to be set repeatedly to the same value, but it
MAY disallow changing parameter values. If the receiver of the MAY disallow changing parameter values. If the receiver of the
request does not understand or cannot locate a parameter, error 451 request does not understand or cannot locate a parameter, error 451
(Parameter Not Understood) SHALL be used. In the case a parameter is (Parameter Not Understood) SHALL be used. In the case a parameter is
not allowed to change, the error code is 458 (Parameter Is Read- not allowed to change, the error code is 458 (Parameter Is Read-
Only). The response body SHOULD contain only the parameters that have Only). The response body SHOULD contain only the parameters that
errors. Otherwise no body SHALL be returned. have errors. Otherwise no body SHALL be returned.
Note: transport parameters for the media stream MUST only be set with Note: transport parameters for the media stream MUST only be set with
the SETUP command. the SETUP command.
Restricting setting transport parameters to SETUP is for Restricting setting transport parameters to SETUP is for the
the benefit of firewalls. benefit of firewalls.
The parameters are split in a fine-grained fashion so that The parameters are split in a fine-grained fashion so that there
there can be more meaningful error indications. However, it can be more meaningful error indications. However, it may make
may make sense to allow the setting of several parameters sense to allow the setting of several parameters if an atomic
if an atomic setting is desirable. Imagine device control setting is desirable. Imagine device control where the client
where the client does not want the camera to pan unless it does not want the camera to pan unless it can also tilt to the
can also tilt to the right angle at the same time. right angle at the same time.
Example: Example:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421 CSeq: 421
Content-length: 20 Content-length: 20
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
S->C: RTSP/2.0 451 Parameter Not Understood S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421 CSeq: 421
Content-length: 10 Content-length: 10
Content-type: text/parameters Content-type: text/parameters
barparam: barstuff barparam: barstuff
The "text/parameters" section is only an example type for The "text/parameters" section is only an example type for
parameters. This method is intentionally loosely defined parameters. This method is intentionally loosely defined with the
with the intention that the reply content and response intention that the reply content and response content will be
content will be defined by the one desiring to use this defined by the one desiring to use this mechanism.
mechanism.
11.9 REDIRECT 11.9. REDIRECT
The REDIRECT method is issued by a server to inform a client that it The REDIRECT method is issued by a server to inform a client that it
required to connect to another server location to access the resource required to connect to another server location to access the resource
indicated by the Request-URI. The presence of the Session header in a indicated by the Request-URI. The presence of the Session header in
REDIRECT request indicates the scope of the request, and determines a REDIRECT request indicates the scope of the request, and determines
the specific semantics of the request. the specific semantics of the request.
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 OPTIONAL Location there are other remaining end-to-end sessions. The OPTIONAL Location
header, if included in such a request, SHALL contain a complete header, if included in such a request, SHALL contain a complete
absolute URI pointing to the resource to which the client SHOULD absolute URI pointing to the resource to which the client SHOULD
reconnect. Specifically, the Location SHALL NOT contain just the host reconnect. Specifically, the Location SHALL NOT contain just the
and port. A client may receive a REDIRECT request with a Session host and port. A client may receive a REDIRECT request with a
header, if and only if, an end-to-end session has been established. Session header, if and only if, an end-to-end session has been
established.
A client may receive a REDIRECT request without a Session header at A client may receive a REDIRECT request without a Session header at
any time when it has communication or a connection established with a any time when it has communication or a connection established with a
server. The scope of such a request is limited to the next-hop (i.e. server. The scope of such a request is limited to the next-hop (i.e.
the RTSP agent in direct communication with the server) and applies, the RTSP agent in direct communication with the server) and applies,
as well, to the control connection between the next-hop RTSP agent as well, to the control connection between the next-hop RTSP agent
and the server. A REDIRECT request without a Session header and the server. A REDIRECT request without a Session header
indicates that all sessions and pending requests being managed via indicates that all sessions and pending requests being managed via
the control connection MUST be redirected. The OPTIONAL Location the control connection MUST be redirected. The OPTIONAL Location
header, if included in such a request, SHOULD contain an absolute URI header, if included in such a request, SHOULD contain an absolute URI
skipping to change at page 62, line 4 skipping to change at page 69, line 10
indicates that all sessions and pending requests being managed via indicates that all sessions and pending requests being managed via
the control connection MUST be redirected. The OPTIONAL Location the control connection MUST be redirected. The OPTIONAL Location
header, if included in such a request, SHOULD contain an absolute URI header, if included in such a request, SHOULD contain an absolute URI
with only the host address and the OPTIONAL port number of the server with only the host address and the OPTIONAL port number of the server
to which the RTSP agent SHOULD reconnect. Any intervening proxies to which the RTSP agent SHOULD reconnect. Any intervening proxies
SHOULD do all of the following in the order listed: SHOULD do all of the following in the order listed:
1. respond to the REDIRECT request 1. respond to the REDIRECT request
2. disconnect the control channel from the requesting server 2. disconnect the control channel from the requesting server
3. connect to the server at the given host address 3. connect to the server at the given host address
4. pass the REDIRECT request to each applicable client 4. pass the REDIRECT request to each applicable client (typically
(typically those clients with an active session or an those clients with an active session or an unanswered request)
unanswered request)
Note: The proxy is responsible for accepting REDIRECT responses from Note: The proxy is responsible for accepting REDIRECT responses
its clients; these responses MUST NOT be passed on to either the from its clients; these responses MUST NOT be passed on to either
original server or the redirected server. the original server or the redirected server.
The lack of a Location header in any REDIRECT request is indicative The lack of a Location header in any REDIRECT request is indicative
of the server no longer being able to fulfill the current request and of the server no longer being able to fulfill the current request and
having no alternatives for the client to continue with its normal having no alternatives for the client to continue with its normal
operation. It is akin to a server initiated TEARDOWN that applies operation. It is akin to a server initiated TEARDOWN that applies
both to sessions as well as the general connection associated with both to sessions as well as the general connection associated with
that client. that client.
When the Range header is not included in a REDIRECT request, the When the Range header is not included in a REDIRECT request, the
client SHOULD perform the redirection immediately and return a client SHOULD perform the redirection immediately and return a
skipping to change at page 62, line 48 skipping to change at page 70, line 6
time= parameter indicates the wall clock time by when the redirection time= parameter indicates the wall clock time by when the redirection
MUST take place. When the time= parameter is present in the range, MUST take place. When the time= parameter is present in the range,
any range value MUST be ignored even though it MUST be syntactically any range value MUST be ignored even though it MUST be syntactically
correct. To allow a client to determine that redirect time without correct. To allow a client to determine that redirect time without
being time synchronized with the server, the server SHALL include a being time synchronized with the server, the server SHALL include a
Date header in the request. When the indicated redirect point is Date header in the request. When the indicated redirect point is
reached, a client MUST issue a TEARDOWN request and SHOULD close the reached, a client MUST issue a TEARDOWN request and SHOULD close the
signalling connection after receiving a 2xx response. The normal signalling connection after receiving a 2xx response. The normal
connection considerations apply for the server. connection considerations apply for the server.
The differentiation of REDIRECT requests with and without The differentiation of REDIRECT requests with and without range
range headers is to allow for clear and explicit state headers is to allow for clear and explicit state handling. As the
handling. As the state in the server needs to be kept until state in the server needs to be kept until the point of
the point of redirection, the handling becomes more clear redirection, the handling becomes more clear if the client is
if the client is required to TEARDOWN the session at the required to TEARDOWN the session at the redirect point.
redirect point.
If the REDIRECT request times out following the rules in Section 9.4 If the REDIRECT request times out following the rules in Section 9.4
the server MAY terminate the session or transport connection that the server MAY terminate the session or transport connection that
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuses to respond to a REDIRECT request. misbehaving clients that refuses to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the Location header Note: The media resource indicated by the \header {Location header
can be identical, slightly different or totally different. can be identical, slightly different or totally different. This
This is the reason why a new DESCRIBE request SHOULD be is the reason why a new DESCRIBE request SHOULD be issued.
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 usage session is still valid except for the host address. However the
of conditional SETUP using ETag identifiers are RECOMMENDED to verify usage of conditional SETUP using ETag identifiers are RECOMMENDED to
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
Range: npt=0- ;time=19960213T143205Z Range: npt=0- ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK C->S: RTSP/2.0 200 OK
CSeq: 732 CSeq: 732
12 Embedded (Interleaved) Binary Data 12. Embedded (Interleaved) Binary Data
In order to fulfill certain requirements on the network side, e.g. In order to fulfill certain requirements on the network side, e.g. in
in conjunction with network address translators that block RTP conjunction with network address translators that block RTP traffic
traffic over UDP, it may be necessary to interleave RTSP messages and over UDP, it may be necessary to interleave RTSP messages and media
media stream data. This interleaving should generally be avoided stream data. This interleaving should generally be avoided unless
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.
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 SHALL contain exactly one upper-layer protocol headers. Each $ block SHALL contain exactly one upper-layer
skipping to change at page 64, line 33 skipping to change at page 71, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter(Section 14.45). interleaved parameter(Section 14.45).
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 range containing a second channel in the indicated by including a range containing a second channel in the
interleaved parameter of the Transport header, see section 14.45. If interleaved parameter of the Transport header, see Section 14.45. If
RTCP is used, packets SHALL be sent on the first available channel RTCP is used, packets SHALL 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 and
therefore RTCP traffic are sent on the second channel in both therefore RTCP traffic are sent on the second channel in both
directions. directions.
RTCP is sometime needed for synchronization when two or RTCP is sometime needed for synchronization when two or more
more streams are interleaved in such a fashion. Also, this streams are interleaved in such a fashion. Also, this provides a
provides a convenient way to tunnel RTP/RTCP packets convenient way to tunnel RTP/RTCP packets through the TCP control
through the TCP control connection when required by the connection when required by the network configuration and transfer
network configuration and transfer them onto UDP when them onto UDP when possible.
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
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6 Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: 12345678 Session: 12345678
skipping to change at page 65, line 31 skipping to change at page 73, line 5
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url="rtsp://example.com/bar.file" RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234 ssrc=0D12F123:seq=232433;rtptime=972948234
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $005{2 byte length}{"length" bytes data, w/RTP header} S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
S->C: $006{2 byte length}{"length" bytes RTCP packet} S->C: $006{2 byte length}{"length" bytes RTCP packet}
13 Status Code Definitions 13. Status Code Definitions
Where applicable, HTTP status [H10] codes are reused. Status codes Where applicable, HTTP status [H10] codes are reused. Status codes
that have the same meaning are not repeated here. See Table 4 for a that have the same meaning are not repeated here. See Table 4 for a
listing of which status codes may be returned by which requests. All listing of which status codes may be returned by which requests. All
error messages, 4xx and 5xx MAY return a body containing further error messages, 4xx and 5xx MAY return a body containing further
information about the error. information about the error.
13.1 Success 1xx 13.1. Success 1xx
13.1.1 100 Continue 13.1.1. 100 Continue
See, [H10.1.1]. See, [H10.1.1].
13.2 Success 2xx 13.2. Success 2xx
13.3. Redirection 3xx
13.3 Redirection 3xx
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.
See [H10.3] for definition of status code 300 to 305. However See [H10.3] for definition of status code 300 to 305. However
comments are given for some to how they apply to RTSP. comments are given for some to how they apply to RTSP.
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
redirecting stream requests to a server topologically closer to the redirecting stream requests to a server topologically closer to the
client. Mechanisms to determine topological proximity are beyond the client. Mechanisms to determine topological proximity are beyond the
scope of this specification. scope of this specification.
A 3rr code MAY be used to respond to any request. It is RECOMMENDED A 3rr code MAY be used to respond to any request. It is RECOMMENDED
that they are used if necessary before a session is established, i.e. that they are used if necessary before a session is established, i.e.
in response to DESCRIBE or SETUP. However in cases where a server is 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 MAY not able to send a REDIRECT request to the client, the server MAY
need to resort to using 3rr responses to inform a client with a need to resort to using 3rr responses to inform a client with a
established session about the need for redirecting the session. If an established session about the need for redirecting the session. If
3rr response is received for an request in relation to a established an 3rr response is received for an request in relation to a
session, the client SHOULD send a TEARDOWN request for the session, established session, the client SHOULD send a TEARDOWN request for
and MAY reestablish the session using the resource indicated by the the session, and MAY reestablish the session using the resource
Location. indicated by the Location.
If the the Location header is used in a response it SHALL contain an If the the Location header is used in a response it SHALL 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 SHALL NOT only contain the host name. to, the URI SHALL NOT only contain the host name.
13.3.1 300 Multiple Choices 13.3.1. 300 Multiple Choices
See [H10.3.1]. See [H10.3.1].
13.3.2 301 Moved Permanently 13.3.2. 301 Moved Permanently
The request resource are moved permanently and resides now at the URI The request resource are moved permanently and resides now at the URI
given by the location header. The user client SHOULD redirect given by the location header. The user client SHOULD redirect
automatically to the given URI. This response MUST NOT contain a automatically to the given URI. This response MUST NOT contain a
message-body. The Location header MUST be included in the response. message-body. The Location header MUST be included in the response.
13.3.3 302 Found 13.3.3. 302 Found
The requested resource resides temporarily at the URI given by the The requested resource resides temporarily at the URI given by the
Location header. The Location header MUST be included in the Location header. The Location header MUST be included in the
response. This response is intended to be used for many types of response. This response is intended to be used for many types of
temporary redirects; e.g., load balancing. It is RECOMMENDED that the temporary redirects; e.g., load balancing. It is RECOMMENDED that
server set the reason phrase to something more meaningful than the server set the reason phrase to something more meaningful than
"Found" in these cases. The user client SHOULD redirect automatically "Found" in these cases. The user client SHOULD redirect
to the given URI. This response MUST NOT contain a message-body. automatically to the given URI. This response MUST NOT contain a
message-body.
This example shows a client being redirected to a different server: This example shows a client being redirected to a different server:
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0 C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
C->S: RTSP/2.0 302 Try Other Server C->S: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
13.3.4 303 See Other 13.3.4. 303 See Other
This status code SHALL NOT be used in RTSP. However as it was allowed This status code SHALL NOT be used in RTSP. However as it was
to use in RTSP 1.0 (RFC 2326). allowed to use in RTSP 1.0 (RFC 2326).
13.3.5 304 Not Modified 13.3.5. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
14.25) and the requested resource has not been modified, the server Section 14.25) and the requested resource has not been modified, the
SHOULD send a 304 response. This response MUST NOT contain a server SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
o Date o Date
o ETag and/or Content-Location, if the header(s) would have been o ETag and/or Content-Location, if the header(s) would have been
sent in a 200 response to the same request. sent in a 200 response to the same request.
o Expires, Cache-Control, and/or Vary, if the field-value might o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant. variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
skipping to change at page 67, line 45 skipping to change at page 75, line 18
differ from that sent in any previous response for the same differ from that sent in any previous response for the same
variant. variant.
This response is independent for the DESCRIBE and SETUP requests. This response is independent for the DESCRIBE and SETUP requests.
That is, a 304 response to DESCRIBE does NOT imply that the resource That is, a 304 response to DESCRIBE does NOT imply that the resource
content is unchanged (only the session description) and a 304 content is unchanged (only the session description) and a 304
response to SETUP does NOT imply that the resource description is response to SETUP does NOT imply that the resource description is
unchanged. The ETag and If-Match headers may be used to link the unchanged. The ETag and If-Match headers may be used to link the
DESCRIBE and SETUP in this manner. DESCRIBE and SETUP in this manner.
13.3.6 305 Use Proxy 13.3.6. 305 Use Proxy
See [H10.3.6]. See [H10.3.6].
13.4 Client Error 4xx 13.4. Client Error 4xx
13.4.1 400 Bad Request 13.4.1. 400 Bad Request
The request could not be understood by the server due to malformed The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without syntax. The client SHOULD NOT repeat the request without
modifications [H10.4.1]. If the request does not have a CSeq header, modifications [H10.4.1]. If the request does not have a CSeq header,
the server MUST NOT include a CSeq in the response. the server MUST NOT include a CSeq in the response.
13.4.2 405 Method Not Allowed 13.4.2. 405 Method Not Allowed
The method specified in the request is not allowed for the resource The method specified in the request is not allowed for the resource
identified by the Request-URI. The response MUST include an Allow identified by the Request-URI. The response MUST include an Allow
header containing a list of valid methods for the requested resource. header containing a list of valid methods for the requested resource.
This status code is also to be used if a request attempts to use a This status code is also to be used if a request attempts to use a
method not indicated during SETUP, e.g., if a RECORD request is method not indicated during SETUP, e.g., if a RECORD request is
issued even though the mode parameter in the Transport header only issued even though the mode parameter in the Transport header only
specified PLAY. specified PLAY.
13.4.3 451 Parameter Not Understood 13.4.3. 451 Parameter Not Understood
The recipient of the request does not support one or more parameters The recipient of the request does not support one or more parameters
contained in the request. When returning this error message the contained in the request. When returning this error message the
sender SHOULD return a entity body containing the offending sender SHOULD return a entity body containing the offending
parameter(s). parameter(s).
13.4.4 452 reserved 13.4.4. 452 reserved
This error code was removed from RFC 2326 [25] and is obsolete. This error code was removed from RFC 2326 [RFC2326] and is obsolete.
13.4.5 453 Not Enough Bandwidth 13.4.5. 453 Not Enough Bandwidth
The request was refused because there was insufficient bandwidth. The request was refused because there was insufficient bandwidth.
This may, for example, be the result of a resource reservation This may, for example, be the result of a resource reservation
failure. failure.
13.4.6 454 Session Not Found 13.4.6. 454 Session Not Found
The RTSP session identifier in the Session header is missing, The RTSP session identifier in the Session header is missing,
invalid, or has timed out. invalid, or has timed out.
13.4.7 455 Method Not Valid in This State 13.4.7. 455 Method Not Valid in This State
The client or server cannot process this request in its current The client or server cannot process this request in its current
state. The response SHALL contain an Allow header to make error state. The response SHALL contain an Allow header to make error
recovery possible. recovery possible.
13.4.8 456 Header Field Not Valid for Resource 13.4.8. 456 Header Field Not Valid for Resource
The server could not act on a required request header. For example, The server could not act on a required request header. For example,
if PLAY contains the Range header field but the stream does not allow if PLAY contains the Range header field but the stream does not allow
seeking. This error message may also be used for specifying when the seeking. This error message may also be used for specifying when the
time format in Range is impossible for the resource. In that case the time format in Range is impossible for the resource. In that case
Accept-Ranges header SHALL be returned to inform the client of which the Accept-Ranges header SHALL be returned to inform the client of
format(s) that are allowed. which format(s) that are allowed.
13.4.9 457 Invalid Range 13.4.9. 457 Invalid Range
The Range value given is out of bounds, e.g., beyond the end of the The Range value given is out of bounds, e.g., beyond the end of the
presentation. presentation.
13.4.10 458 Parameter Is Read-Only 13.4.10. 458 Parameter Is Read-Only
The parameter to be set by SET_PARAMETER can be read but not The parameter to be set by SET_PARAMETER can be read but not
modified. When returning this error message the sender SHOULD return modified. When returning this error message the sender SHOULD return
a entity body containing the offending parameter(s). a entity body containing the offending parameter(s).
13.4.11 459 Aggregate Operation Not Allowed 13.4.11. 459 Aggregate Operation Not Allowed
The requested method may not be applied on the URI in question since The requested method may not be applied on the URI in question since
it is an aggregate (presentation) URI. The method may be applied on a it is an aggregate (presentation) URI. The method may be applied on
media URI. a media URI.
13.4.12 460 Only Aggregate Operation Allowed 13.4.12. 460 Only Aggregate Operation Allowed
The requested method may not be applied on the URI in question since The requested method may not be applied on the URI in question since
it is not an aggregate control (presentation) URI. The method may be it is not an aggregate control (presentation) URI. The method may be
applied on the aggregate control URI. applied on the aggregate control URI.
13.4.13 461 Unsupported Transport 13.4.13. 461 Unsupported Transport
The Transport field did not contain a supported transport The Transport field did not contain a supported transport
specification. specification.
13.4.14 462 Destination Unreachable 13.4.14. 462 Destination Unreachable
The data transmission channel could not be established because the The data transmission channel could not be established because the
client address could not be reached. This error will most likely be client address could not be reached. This error will most likely be
the result of a client attempt to place an invalid dest_addr the result of a client attempt to place an invalid dest_addr
parameter in the Transport field. parameter in the Transport field.
13.4.15 463 Destination Prohibited 13.4.15. 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.
13.4.16 464 Data Transport Not Ready Yet 13.4.16. 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 expects
that the data transmission channel will be established at this point that the data transmission channel will be established at this point
in time. Note however that this may result in a permanent failure in time. Note however that this may result in a permanent failure
like 462 "Destination Unreachable". 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.
13.4.17 470 Connection Authorization Required 13.4.17. 470 Connection Authorization Required
The secured connection attempt need user or client authorization The secured connection attempt need 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.
13.4.18 471 Connection Credentials not accepted 13.4.18. 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.
13.5 Server Error 5xx 13.5. Server Error 5xx
13.5.1 551 Option not supported 13.5.1. 551 Option not supported
A feature-tag given in the Require or the Proxy-Require fields was A feature-tag given in the Require or the Proxy-Require fields was
not supported. The Unsupported header SHALL be returned stating the not supported. The Unsupported header SHALL be returned stating the
feature for which there is no support. feature for which there is no support.
14 Header Field Definitions 14. Header Field Definitions
The general syntax for header fields is covered in Section 4.2 This
section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for header fields are
present in section 19.2.3. Throughout this section, we use [HX.Y] to
refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[3]. Examples of each header field are given.
Information about header fields in relation to methods and proxy
processing is summarized in Tables 9, 10, 11, and 12.
method direction object acronym Body +--------------+----------------+--------+---------+------+
_________________________________________________ | method | direction | object | acronym | Body |
DESCRIBE C -> S P,S DES r +--------------+----------------+--------+---------+------+
GET_PARAMETER C -> S, S -> C P,S GPR R,r | DESCRIBE | C -> S | P,S | DES | r |
OPTIONS C -> S P,S OPT | | | | | |
S -> C | GETPARAMETER | C -> S, S -> C | P,S | GPR | R,r |
PAUSE C -> S P,S PSE | | | | | |
PLAY C -> S P,S PLY | OPTIONS | C -> S | P,S | OPT | |
REDIRECT S -> C P,S RDR | | | | | |
SETUP C -> S S STP | | S -> C | | | |
SET_PARAMETER C -> S, S -> C P,S SPR R,r | | | | | |
TEARDOWN C -> S P,S TRD | PAUSE | C -> S | P,S | PSE | |
| | | | | |
| PLAY | C -> S | P,S | PLY | |
| | | | | |
| REDIRECT | S -> C | P,S | RDR | |
| | | | | |
| SETUP | C -> S | S | STP | |
| | | | | |
| SETPARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | |
| TEARDOWN | C -> S | P,S | TRD | |
+--------------+----------------+--------+---------+------+
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section
Section 4.2 This section lists the full set of header fields along
with notes on meaning, and usage. The syntax definition for header
fields are present in section Section 19.2.3. Throughout this
section, we use [HX.Y] to refer to Section X.Y of the current
HTTP/1.1 specification RFC 2616 [RFC2616]. Examples of each header
field are given.
Information about header fields in relation to methods and proxy
processing is summarized in Table 9, Table 10, Table 11, and
Table 12.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
R: header field may only appear in requests; R: header field may only appear in requests;
r: header field may only appear in responses; r: header field may only appear in responses;
2xx, 4xx, etc.: A numerical value or range indicates response 2xx, 4xx, etc.: A numerical value or range indicates response codes
codes with which the header field can be used; with which the header field can be used;
c: header field is copied from the request to the response. c: header field is copied from the request to the response.
An empty entry in the "where" column indicates that the header field An empty entry in the "where" column indicates that the header field
may be present in both requests and responses. may be present in both requests and responses.
The "proxy" column describes the operations a proxy may perform on a The "proxy" column describes the operations a proxy may perform on a
header field. An empty proxy column indicates that the proxy SHALL header field. An empty proxy column indicates that the proxy SHALL
NOT do any changes to that header, all allowed operations are NOT do any changes to that header, all allowed operations are
explicitly stated: explicitly stated:
a: A proxy can add or concatenate the header field if not a: A proxy can add or concatenate the header field if not present.
present.
m: A proxy can modify an existing header field value. m: A proxy can modify an existing header field value.
d: A proxy can delete a header field value. d: A proxy can delete a header field value.
r: A proxy needs to be able to read the header field, and thus r: A proxy needs to be able to read the header field, and thus
this header field cannot be encrypted. this header field cannot be encrypted.
The rest of the columns relate to the presence of a header field in a The rest of the columns relate to the presence of a header field in a
method. The method names when abbreviated, are according to table 8: method. The method names when abbreviated, are according to table
XXX {tab:methods2:
c: Conditional; requirements on the header field depend on the c: Conditional; requirements on the header field depend on the
context of the message. context of the message.
m: The header field is mandatory. m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to m*: The header field SHOULD be sent, but clients/servers need to be
be prepared to receive messages without that header field. prepared to receive messages without that header field.
o: The header field is optional. o: The header field is optional.
*: The header field is SHALL be present if the message body is *: The header field is SHALL be present if the message body is not
not empty. See sections 14.16, 14.18 and 4.3 for details. empty. See Section 14.16, Section 14.18 and Section 4.3 for
details.
-: The header field is not applicable. -: The header field is not applicable.
"Optional" means that a Client/Server MAY include the header field in "Optional" means that a Client/Server MAY include the header field in
a request or response. The Client/Server behavior when receiving such a request or response. The Client/Server behavior when receiving
headers varies, for some it may ignore the header field, in other such headers varies, for some it may ignore the header field, in
case it is request to process the header. This is regulated by the other case it is request to process the header. This is regulated by
method and header descriptions. Example of such headers that require the method and header descriptions. Example of such headers that
processing are the Require and Proxy-Require header fields discussed require processing are the Require and Proxy-Require header fields
in 14.37 and 14.31. A "mandatory" header field MUST be present in a discussed in Section 14.37 and Section 14.31. A "mandatory" header
request, and MUST be understood by the Client/Server receiving the field MUST be present in a request, and MUST be understood by the
request. A mandatory response header field MUST be present in the Client/Server receiving the request. A mandatory response header
response, and the header field MUST be understood by the field MUST be present in the response, and the header field MUST be
Client/Server processing the response. "Not applicable" means that understood by the Client/Server processing the response. "Not
the header field MUST NOT be present in a request. If one is placed applicable" means that the header field MUST NOT be present in a
in a request by mistake, it MUST be ignored by the Client/Server request. If one is placed in a request by mistake, it MUST be
receiving the request. Similarly, a header field labeled "not ignored by the Client/Server receiving the request. Similarly, a
applicable" for a response means that the Client/Server MUST NOT header field labeled "not applicable" for a response means that the
place the header field in the response, and the Client/Server MUST Client/Server MUST NOT place the header field in the response, and
ignore the header field in the response. the Client/Server MUST ignore the header field in the response.
An RTSP agent SHALL ignore extension headers that are not understood. An RTSP agent SHALL ignore extension headers that are not understood.
The From and Location header fields contain an URI. If the URI The From and Location header fields contain an URI. If the URI
contains a comma, or semicolon, the URI MUST be enclosed in double contains a comma, or semicolon, the URI MUST be enclosed in double
quotas ("). Any URI parameters are contained within these quotas. If quotas ("). Any URI parameters are contained within these quotas.
the URI is not enclosed in double quotas, any semicolon- delimited If the URI is not enclosed in double quotas, any semicolon- delimited
parameters are header-parameters, not URI parameters. parameters are header-parameters, not URI parameters.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD +----------------+------+-----+-----+-----+------+-----+------+-----+
_________________________________________________________________ | Header | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD |
Accept R o - - - - - | | e | xy | | | P | Y | E | |
Accept-Credentials R r o o o o o o +----------------+------+-----+-----+-----+------+-----+------+-----+
Accept-Encoding R r o - - - - - | Accept | R | | o | - | - | - | - | - |
Accept-Language R r o - - - - - | | | | | | | | | |
Accept-Ranges R r - - m - - - | Accept-Credent | R | r | o | o | o | o | o | o |
Accept-Ranges r r - - o - - - | ials | | | | | | | | |
Accept-Ranges 456 r - - - o - - | | | | | | | | | |
Allow r am c c c - - - | Accept-Encodin | R | r | o | - | - | - | - | - |
Allow 405 am m m m m m m | g | | | | | | | | |
Authorization R o o o o o o | | | | | | | | | |
Bandwidth R o o o o - - | Accept-Languag | R | r | o | - | - | - | - | - |
Blocksize R o - o o - - | e | | | | | | | | |
Cache-Control r o - o - - - | | | | | | | | | |
Connection o o o o o o | Accept-Ranges | R | r | - | - | m | - | - | - |
Connection-Credentials 470,407 ar o o o o o o | | | | | | | | | |
Content-Base r o - - - - - | Accept-Ranges | r | r | - | - | o | - | - | - |
Content-Base 4xx,5xx o o o o o o | | | | | | | | | |
Content-Encoding R r - - - - - - | Accept-Ranges | 456 | r | - | - | - | o | - | - |
Content-Encoding r r o - - - - - | | | | | | | | | |
Content-Encoding 4xx,5xx r o o o o o o | Allow | r | am | c | c | c | - | - | - |
Content-Language R r - - - - - - | | | | | | | | | |
Content-Language r r o - - - - - | Allow | 405 | am | m | m | m | m | m | m |
Content-Language 4xx,5xx r o o o o o o | Authorization | R | | o | o | o | o | o | o |
Content-Length r r * - - - - - | | | | | | | | | |
Content-Length 4xx,5xx r * * * * * * | Bandwidth | R | | o | o | o | o | - | - |
Content-Location r o - - - - - | | | | | | | | | |
Content-Location 4xx,5xx o o o o o o | Blocksize | R | | o | - | o | o | - | - |
Content-Type r * - - - - - | | | | | | | | | |
Content-Type 4xx,5xx * * * * * * | Cache-Control | | r | o | - | o | - | - | - |
CSeq Rc rm m m m m m m | | | | | | | | | |
Date am o o o o o o | Connection | | | o | o | o | o | o | o |
ETag r r o - o - - - | | | | | | | | | |
Expires r r o - - - - - | Connection-Cre | 470, | ar | o | o | o | o | o | o |
From R r o o o o o o | dentials | 407 | | | | | | | |
If-Match R r - - o - - - | | | | | | | | | |
If-Modified-Since R r o - o - - - | Content-Base | r | | o | - | - | - | - | - |
If-None-Match R r o - - - - - | | | | | | | | | |
Last-Modified r r o - - - - - | Content-Base | 4xx, | | o | o | o | o | o | o |
Location 3rr o o o o o o | | 5xx | | | | | | | |
| | | | | | | | | |
| Content-Encodi | R | r | - | - | - | - | - | - |
| ng | | | | | | | | |
| | | | | | | | | |
| Content-Encodi | r | r | o | - | - | - | - | - |
| ng | | | | | | | | |
| | | | | | | | | |
| Content-Encodi | 4xx, | r | o | o | o | o | o | o |
| ng | 5xx | | | | | | | |
| | | | | | | | | |
| Content-Langua | R | r | - | - | - | - | - | - |
| ge | | | | | | | | |
| | | | | | | | | |
| Content-Langua | r | r | o | - | - | - | - | - |
| ge | | | | | | | | |
| | | | | | | | | |
| Content-Langua | 4xx, | r | o | o | o | o | o | o |
| ge | 5xx | | | | | | | |
| | | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - |
| | | | | | | | | |
| Content-Length | 4xx, | r | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| | | | | | | | | |
| Content-Locati | r | | o | - | - | - | - | - |
| on | | | | | | | | |
| | | | | | | | | |
| Content-Locati | 4xx, | | o | o | o | o | o | o |
| on | 5xx | | | | | | | |
| | | | | | | | | |
| Content-Type | r | | * | - | - | - | - | - |
| Content-Type | 4xx, | | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| | | | | | | | | |
| CSeq | Rc | rm | m | m | m | m | m | m |
| | | | | | | | | |
| Date | | am | o | o | o | o | o | o |
| | | | | | | | | |
| ETag | r | r | o | - | o | - | - | - |
| | | | | | | | | |
| Expires | r | r | o | - | - | - | - | - |
| | | | | | | | | |
| From | R | r | o | o | o | o | o | o |
| | | | | | | | | |
| If-Match | R | r | - | - | o | - | - | - |
| | | | | | | | | |
| If-Modified-Si | R | r | o | - | o | - | - | - |
| nce | | | | | | | | |
| | | | | | | | | |
| If-None-Match | R | r | o | - | - | - | - | - |
| | | | | | | | | |
| Last-Modified | r | r | o | - | - | - | - | - |
| | | | | | | | | |
| Location | 3rr | | o | o | o | o | o | o |
+----------------+------+-----+-----+-----+------+-----+------+-----+
Table 9: Overview of RTSP header fields (A-L) related to methods Table 9: Overview of RTSP header fields (A-L) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD +------------+-------+------+----+-----+-------+------+-------+-----+
______________________________________________________________ | Header | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD |
Proxy-Authenticate 407 amr m m m m m m | | | y | S | | | | | |
Proxy-Authorization R rd o o o o o o +------------+-------+------+----+-----+-------+------+-------+-----+
Proxy-Require R ar o o o o o o | Proxy- | 407 | amr | m | m | m | m | m | m |
Proxy-Require r r c c c c c c | Authentica | | | | | | | | |
Proxy-Supported R amr c c c c c c | te | | | | | | | | |
Proxy-Supported r c c c c c c | | | | | | | | | |
Public r admr - m - - - - | Proxy- | R | rd | o | o | o | o | o | o |
Public 501 admr m m m m m m | Authorizat | | | | | | | | |
Range R - - - o - - | ion | | | | | | | | |
Range r - - c m m - | | | | | | | | | |
Referer R o o o o o o | Proxy- | R | ar | o | o | o | o | o | o |
Require R o o o o o o | Require | | | | | | | | |
Retry-After 3rr,503 o o o - - - | | | | | | | | | |
RTP-Info r - - o c - - | Proxy- | r | r | c | c | c | c | c | c |
Scale - - - o - - | Require | | | | | | | | |
Session R r - o o m m m | | | | | | | | | |
Session r r - c m m m o | Proxy- | R | amr | c | c | c | c | c | c |
Server R r - o - - - - | Supported | | | | | | | | |
Server r r o o o o o o | Proxy- | r | | c | c | c | c | c | c |
Speed - - - o - - | Supported | | | | | | | | |
Supported R amr o o o o o o | | | | | | | | | |
Supported r amr c c c c c c | Public | r | admr | - | m | - | - | - | - |
Timestamp R admr o o o o o o | | | | | | | | | |
Timestamp c admr m m m m m m | Public | 501 | admr | m | m | m | m | m | m |
Transport amr - - m - - - | | | | | | | | | |
Unsupported r c c c c c c | Range | R | | - | - | - | o | - | - |
User-Agent R m* m* m* m* m* m* | | | | | | | | | |
Vary r c c c c c c | Range | r | | - | - | c | m | m | - |
Via R amr o o o o o o | | | | | | | | | |
Via c dr m m m m m m | Referer | R | | o | o | o | o | o | o |
WWW-Authenticate 401 m m m m m m | | | | | | | | | |
| Require | R | | o | o | o | o | o | o |
______________________________________________________________ | | | | | | | | | |
Header Where Proxy DES OPT SETUP PLAY PAUSE TRD | Retry-Afte | 3rr,5 | | o | o | o | - | - | - |
| r | 03 | | | | | | | |
| | | | | | | | | |
| RTP-Info | r | | - | - | o | c | - | - |
| | | | | | | | | |
| Scale | | | - | - | - | o | - | - |
| | | | | | | | | |
| Session | R | r | - | o | o | m | m | m |
| | | | | | | | | |
| Session | r | r | - | c | m | m | m | o |
| | | | | | | | | |
| Server | R | r | - | o | - | - | - | - |
| | | | | | | | | |
| Server | r | r | o | o | o | o | o | o |
| | | | | | | | | |
| Speed | | | - | - | - | o | - | - |
| | | | | | | | | |
| Supported | R | amr | o | o | o | o | o | o |
| | | | | | | | | |
| Supported | r | amr | c | c | c | c | c | c |
| | | | | | | | | |
| Timestamp | R | admr | o | o | o | o | o | o |
| | | | | | | | | |
| Timestamp | c | admr | m | m | m | m | m | m |
| | | | | | | | | |
| Transport | | amr | - | - | m | - | - | - |
| | | | | | | | | |
| Unsupporte | r | | c | c | c | c | c | c |
| d | | | | | | | | |
| | | | | | | | | |
| User-Agent | R | | m* | m* | m* | m* | m* | m* |
| | | | | | | | | |
| Vary | r | | c | c | c | c | c | c |
| Via | R | amr | o | o | o | o | o | o |
| | | | | | | | | |
| Via | c | dr | m | m | m | m | m | m |
| | | | | | | | | |
| WWW- | 401 | | m | m | m | m | m | m |
| Authentica | | | | | | | | |
| te | | | | | | | | |
+------------+-------+------+----+-----+-------+------+-------+-----+
Table 10: Overview of RTSP header fields (P-W) related to methods Table 10: Overview of RTSP header fields (P-W) related to methods
DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN. DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.
14.1 Accept +------------------------+---------+-------+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR |
+------------------------+---------+-------+-----+-----+-----+
| Accept-Credentials | R | r | o | o | o |
| | | | | | |
| Allow | 405 | amr | m | m | m |
| | | | | | |
| Authorization | R | | o | o | o |
| | | | | | |
| Bandwidth | R | | - | o | - |
| | | | | | |
| Blocksize | R | | - | o | - |
| | | | | | |
| Connection | | | o | o | o |
| | | | | | |
| Connection-Credentials | 470,407 | ar | o | o | o |
| | | | | | |
| Content-Base | R | | o | o | - |
| | | | | | |
| Content-Base | r | | o | o | - |
| | | | | | |
| Content-Base | 4xx,5xx | | o | o | o |
| | | | | | |
| Content-Encoding | R | r | o | o | - |
| | | | | | |
| Content-Encoding | r | r | o | o | - |
| | | | | | |
| Content-Encoding | 4xx,5xx | r | o | o | o |
| | | | | | |
| Content-Language | R | r | o | o | - |
| | | | | | |
| Content-Language | r | r | o | o | - |
| | | | | | |
| Content-Language | 4xx,5xx | r | o | o | o |
| | | | | | |
| Content-Length | R | r | * | * | - |
| Content-Length | r | r | * | * | - |
| | | | | | |
| Content-Length | 4xx,5xx | r | * | * | * |
| | | | | | |
| Content-Location | R | | o | o | - |
| | | | | | |
| Content-Location | r | | o | o | - |
| | | | | | |
| Content-Location | 4xx,5xx | | o | o | o |
| | | | | | |
| Content-Type | R | | * | * | - |
| | | | | | |
| Content-Type | r | | * | * | - |
| | | | | | |
| Content-Type | 4xx | | * | * | * |
| | | | | | |
| CSeq | R,c | mr | m | m | m |
| | | | | | |
| Date | R | a | o | o | m |
| | | | | | |
| Date | r | am | o | o | o |
| | | | | | |
| From | R | r | o | o | o |
| | | | | | |
| Last-Modified | R | r | - | - | - |
| | | | | | |
| Last-Modified | r | r | o | - | - |
| | | | | | |
| Location | 3rr | | o | o | o |
| | | | | | |
| Location | R | | - | - | m |
| | | | | | |
| Proxy-Authenticate | 407 | amr | m | m | m |
| | | | | | |
| Proxy-Authorization | R | rd | o | o | o |
| | | | | | |
| Proxy-Require | R | ar | o | o | o |
| | | | | | |
| Proxy-Require | r | r | c | c | c |
| | | | | | |
| Proxy-Supported | R | amr | c | c | c |
| | | | | | |
| Proxy-Supported | r | | c | c | c |
| | | | | | |
| Public | 501 | admr | m | m | m |
+------------------------+---------+-------+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods
GETPARAMETER, SETPARAMETER, and REDIRECT.
+------------------+---------+-------+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR |
+------------------+---------+-------+-----+-----+-----+
| Range | R | | - | - | o |
| | | | | | |
| Referer | R | | o | o | o |
| | | | | | |
| Require | R | r | o | o | o |
| | | | | | |
| Retry-After | 3rr,503 | | o | o | - |
| | | | | | |
| Scale | | | - | - | - |
| | | | | | |
| Session | R | r | o | o | o |
| | | | | | |
| Session | r | r | c | c | o |
| | | | | | |
| Server | R | r | o | o | o |
| | | | | | |
| Server | r | r | o | o | - |
| | | | | | |
| Supported | R | adrm | o | o | o |
| | | | | | |
| Supported | r | adrm | c | c | c |
| | | | | | |
| Timestamp | R | adrm | o | o | o |
| | | | | | |
| Timestamp | c | adrm | m | m | m |
| | | | | | |
| Unsupported | r | arm | c | c | c |
| | | | | | |
| User-Agent | R | r | m* | m* | - |
| | | | | | |
| User-Agent | r | r | - | - | m* |
| | | | | | |
| Vary | r | | c | c | - |
| | | | | | |
| Via | R | amr | o | o | o |
| | | | | | |
| Via | c | dr | m | m | m |
| | | | | | |
| WWW-Authenticate | 401 | | m | m | m |
+------------------+---------+-------+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods
GETPARAMETER, SETPARAMETER, and REDIRECT.
14.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: Example of use:
Accept: application/example q=1.0, application/sdp Accept: application/example q=1.0, application/sdp
14.2 Accept-Credentials 14.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 18 for the usage of this header. It proxies or servers. See Section Section 18 for the usage of this
SHALL NOT be included in server to client requests. header. It SHALL NOT be included in server to client requests.
In a request the header SHALL contain the method (User, Proxy, or In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy. If the method is "User" the header SHALL NOT be changed by any proxy. If the method is "User" the
contains zero or more of credentials that the client accept. The header contains zero or more of credentials that the client accept.
header may contain zero credentials in the first RTSP request to a The header may contain zero credentials in the first RTSP request to
RTSP server when using the "User" method. This as the client has not a RTSP server when using the "User" method. This as the client has
yet received any credentials to accept. Each credential SHALL consist not yet received any credentials to accept. Each credential SHALL
of one URI identifying the proxy or server, the hash algorithm consist of one URI identifying the proxy or server, the hash
identifier, and the hash over that entity's DER encoded certificate algorithm identifier, and the hash over that entity's DER encoded
[14] in Base64. All RTSP clients and proxies SHALL implement the certificate [RFC3280]"/> in Base64. All RTSP clients and proxies
SHA-1 [15] algorithm for computation of the hash of the DER encoded SHALL implement the SHA-1[FIPS-pub-180-1] algorithm for computation
certificate. The SHA-1 algorithm is identified by the token "sha-1". of the hash of the DER encoded certificate. The SHA-1 algorithm is
identified by the token "sha-1".
The intention with allowing for other hash algorithms is to enable The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited. for this purpose is intended to be extremely limited.
Example: Example:
Accept-Credentials:User, Accept-Credentials:User,
"rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=, "rtsps://proxy2.example.com/";sha-1;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M= "rtsps://server.example.com/";sha-1;lurbjj5khhB0NhIuOXtt4bBRH1M=
14.3 Accept-Encoding 14.3. Accept-Encoding
Header Where Proxy GPR SPR RDR
__________________________________________________
Accept-Credentials R r o o o
Allow 405 amr m m m
Authorization R o o o
Bandwidth R - o -
Blocksize R - o -
Connection o o o
Connection-Credentials 470,407 ar o o o
Content-Base R o o -
Content-Base r o o -
Content-Base 4xx,5xx o o o
Content-Encoding R r o o -
Content-Encoding r r o o -
Content-Encoding 4xx,5xx r o o o
Content-Language R r o o -
Content-Language r r o o -
Content-Language 4xx,5xx r o o o
Content-Length R r * * -
Content-Length r r * * -
Content-Length 4xx,5xx r * * *
Content-Location R o o -
Content-Location r o o -
Content-Location 4xx,5xx o o o
Content-Type R * * -
Content-Type r * * -
Content-Type 4xx * * *
CSeq R,c mr m m m
Date R a o o m
Date r am o o o
From R r o o o
Last-Modified R r - - -
Last-Modified r r o - -
Location 3rr o o o
Location R - - m
Proxy-Authenticate 407 amr m m m
Proxy-Authorization R rd o o o
Proxy-Require R ar o o o
Proxy-Require r r c c c
Proxy-Supported R amr c c c
Proxy-Supported r c c c
Public 501 admr m m m
__________________________________________________
Header Where Proxy GPR SPR RDR
Table 11: Overview of RTSP header fields (A-P) related to methods
GET_PARAMETER, SET_PARAMETER, and REDIRECT.
Header Where Proxy GPR SPR RDR
____________________________________________
Range R - - o
Referer R o o o
Require R r o o o
Retry-After 3rr,503 o o -
Scale - - -
Session R r o o o
Session r r c c o
Server R r o o o
Server r r o o -
Supported R adrm o o o
Supported r adrm c c c
Timestamp R adrm o o o
Timestamp c adrm m m m
Unsupported r arm c c c
User-Agent R r m* m* -
User-Agent r r - - m*
Vary r c c -
Via R amr o o o
Via c dr m m m
WWW-Authenticate 401 m m m
____________________________________________
Header Where Proxy GPR SPR RDR
Table 12: Overview of RTSP header fields (R-W) related to methods
GET_PARAMETER, SET_PARAMETER, and REDIRECT.
See [H14.3] See [H14.3].
14.4 Accept-Language 14.4. Accept-Language
See [H14.4]. Note that the language specified applies to the See [H14.4]. Note that the language specified applies to the
presentation description and any reason phrases, not the media presentation description and any reason phrases, not the media
content. content.
14.5 Accept-Ranges 14.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 SHALL include of the format supported in the Range header. The client SHALL
the header in SETUP requests to indicate which formats it support to include the header in SETUP requests to indicate which formats it
receive in PLAY and PAUSE responses, and REDIRECT requests. The support to receive in PLAY and PAUSE responses, and REDIRECT
server SHALL include the header in SETUP and 456 error responses to requests. The server SHALL include the header in SETUP and 456 error
indicate the formats supported for the resource indicated by the responses to indicate the formats supported for the resource
request URI. indicated by the request URI.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined This header has the same syntax as [H14.5] and the syntax is defined
in 19.2.3. However, new range-units are defined. in Section 19.2.3. However, new range-units are defined.
14.6 Allow 14.6. Allow
The Allow entity-header field lists the methods supported by the The Allow entity-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. The Allow Allowed) response. See [H14.7] for syntax definition. The Allow
header MUST also be present in all OPTIONS responses where the header MUST also be present in all OPTIONS responses where the
content of the header will not include exactly the same methods as content of the header will not include exactly the same methods as
listed in the Public header. listed in the Public header.
The Allow SHALL also be included in SETUP and DESCRIBE responses, if The Allow SHALL also be included in SETUP and DESCRIBE responses, if
the methods allowed for the resource is different than the minimal the methods allowed for the resource is different than the minimal
implementation set. implementation set.
Example of use: Example of use:
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
14.7 Authorization 14.7. Authorization
See [H14.8] See [H14.8].
14.8 Bandwidth 14.8. Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in bits per second. The bandwidth available to the client may change in bits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to mobility, congestion, etc. during an RTSP session, e.g., due to mobility, congestion, etc.
Example: Example:
Bandwidth: 62360 Bandwidth: 62360
14.9 Blocksize 14.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, This packet size does not include lower-layer headers such as IP,
UDP, or RTP. The server is free to use a blocksize which is lower UDP, or RTP. The server is free to use a blocksize which is lower
than the one requested. The server MAY truncate this packet size to than the one requested. The server MAY truncate this packet size to
the closest multiple of the minimum, media-specific block size, or the closest multiple of the minimum, media-specific block size, or
override it with the media-specific size if necessary. The block size override it with the media-specific size if necessary. The block
MUST be a positive decimal number, measured in octets. The server size MUST be a positive decimal number, measured in octets. The
only returns an error (4xx) if the value is syntactically invalid. server only returns an error (4xx) if the value is syntactically
invalid.
14.10 Cache-Control 14.10. Cache-Control
The Cache-Control general-header field is used to specify directives The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the that MUST be obeyed by all caching mechanisms along the request/
request/response chain. response chain.
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does not govern the caching of response. Note: Cache-Control does em not govern the caching of
responses as for HTTP, instead it applies to the media stream responses as for HTTP, instead it applies to the media stream
identified by the SETUP request. The RTSP requests are generally not identified by the SETUP request. The RTSP requests are generally not
cacheable, for further information see section 16. Below is the cacheable, for further information see section Section 16. Below is
description of the cache directives that can be included in the the description of the cache directives that can be included in the
Cache-Control header. Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching anywhere. This allows an origin server to prevent caching even
even by caches that have been configured to return stale by caches that have been configured to return stale responses
responses to client requests. to client requests.
public: Indicates that the media stream is cacheable by any public: Indicates that the media stream is cacheable by any cache.
cache.
private: Indicates that the media stream is intended for a private: Indicates that the media stream is intended for a single
single user and MUST NOT be cached by a shared cache. A user and MUST NOT be cached by a shared cache. A private (non-
private (non-shared) cache may cache the media stream. shared) cache may cache the media streams.
no-transform: An intermediate cache (proxy) may find it useful no-transform: An intermediate cache (proxy) may find it useful to
to convert the media type of a certain stream. A proxy convert the media type of a certain stream. A proxy might, for
might, for example, convert between video formats to save example, convert between video formats to save cache space or
cache space or to reduce the amount of traffic on a slow to reduce the amount of traffic on a slow link. Serious
link. Serious operational problems may occur, however, operational problems may occur, however, when these
when these transformations have been applied to streams transformations have been applied to streams intended for
intended for certain kinds of applications. For example, certain kinds of applications. For example, applications for
applications for medical imaging, scientific data analysis medical imaging, scientific data analysis and those using end-
and those using end-to-end authentication all depend on to-end authentication all depend on receiving a stream that is
receiving a stream that is bit-for-bit identical to the bit-for-bit identical to the original media stream. Therefore,
original media stream. Therefore, if a response includes if a response includes the no-transform directive, an
the no-transform directive, an intermediate cache or proxy intermediate cache or proxy MUST NOT change the encoding of the
MUST NOT change the encoding of the stream. Unlike HTTP, stream. Unlike HTTP, RTSP does not provide for partial
RTSP does not provide for partial transformation at this transformation at this point, e.g., allowing translation into a
point, e.g., allowing translation into a different different language.
language.
only-if-cached: In some cases, such as times of extremely poor only-if-cached: In some cases, such as times of extremely poor
network connectivity, a client may want a cache to return network connectivity, a client may want a cache to return only
only those media streams that it currently has stored, and those media streams that it currently has stored, and not to
not to receive these from the origin server. To do this, receive these from the origin server. To do this, the client
the client may include the only-if-cached directive in a may include the only-if-cached directive in a request. If it
request. If it receives this directive, a cache SHOULD receives this directive, a cache SHOULD either respond using a
either respond using a cached media stream that is cached media stream that is consistent with the other
consistent with the other constraints of the request, or constraints of the request, or respond with a 504 (Gateway
respond with a 504 (Gateway Timeout) status. However, if a Timeout) status. However, if a group of caches is being
group of caches is being operated as a unified system with operated as a unified system with good internal connectivity,
good internal connectivity, such a request MAY be forwarded such a request MAY be forwarded within that group of caches.
within that group of caches.
max-stale: Indicates that the client is willing to accept a max-stale: Indicates that the client is willing to accept a media