draft-ietf-mmusic-rfc2326bis-18.txt   draft-ietf-mmusic-rfc2326bis-19.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Standards Track A. Rao Intended status: Standards Track A. Rao
Expires: November 6, 2008 Cisco Expires: May 7, 2009 Cisco
R. Lanphier R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
May 5, 2008 November 3, 2008
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-18.txt draft-ietf-mmusic-rfc2326bis-19
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 6, 2008. This Internet-Draft will expire on May 7, 2009.
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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 112 16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 112
16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 112 16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 112
16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 113 16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 113
16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 113 16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 113
16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 113 16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 113
16.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 113 16.29. Media-Properties . . . . . . . . . . . . . . . . . . . . 113
16.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 115 16.30. Media-Range . . . . . . . . . . . . . . . . . . . . . . 115
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 115 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 115
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 115 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 115
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 116 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 116
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 116 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 117
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 116 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 117
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 117 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 117
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 118
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 119 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 119
16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 120 16.39. Referer . . . . . . . . . . . . . . . . . . . . . . . . 120
16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 120 16.40. Retry-After . . . . . . . . . . . . . . . . . . . . . . 120
16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 120 16.41. Request-Status . . . . . . . . . . . . . . . . . . . . . 120
16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 121 16.42. Require . . . . . . . . . . . . . . . . . . . . . . . . 121
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 122 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 122
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 123 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 123
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 124 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 124
16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 125 16.46. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 125
16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 126 16.47. Server . . . . . . . . . . . . . . . . . . . . . . . . . 126
16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 126 16.48. Session . . . . . . . . . . . . . . . . . . . . . . . . 126
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 127 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 127
16.50. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 127 16.50. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 127
16.51. Transport . . . . . . . . . . . . . . . . . . . . . . . 127 16.51. Transport . . . . . . . . . . . . . . . . . . . . . . . 128
16.52. Unsupported . . . . . . . . . . . . . . . . . . . . . . 133 16.52. Unsupported . . . . . . . . . . . . . . . . . . . . . . 134
16.53. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 134 16.53. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 134
16.54. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 134 16.54. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 134 16.55. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 135
16.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 134 16.56. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 135
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 137
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 138 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 138 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 140
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 138 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 140
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 139 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 140
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 140 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 141
19.3.2. User approved TLS procedure . . . . . . . . . . . . 141 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 142
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 19.3.2. User approved TLS procedure . . . . . . . . . . . . 143
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 143 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 145 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 145
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 145 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 147
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 148 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 147
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 152 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 150
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 160 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 154
21. Security Considerations . . . . . . . . . . . . . . . . . . . 161 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 162
21.1. Remote denial of Service Attack . . . . . . . . . . . . 163 21. Security Considerations . . . . . . . . . . . . . . . . . . . 163
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 165 21.1. Remote denial of Service Attack . . . . . . . . . . . . 165
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 165 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 167
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 165 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 167
22.1.2. Registering New Feature-tags with IANA . . . . . . . 166 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 167
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 166 22.1.2. Registering New Feature-tags with IANA . . . . . . . 168
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 166 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 168
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 166 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 168
22.2.2. Registering New Methods with IANA . . . . . . . . . 166 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 168
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 167 22.2.2. Registering New Methods with IANA . . . . . . . . . 168
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 167 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 169
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 167 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 169
22.3.2. Registering New Status Codes with IANA . . . . . . . 167 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 169
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 167 22.3.2. Registering New Status Codes with IANA . . . . . . . 169
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 167 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 169
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 167 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 169
22.4.2. Registering New Headers with IANA . . . . . . . . . 168 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 169
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 168 22.4.2. Registering New Headers with IANA . . . . . . . . . 170
22.5. Transport Header Registries . . . . . . . . . . . . . . 169 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 170
22.5.1. Transport Protocol Specification . . . . . . . . . . 169 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 171
22.5.2. Transport modes . . . . . . . . . . . . . . . . . . 170 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 171
22.5.3. Transport Parameters . . . . . . . . . . . . . . . . 171 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 171
22.6. Cache Directive Extensions . . . . . . . . . . . . . . . 171 22.6. Cache-Control Cache Directive Extensions . . . . . . . 172
22.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 172 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 172
22.7.1. Accept-Credentials policies . . . . . . . . . . . . 172 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 173
22.7.2. Accept-Credentials hash algorithms . . . . . . . . . 172 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 173
22.8. Range header formats . . . . . . . . . . . . . . . . . . 173 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 173
22.9. Media Property Values . . . . . . . . . . . . . . . . . 173 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 173
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 173 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 173
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 173 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 173
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 174 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 174
22.10. Notify-Reason header . . . . . . . . . . . . . . . . . . 174 22.9. Range header formats . . . . . . . . . . . . . . . . . . 174
22.10.1. Description . . . . . . . . . . . . . . . . . . . . 174 22.10. RTP-Info header parameters . . . . . . . . . . . . . . . 174
22.10.2. Registration Rules . . . . . . . . . . . . . . . . . 174 22.10.1. Desctiption . . . . . . . . . . . . . . . . . . . . 174
22.10.3. Registered Values . . . . . . . . . . . . . . . . . 174 22.10.2. Registration Rules . . . . . . . . . . . . . . . . . 175
22.11. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 175 22.10.3. Registered Values . . . . . . . . . . . . . . . . . 175
22.11. Seek-Style Policies . . . . . . . . . . . . . . . . . . 175
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 175 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 175
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 175 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 175
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 175 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 176
22.12. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 175 22.12. Transport Header Registries . . . . . . . . . . . . . . 176
22.12.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 175 22.12.1. Transport Protocol Specification . . . . . . . . . . 176
22.12.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 176 22.12.2. Transport modes . . . . . . . . . . . . . . . . . . 177
22.12.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 177 22.12.3. Transport Parameters . . . . . . . . . . . . . . . . 178
22.13. SDP attributes . . . . . . . . . . . . . . . . . . . . . 178 22.13. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 178
22.14. Media Type Registration for text/parameters . . . . . . 179 22.13.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 178
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 181 22.13.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 179
23.1. Normative References . . . . . . . . . . . . . . . . . . 181 22.13.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 180
23.2. Informative References . . . . . . . . . . . . . . . . . 183 22.14. SDP attributes . . . . . . . . . . . . . . . . . . . . . 181
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 186 22.15. Media Type Registration for text/parameters . . . . . . 182
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 186 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 184
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 190 23.1. Normative References . . . . . . . . . . . . . . . . . . 184
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 192 23.2. Informative References . . . . . . . . . . . . . . . . . 186
A.4. Single Stream Container Files . . . . . . . . . . . . . 196 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 189
A.5. Live Media Presentation Using Multicast . . . . . . . . 198 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 189
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 199 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 193
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 201 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 195
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 201 A.4. Single Stream Container Files . . . . . . . . . . . . . 199
B.2. State variables . . . . . . . . . . . . . . . . . . . . 201 A.5. Live Media Presentation Using Multicast . . . . . . . . 201
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 201 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 202
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 202 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 204
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 207 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 204
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 207 B.2. State variables . . . . . . . . . . . . . . . . . . . . 204
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 207 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 204
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 207 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 205
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 208 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 210
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 209 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 210
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 209 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 210
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 209 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 210
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 210 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 211
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 210 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 212
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 210 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 212
C.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 214 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 212
C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 217 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 213
C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 219 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 213
C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 219 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 213
C.2.3. Handling Media Clock Time Jumps in the RTP Media
Layer . . . . . . . . . . . . . . . . . . . . . . . 217
C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 220
C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 223
C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 223
C.2.7. Maintaining NPT synchronization with RTP C.2.7. Maintaining NPT synchronization with RTP
timestamps . . . . . . . . . . . . . . . . . . . . . 219 timestamps . . . . . . . . . . . . . . . . . . . . . 223
C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 219 C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 223
C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 219 C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 223
C.2.10. Usage of SSRCs and the RTCP BYE Message During an C.2.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . 219 RTSP Session . . . . . . . . . . . . . . . . . . . . 223
C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 220 C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 224
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 221 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 225
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 221 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 225
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 221 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 225
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 222 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 226
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 223 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 227
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 223 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 227
D.1.5. Directionality of media stream . . . . . . . . . . . 223 D.1.5. Directionality of media stream . . . . . . . . . . . 227
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 224 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 228
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 225 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 229
D.1.8. Connection Information . . . . . . . . . . . . . . . 225 D.1.8. Connection Information . . . . . . . . . . . . . . . 229
D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 225 D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 229
D.2. Aggregate Control Not Available . . . . . . . . . . . . 226 D.2. Aggregate Control Not Available . . . . . . . . . . . . 230
D.3. Aggregate Control Available . . . . . . . . . . . . . . 226 D.3. Aggregate Control Available . . . . . . . . . . . . . . 230
D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 227 D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 231
Appendix E. Text format for Parameters . . . . . . . . . . . . . 229 Appendix E. Text format for Parameters . . . . . . . . . . . . . 233
Appendix F. Requirements for Unreliable Transport of RTSP . . . 230 Appendix F. Requirements for Unreliable Transport of RTSP . . . 234
Appendix G. Backwards Compatibility Considerations . . . . . . . 232 Appendix G. Backwards Compatibility Considerations . . . . . . . 236
G.1. Play Request in Play mode . . . . . . . . . . . . . . . 232 G.1. Play Request in Play mode . . . . . . . . . . . . . . . 236
G.2. Using Persistent Connections . . . . . . . . . . . . . . 232 G.2. Using Persistent Connections . . . . . . . . . . . . . . 236
Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 233 Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 237
Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 235 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 238
Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 242 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 245
J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 242 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 245
Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 244 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 247
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 245 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 248
Intellectual Property and Copyright Statements . . . . . . . . . 246 Intellectual Property and Copyright Statements . . . . . . . . . 249
1. Introduction 1. Introduction
1.1. Scope and Background 1.1. Scope and Background
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0) which is an application-level protocol for control over (RTSP 2.0) which is an application-level protocol for control over
the delivery of data with real-time properties, typically streaming the delivery of data with real-time properties, typically streaming
media. Streaming media is, for instance, video on demand or audio media. Streaming media is, for instance, video on demand or audio
live streaming. Put simply, RTSP acts as a "network remote control" live streaming. Put simply, RTSP acts as a "network remote control"
for multimedia servers, as you know it from your TV set. for multimedia servers, as you know it from your TV set.
The protocol operates between RTSP 2.0 clients and servers, but also The protocol operates between RTSP 2.0 clients and servers, but also
supports the usage of RTSP 2.0 proxies between clients and servers. supports the usage of RTSP 2.0 proxies between clients and servers.
Basically, clients can request information about streaming media from Basically, clients can request information about streaming media from
servers, by asking for a description of the media or use media setranrvers, by asking for a description of the media or use media
description provided externally. Based on the media description description provided externally. Based on the media description
clients can request to play out the media, pause it, or stop it clients can request to play out the media, pause it, or stop it
completely, as known from a regular TV remote control. The requested completely, as known from a regular TV remote control. The requested
media can consist of multiple audio and video streams that are media can consist of multiple audio and video streams that are
delivered as a time-synchronized streams from servers to clients. delivered as a time-synchronized streams from servers to clients.
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. For security, TLS over based transport level protocol, such as TCP. For security, TLS over
a connection oriented transport is supported. a connection oriented transport is supported.
skipping to change at page 16, line 12 skipping to change at page 16, line 5
policies are envisioned and taken into consideration where policies are envisioned and taken into consideration where
applicable. applicable.
Unlimited: The media will not be removed as long as the RTSP session Unlimited: The media will not be removed as long as the RTSP session
are in existence. are in existence.
Time Limited: The media will at least not be removed before given Time Limited: The media will at least not be removed before given
wall clock time. After that time it may or may not be available wall clock time. After that time it may or may not be available
any more. any more.
Duration limited Each indiviudal unit of the media will be retained Duration limited: Each indiviudal unit of the media will be retained
for the specified duration. for the specified duration.
1.5.3. Content Modifications 1.5.3. Content Modifications
There is also the question of how the content may change during time There is also the question of how the content may change during time
for a give media resource: for a give media resource:
Unmutable: The content of the media will not change, even if the Unmutable: The content of the media will not change, even if the
representation, i.e encoding, quality, etc, may change. representation, i.e encoding, quality, etc, may change.
skipping to change at page 17, line 14 skipping to change at page 17, line 14
2. RTSP Introduction 2. RTSP Introduction
2.1. Protocol Properties 2.1. Protocol Properties
RTSP has the following properties: RTSP has the following properties:
Extendable: New methods and parameters can be easily added to RTSP. Extendable: New methods and parameters can be easily added to RTSP.
Secure: RTSP re-uses web security mechanisms, either at the Secure: RTSP re-uses web security mechanisms, either at the
transport level (TLS, [RFC4346]) or within the protocol itself. transport level (TLS, [RFC5246]) or within the protocol itself.
All HTTP authentication mechanisms such as basic ([RFC2616]) and All HTTP authentication mechanisms such as basic ([RFC2616]) and
digest authentication ([RFC2617]) are directly applicable. digest authentication ([RFC2617]) are directly applicable.
Transport-independent: RTSP does not preclude the use of unreliable Transport-independent: RTSP does not preclude the use of unreliable
datagram protocol (UDP) ([RFC0768]) as it would be possible to datagram protocol (UDP) ([RFC0768]) as it would be possible to
implement application-level reliability. The use of a implement application-level reliability. The use of a
connectionless datagram protocol such as UDP requires additional connectionless datagram protocol such as UDP requires additional
definition that may be provided as extensions to the core RTSP definition that may be provided as extensions to the core RTSP
specification. The reliable stream protocol TCP ([RFC0793]) and specification. The reliable stream protocol TCP ([RFC0793]) and
the secured reliable stream protocol TLS over TCP [RFC4346] are the secured reliable stream protocol TLS over TCP [RFC5246] are
the currently defined transport protocols for RTSP messages. the currently defined transport protocols for RTSP messages.
Media-delivery protocol independent: The operation of RTSP does not Media-delivery protocol independent: The operation of RTSP does not
depend on the transport mechanism used to carry continuous media. depend on the transport mechanism used to carry continuous media.
While most real-time media will use RTP as a transport protocol, While most real-time media will use RTP as a transport protocol,
RTSP does not preclude the use of other protocols such as MPEG-2 RTSP does not preclude the use of other protocols such as MPEG-2
[ISO.13818-1.2000]. The use of other protocols requires [ISO.13818-1.2000]. The use of other protocols requires
additional definition that may be provided as extensions to the additional definition that may be provided as extensions to the
core RTSP specification. core RTSP specification.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
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 request Unicast: The media is transmitted to the source of the RTSP request
or the requested destination, with the port number chosen by the or the requested destination, with the port number chosen by the
client. Alternatively, the media is transmitted on the same client. Alternatively, the media is 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 live multicast address and port. This is the typical case for a live
or near-media-on-demand transmission. or near-media-on-demand transmission. The address is provided by
the session description.
Multicast, client chooses address: If the server is to participate Multicast, client chooses address: If the server is to participate
in an existing multicast conference, the multicast address, port in an existing multicast conference, the multicast address, port
and encryption key are given by the conference description, and encryption key are given by the conference description,
established by means outside the scope of this specification, for established by means outside the scope of this specification, for
example by a SIP created conference. example by a SIP created conference.
2.5. RTSP States 2.5. 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,
skipping to change at page 29, line 8 skipping to change at page 29, line 8
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
[RFC4346], see (Section 19). [RFC5246], see (Section 19).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 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
[RFC3986]. URIs may refer to a stream or an aggregate of streams; [RFC3986]. URIs may refer to a stream or an aggregate of streams;
i.e., a presentation. Accordingly, requests described in i.e., a presentation. Accordingly, requests described in
(Section 13) can apply to either the whole presentation or an (Section 13) can apply to either the whole presentation or an
skipping to change at page 34, line 9 skipping to change at page 34, line 9
In the interest of robustness, servers SHOULD ignore any empty In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other words, line(s) received where a Request-Line is expected. In other words,
if the server is reading the protocol stream at the beginning of a if the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF. message and receives a CRLF first, it should ignore the CRLF.
5.2. Message Headers 5.2. Message Headers
See [H4.2]. See [H4.2].
Unknown message headers SHALL be ignored by a RTSP server or client.
An RTSP Proxy SHALL forward unknown message headers. Message headers
defined outside of this specification that are required to be
interpret by the RTSP agent will need to use feature tags
(Section 4.7) and include it in the appropriate Require
(Section 16.42) or Proxy-Require (Section 16.35) header.
5.3. Message Body 5.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 16.16). field (see Section 16.16).
5.4. Message Length 5.4. Message Length
skipping to change at page 57, line 14 skipping to change at page 57, line 14
Note on Table 7: GET_PARAMETER is recommended, but not required. Note on Table 7: GET_PARAMETER is recommended, but not required.
For example, a fully functional server can be built to deliver For example, a fully functional server can be built to deliver
media without any parameters. SET_PARAMETER is required however media without any parameters. SET_PARAMETER is required however
due to its usage for keep-alive. PAUSE is now required due to due to its usage for keep-alive. PAUSE is now required due to
that it is the only way of getting out of the state machines play that it is the only way of getting out of the state machines play
state 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.
An RTSP proxy whos main function is to log or audit and not modify
transport or media handling in any way MAY forward RTSP messages with
unknown methods. Note, the proxy stil needs to perform the minimal
required processing, like adding the Via header.
13.1. OPTIONS 13.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.
skipping to change at page 59, line 14 skipping to change at page 59, line 14
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312 CSeq: 312
User-Agent: PhonyClient 1.2 User-Agent: PhonyClient 1.2
Accept: application/sdp, application/example Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 312 CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 367 Content-Length: 358
v=0 v=0
o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46 o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar s=SDP Seminar
i=A Seminar on the session description protocol i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management) e=seminar@example.com (Seminar Management)
c=IN IP4 224.2.17.12/127 c=IN IP4 0.0.0.0
t=2873397496 2873404696
a=recvonly a=recvonly
a=control:*
t=2873397496 2873404696
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
a=control:audio
m=video 2232 RTP/AVP 31 m=video 2232 RTP/AVP 31
m=application 32416 UDP WB a=control:video
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 information for the resource(s) that it describes. Servers SHOULD
NOT use the DESCRIBE response as a means of media indirection by NOT use the DESCRIBE response as a means of media indirection by
having 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 initialization By forcing a DESCRIBE response to contain all media initialization
for the set of streams that it describes, and discouraging the use for the set of streams that it describes, and discouraging the use
of DESCRIBE for media indirection, any looping problems can be of DESCRIBE for media indirection, any looping problems can be
skipping to change at page 61, line 16 skipping to change at page 61, line 18
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 16.5) to indicate which time formats that are acceptable (see Section 16.5) to indicate which time formats that are acceptable
to use for this media resource. to use for this media resource.
The SETUP response 200 OK SHALL include the Media-Properties header The SETUP response 200 OK SHALL include the Media-Properties header
(see Section 16.29 ). The combination of the parameters of the (see Section 16.29 ). The combination of the parameters of the
Media-Properties header indicate the nature of the content (see also Media-Properties header indicate the nature of the content present in
Section 1.5). For example, a live stream with time shifting is the session (see also Section 1.5). For example, a live stream with
indicated by time shifting is indicated by
o Random Access set to Random-Access, o Random Access set to Random-Access,
o Content Modifications set to Time Progressing, o Content Modifications set to Time Progressing,
o Retention set to Time-Duration (with specific recording window o Retention set to Time-Duration (with specific recording window
time value). time value).
The SETUP response 200 OK SHALL include the Media-Range header (see The SETUP response 200 OK SHALL include the Media-Range header (see
Section 16.30) if the media is Time-Progressing. Section 16.30) if the media is Time-Progressing.
skipping to change at page 61, line 44 skipping to change at page 61, line 46
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589", Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 302 CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.1 Server: PhonyServer 1.1
Session: 47112344;timeout=60 Session: 47112344;timeout=60
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589"; Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
src_addr="192.0.2.241:6256"/"192.0.2.241:6257"; "192.0.2.53:4589"; src_addr="192.0.2.241:6256"/
ssrc=2A3F93ED "192.0.2.241:6257"; ssrc=2A3F93ED
Accept-Ranges: NPT Accept-Ranges: NPT
Media-Properties: Random-Access=3.2, Time-Progressing, Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0 Time-Duration=3600.0
Media-Range: npt=0-2893.23 Media-Range: npt=0-2893.23
In the above example the client wants to create an RTSP session In the above example the client wants to create an RTSP session
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 RTP/AVP/ The transport parameters acceptable to the client is either RTP/AVP/
UDP (UDP per default) to be received on client port 4588 and 4589 or UDP (UDP per default) to be received on client port 4588 and 4589 or
RTP/AVP interleaved on the RTSP control channel. The server selects RTP/AVP interleaved on the RTSP control channel. The server 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
skipping to change at page 65, line 32 skipping to change at page 65, line 32
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 format used in contained. If no Range header was in the request, the format used in
any previous PLAY request within the session SHOULD be used. If no any previous PLAY request within the session SHOULD be used. If no
format has been indicated in a previous request the server MAY use format has been indicated in a previous request the server MAY use
any time format supported by the media and indicated in the Accept- any time format supported by the media and indicated in the Accept-
Ranges header in the SETUP respone. It is RECOMMENDED that NPT is Ranges header in the SETUP respone. It is RECOMMENDED that NPT is
used if supported by the media. used if supported by the media.
For any error response to a PLAY request, the server's response
depends on the current session state. If the session is in ready
state, the current pause-point is returned. For time-progressing
content where the pause-point moves with real-time due to limited
retention, the current resume point is returned. For sessions in
playing state, the current playout point and the remaining parts of
the range request is returned.
A PLAY response MAY include a header(s) carrying synchronization A PLAY response MAY include a header(s) carrying synchronization
information. As the information necessary is dependent on the media information. As the information necessary is dependent on the media
transport format, further rules specifying the header and its usage transport format, further rules specifying the header and its usage
is needed. For RTP the RTP-Info header is specified, see is needed. For RTP the RTP-Info header is specified, see
Section 16.43, and used in the following example. Section 16.43, and used in the following example.
Here is a simple example for a single audio stream where the client Here is a simple example for a single audio stream where the client
requests the media starting from 3.52 seconds. The server sends a requests the media starting from 3.52 seconds and to the end. The
200 OK response with the actual play time (equal to the requested in server sends a 200 OK response with the actual play time (equal to
this case) and the RTP-Info header that contains the necessary the requested in this case) and the RTP-Info header that contains the
parameters for the RTP stack. necessary parameters for the RTP stack.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=3.52- Range: npt=3.52-
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 836 CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-324.39
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
For media with random-access, the server MUST reply with the actual For media with random-acces properties, the server MUST reply with
range that will be played back, i.e. for which duration any media the actual range that will be played back, i.e. for which duration
(having content at this time) is delivered. This may differ from the any media (having content at this time) is delivered. This may
requested range if alignment of the requested range to valid frame differ from the requested range if alignment of the requested range
boundaries is required for the media source. Note that some media to valid frame boundaries is required for the media source. Note
streams in an aggregate may need to be delivered from even earlier that some media streams in an aggregate may need to be delivered from
points. Also, some media format have a very long duration per even earlier points. Also, some media format have a very long
individual data unit, therefore it might be necessary for the client duration per individual data unit, therefore it might be necessary
to parse the data unit, and select where to start. The client can for the client to parse the data unit, and select where to start.
express its desired handling by the server by including the Seek- The client can express its desired handling by the server by
Style header (Section 16.45) in the PLAY request, if desired. including the Seek-Style header (Section 16.45) in the PLAY request,
if desired.
In the following example the client receives the first media packet In the following example the client receives the first media packet
that stretches all the way up and past the requested playtime. Thus, that stretches all the way up and past the requested playtime. Thus,
it is the client's decision if to render to the user the time between it is the client's decision if to render to the user the time between
3.52 and 7.05, or to skip it. In most cases it is probably most 3.52 and 7.05, or to skip it. In most cases it is probably most
suitable to not render that time period. suitable to not render that time period.
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
skipping to change at page 102, line 32 skipping to change at page 102, line 32
| Proxy-Require | r | r | c | c | c | - | | Proxy-Require | r | r | c | c | c | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | R | amr | c | c | c | - | | Proxy-Supported | R | amr | c | c | c | - |
| | | | | | | | | | | | | | | |
| Proxy-Supported | r | | c | c | c | - | | Proxy-Supported | r | | c | c | c | - |
| | | | | | | | | | | | | | | |
| Public | 501 | admr | m | m | m | - | | Public | 501 | admr | m | m | m | - |
+------------------------+---------+-------+-----+-----+-----+-----+ +------------------------+---------+-------+-----+-----+-----+-----+
Table 11: Overview of RTSP header fields (A-P) related to methods Table 11: Overview of RTSP header fields (A-P) related to methods
GETPARAMETER, SETPARAMETER, PLAY_NOTIFY, and REDIRECT. GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT.
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY | | Header | Where | Proxy | GPR | SPR | RDR | PNY |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
| Range | R | | - | - | o | m | | Range | R | | - | - | o | m |
| | | | | | | | | | | | | | | |
| Referer | R | | o | o | o | - | | Referer | R | | o | o | o | - |
| | | | | | | | | | | | | | | |
| Request-Status | R | | - | - | - | m | | Request-Status | R | | - | - | - | m |
| | | | | | | | | | | | | | | |
skipping to change at page 103, line 34 skipping to change at page 103, line 34
| Vary | r | | c | c | - | - | | Vary | r | | c | c | - | - |
| | | | | | | | | | | | | | | |
| Via | R | amr | o | o | o | - | | Via | R | amr | o | o | o | - |
| | | | | | | | | | | | | | | |
| Via | c | dr | m | m | m | - | | Via | c | dr | m | m | m | - |
| | | | | | | | | | | | | | | |
| WWW-Authenticate | 401 | | m | m | m | - | | WWW-Authenticate | 401 | | m | m | m | - |
+------------------+---------+-------+-----+-----+-----+-----+ +------------------+---------+-------+-----+-----+-----+-----+
Table 12: Overview of RTSP header fields (R-W) related to methods Table 12: Overview of RTSP header fields (R-W) related to methods
GETPARAMETER, SETPARAMETER, PLAY_NOTIFY, and REDIRECT. GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT.
16.1. Accept 16.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
16.2. Accept-Credentials 16.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 19 for the usage of this header. It proxies or servers. See Section 19 for the usage of this header. It
SHALL NOT be included in server to client requests. 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, unless it is "proxy" when a proxy SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy
MAY change it to "user" to take the role of user approving each MAY change it to "user" to take the role of user approving each
further hop. If the method is "User" the header contains zero or further hop. If the method is "User" the header contains zero or
more of credentials that the client accepts. The header may contain more of credentials that the client accepts. The header may contain
zero credentials in the first RTSP request to a RTSP server when zero credentials in the first RTSP request to a RTSP server when
using the "User" method. This as the client has not yet received any using the "User" method. This as the client has not yet received any
credentials to accept. Each credential SHALL consist of one URI credentials to accept. Each credential SHALL consist of one URI
identifying the proxy or server, the hash algorithm identifier, and identifying the proxy or server, the hash algorithm identifier, and
the hash over that entity's DER encoded certificate [RFC3280] in the hash over that entity's DER encoded certificate [RFC5280] in
Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the
SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the
DER encoded certificate. The SHA-256 algorithm is identified by the DER encoded certificate. The SHA-256 algorithm is identified by the
token "sha-256". token "sha-256".
The intention with allowing for other hash algorithms is to enable The intention with allowing for other hash algorithms is to enable
the future retirement of algorithms that are not implemented the future retirement of algorithms that are not implemented
somewhere else than here. Thus the definition of future algorithms somewhere else than here. Thus the definition of future algorithms
for this purpose is intended to be extremely limited. A feature tag for this purpose is intended to be extremely limited. A feature tag
can be used to ensure that support for the replacement algorithm can be used to ensure that support for the replacement algorithm
skipping to change at page 108, line 46 skipping to change at page 108, line 46
The Connection-Credentials response header is used to carry the chain The Connection-Credentials response header is used to carry the chain
of credentials of any next hop that need to be approved by the of credentials of any next hop that need to be approved by the
requestor. It SHALL only be used in server to client responses. requestor. It SHALL only be used in server to client responses.
The Connection-Credentials header in an RTSP response SHALL, if The Connection-Credentials header in an RTSP response SHALL, if
included, contain the credential information (in form of a list of included, contain the credential information (in form of a list of
certificates providing the chain of certification) of the next hop certificates providing the chain of certification) of the next hop
that an intermediary needs to securely connect to. The header MUST that an intermediary needs to securely connect to. The header MUST
include the URI of the next hop (proxy or server) and a base64 include the URI of the next hop (proxy or server) and a base64
[RFC4648] encoded binary structure containg a sequence of DER encoded [RFC4648] encoded binary structure containg a sequence of DER encoded
X.509v3 certificates[RFC3280] . X.509v3 certificates[RFC5280] .
The binary structure starts with the number of certificates The binary structure starts with the number of certificates
(NR_CERTS) included as a 16 bit unsigned integer. This is followed (NR_CERTS) included as a 16 bit unsigned integer. This is followed
by NR_CERTS number of 16 bit unsigned integers providing the size in by NR_CERTS number of 16 bit unsigned integers providing the size in
octets of each DER encoded certificate. This is followed by NR_CERTS octets of each DER encoded certificate. This is followed by NR_CERTS
number of DER encoded X.509v3 certificates in a sequence (chain). number of DER encoded X.509v3 certificates in a sequence (chain).
The proxy or server's certificate must come first in the structure. The proxy or server's certificate must come first in the structure.
Each following certificate must directly certify the one preceding Each following certificate must directly certify the one preceding
it. Because certificate validation requires that root keys be it. Because certificate validation requires that root keys be
skipping to change at page 112, line 20 skipping to change at page 112, line 20
especially including the value "0", as having occurred in the past especially including the value "0", as having occurred in the past
(i.e., already expired). (i.e., already expired).
To mark a response as "already expired," an origin server should use To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. To mark a an Expires date that is equal to the Date header value. To mark a
response as "never expires," an origin server SHOULD use an Expires response as "never expires," an origin server SHOULD use an Expires
date approximately one year from the time the response is sent. date approximately one year from the time the response is sent.
RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
The presence of an Expires header field with a date value of some
time in the future on a media stream that otherwise would by default
be non-cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field (Section 16.10).
16.23. From 16.23. From
See [H14.22]. See [H14.22].
16.24. If-Match 16.24. If-Match
See [H14.24]. See [H14.24].
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, in both the case where the integrity of the presentation description, in both the case where
skipping to change at page 113, line 37 skipping to change at page 113, line 33
DESCRIBE, the header field indicates the last modification date and DESCRIBE, the header field indicates the last modification date and
time of the description, for SETUP that of the media stream. time of the description, for SETUP that of the media stream.
16.28. Location 16.28. Location
See [H14.30]. See [H14.30].
16.29. Media-Properties 16.29. Media-Properties
This general header is used in SETUP response or PLAY_NOTIFY requests This general header is used in SETUP response or PLAY_NOTIFY requests
to indicate the media's properties that currently are applicable. to indicate the media's properties that currently are applicable to
PLAY_NOTIFY MAY be used to modify these properties at any point. the RTSP session. PLAY_NOTIFY MAY be used to modify these properties
However, the client MUST have received the update prior to any action at any point. However, the client MUST have received the update
related to the new media properties take affect. prior to any action related to the new media properties take affect.
For aggregated sessions the Media-Properties header will be returned
in each SETUP response and the one that applies is the response to
the last request.
The media properties expressed by this header is the one applicable
to all media in the RTSP session. So for aggregated sessions the
header expressed the combined media-properties. As a result
aggregation of media MAY result in a change of the media properties,
and thus the content of the Media-Properties header contained in
subsequent SETUP responses.
The header contains a list of property values that are applicable to The header contains a list of property values that are applicable to
the currently setup media or aggregate of media as indicated by the the currently setup media or aggregate of media as indicated by the
RTSP URI in the request. No ordering are enforced within the header. RTSP URI in the request. No ordering are enforced within the header.
Property values should be grouped into a single group that handles a Property values should be grouped into a single group that handles a
particular orthogonal property. Values or groups that express particular orthogonal property. Values or groups that express
multiple properties SHOULD NOT be used. The list of properties that multiple properties SHOULD NOT be used. The list of properties that
can be expressed MAY be extended at any time. Unknown property can be expressed MAY be extended at any time. Unknown property
values SHALL be ignored. values SHALL be ignored.
skipping to change at page 115, line 35 skipping to change at page 115, line 41
was issued. As wall clock progresses so will also the media range. was issued. As wall clock progresses so will also the media range.
However it shall be assumed that media time progress in direct However it shall be assumed that media time progress in direct
relationship to wall clock time (with the exception of clock skew) so relationship to wall clock time (with the exception of clock skew) so
that a reasoanbly accurate estiamation of the media range can be that a reasoanbly accurate estiamation of the media range can be
calculated. calculated.
16.31. Notify-Reason 16.31. Notify-Reason
The Notify Reason header is solely used in the PLAY_NOTIFY method. The Notify Reason header is solely used in the PLAY_NOTIFY method.
It indiciates the reason why the server has sent the asynchronous It indiciates the reason why the server has sent the asynchronous
PLAY-NOTIFY request (see Section 13.5). PLAY_NOTIFY request (see Section 13.5).
16.32. Pipelined-Requests 16.32. Pipelined-Requests
The Pipelined-Requests general header is used to indicate that a The Pipelined-Requests general header is used to indicate that a
request is to be executed in the context created by previous request is to be executed in the context created by previous
requests. The primary usage of this header is to allow pipelining of requests. The primary usage of this header is to allow pipelining of
SETUP requests so that any additional SETUP request after the first SETUP requests so that any additional SETUP request after the first
one doesn't need to wait for the session ID to be sent back to the one doesn't need to wait for the session ID to be sent back to the
requesting entity. The header contains a unique identifier that is requesting entity. The header contains a unique identifier that is
scoped by the persistent connection used to send the requests. scoped by the persistent connection used to send the requests.
skipping to change at page 117, line 12 skipping to change at page 117, line 22
sensitive features that MUST be supported by the proxy. Any Proxy- sensitive features that MUST be supported by the proxy. Any Proxy-
Require header features that are not supported by the proxy MUST be Require header features that are not supported by the proxy MUST be
negatively acknowledged by the proxy to the client using the negatively acknowledged by the proxy to the client using the
Unsupported header. The proxy SHALL use the 551 (Option Not Unsupported header. The proxy SHALL use the 551 (Option Not
Supported) status code in the response. Any feature-tag included in Supported) status code in the response. Any feature-tag included in
the Proxy-Require does not apply to the end-point (server or client). the Proxy-Require does not apply to the end-point (server or client).
To ensure that a feature is supported by both proxies and servers the To ensure that a feature is supported by both proxies and servers the
tag needs to be included in also a Require header. tag needs to be included in also a Require header.
See Section 16.42 for more details on the mechanics of this message See Section 16.42 for more details on the mechanics of this message
and a usage example. and a usage example. See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy
support.
Example of use: Example of use:
Proxy-Require: play.basic Proxy-Require: play.basic
16.36. Proxy-Supported 16.36. Proxy-Supported
The Proxy-Supported header field enumerates all the extensions The Proxy-Supported header field enumerates all the extensions
supported by the proxy using feature-tags. The header carries the supported by the proxy using feature-tags. The header carries the
intersection of extensions supported by the forwarding proxies. The intersection of extensions supported by the forwarding proxies. The
Proxy-Supported header MAY be included in any request by a proxy. It Proxy-Supported header MAY be included in any request by a proxy. It
skipping to change at page 121, line 17 skipping to change at page 121, line 17
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however the use of the other end-point supports certain features, however the use of the
Supported (Section 16.49) is much more effective in this purpose. Supported (Section 16.49) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response SHALL use the error code 551 (Option Not supported. The response SHALL use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see Proxy-Require header functionality in respect to proxies see Proxy-Require header
(Section 16.35). (Section 16.35) with the exception of media modifying proxies. Media
modifying proxies due to their nature of handling media in a way that
is very similar to what a server, do need to understand also the
server features to correctly serve the client.
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does ambiguity when the client requires features that the server does
not understand. not understand.
skipping to change at page 121, line 48 skipping to change at page 121, line 51
In this example, "funky-feature" is the feature-tag which indicates In this example, "funky-feature" is the feature-tag which indicates
to the client that the fictional Funky-Parameter field is required. to the client that the fictional Funky-Parameter field is required.
The relationship between "funky-feature" and Funky-Parameter is not The relationship between "funky-feature" and Funky-Parameter is not
communicated via the RTSP exchange, since that relationship is an communicated via the RTSP exchange, since that relationship is an
immutable property of "funky-feature" and thus should not be immutable property of "funky-feature" and thus should not be
transmitted with every exchange. transmitted with every exchange.
Proxies and other intermediary devices SHALL ignore this header. If Proxies and other intermediary devices SHALL ignore this header. If
a particular extension requires that intermediate devices support it, a particular extension requires that intermediate devices support it,
the extension should be tagged in the Proxy-Require field instead the extension should be tagged in the Proxy-Require field instead
(see Section 16.35). (see Section 16.35). See discussion in the proxies section
(Section 17.1) about when to consider that a feature requires proxy
support.
16.43. RTP-Info 16.43. RTP-Info
The RTP-Info response-header field is used to set RTP-specific The RTP-Info response-header field is used to set RTP-specific
parameters in the PLAY response. For streams using RTP as transport parameters in the PLAY response. For streams using RTP as transport
protocol the RTP-Info header SHOULD be part of a 200 response to protocol the RTP-Info header SHOULD be part of a 200 response to
PLAY. PLAY.
The exclusion of the RTP-Info in a PLAY response for RTP The exclusion of the RTP-Info in a PLAY response for RTP
transported media will result in that a client needs to transported media will result in that a client needs to
skipping to change at page 124, line 9 skipping to change at page 124, line 11
twice the normal viewing rate ("fast forward") and a ratio of 0.5 twice the normal viewing rate ("fast forward") and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 indicates half the normal viewing rate. In other words, a ratio of 2
has normal play time increase at twice the wallclock rate. For every has normal play time increase at twice the wallclock rate. For every
second of elapsed (wallclock) time, 2 seconds of content will be second of elapsed (wallclock) time, 2 seconds of content will be
delivered. A negative value indicates reverse direction. For delivered. A negative value indicates reverse direction. For
certain media transports this may require certain considerations to certain media transports this may require certain considerations to
work consistent, see Appendix C.1 for description on how RTP handles work consistent, see Appendix C.1 for description on how RTP handles
this. this.
Unless requested otherwise by the Speed parameter, the data rate Unless requested otherwise by the Speed parameter, the data rate
SHOULD not be changed. Implementation of scale changes depends on SHOULD NOT be changed. Implementation of scale changes depends on
the server and media type. For video, a server may, for example, the server and media type. For video, a server may, for example,
deliver only key frames or selected key frames. For audio, for deliver only key frames or selected key frames. For audio, for
example, it may time-scale the audio while preserving pitch or, less example, it may time-scale the audio while preserving pitch or, less
desirably, deliver fragments of audio. desirably, deliver fragments of audio.
The server should try to approximate the viewing rate, but may The server should try to approximate the viewing rate, but may
restrict the range of scale values that it supports. The response restrict the range of scale values that it supports. The response
MUST contain the actual scale value chosen by the server. MUST contain the actual scale value chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
skipping to change at page 128, line 8 skipping to change at page 128, line 13
resolves retransmission ambiguities for unreliable transport of RTSP. resolves retransmission ambiguities for unreliable transport of RTSP.
16.51. Transport 16.51. Transport
The Transport request and response header field indicates which The Transport request and response header field indicates which
transport protocol is to be used and configures its parameters such transport protocol is to be used and configures its parameters such
as destination address, compression, multicast time-to-live and as destination address, compression, multicast time-to-live and
destination port for a single stream. It sets those values not destination port for a single stream. It sets those values not
already determined by a presentation description. already determined by a presentation description.
Transports are comma separated, listed in order of preference.
Parameters may be added to each transport, separated by a semicolon.
The server SHOULD return a Transport response-header field in the
response to indicate the values actually chosen. The Transport
header field MAY also be used to change certain transport parameters.
A server MAY refuse to change parameters of an existing stream.
A Transport request header field MAY contain a list of transport A Transport request header field MAY contain a list of transport
options acceptable to the client, in the form of multiple transport- options acceptable to the client, in the form of multiple transport
spec entries. In that case, the server MUST return the single specification entries. Transport specifications are comma separated,
(transport-spec) which was actually chosen. The number of transport- listed in decreasing order of preference. Parameters may be added to
spec entries is expected to be limited as the client will get each transport specififcation, separated by a semicolon. The server
guidance on what configurations that are possible from the MUST return a Transport response-header field in the response to
indicate the values actually chosen if any. If not transport
specification is supported no transport header is returned and the
request SHALL be responded using the status code 461 (Unsupported
Transport) (Section 15.4.13). In case more than one transport
specification was present in the request, the server MUST return the
single (transport-spec) which was actually chosen if any. The number
of transport-spec entries is expected to be limited as the client
will get guidance on what configurations that are possible from the
presentation description. presentation description.
A transport-spec transport option may only contain one of any given The Transport header field MAY also be used in subsequent SETUP
parameter within it. Parameters MAY be given in any order. requests to change transport parameters. A server MAY refuse to
Additionally, it may only contain the unicast or the multicast change parameters of an existing stream.
transport type parameter. Unknown parameters SHALL be ignored. The
requester need to ensure that the responder understands the
parameters through the use of feature tags and the Require header.
Any parameters part of future extensions requires clarification if A transport specification may only contain one of any given parameter
they are safe to ignore in accordance to this specification, or are within it. Parameters MAY be given in any order. Additionally, it
required to be understood. If a parameter is required to be may only contain either of the unicast or the multicast transport
understood, then a feature-tag MUST be defined for the functionality type parameter. All parameters needs to be understood in a transport
and used in the Require or Proxy-Require headers. specification, if not the transport specification SHALL be ignored.
RTSP proxies of any type that uses or modifies the transport
specification, e.g. acces proxy or security proxy, SHALL remove
specifications with unknown parameters before forwarding the RTSP
message. If that result in no remaing transport specification the
proxy shall send a 461 (Unsupported Transport) (Section 15.4.13)
response without any Transport header.
The Transport header field is restricted to describing a single The Transport header field is restricted to describing a single
media stream. (RTSP can also control multiple streams as a single media stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a entity.) Making it part of RTSP rather than relying on a
multitude of session description formats greatly simplifies multitude of session description formats greatly simplifies
designs of firewalls. designs of firewalls.
The general syntax for the transport specifier is a list of slash The general syntax for the transport specifier is a list of slash
separated tokens: separated tokens:
Value1/Value2/Value3... Value1/Value2/Value3...
Which for RTP transports take the form: Which for RTP transports take the form:
RTP/profile/lower-transport. RTP/profile/lower-transport.
The default value for the "lower-transport" parameters is specific to The default value for the "lower-transport" parameters is specific to
the profile. For RTP/AVP, the default is UDP. the profile. For RTP/AVP, the default is UDP.
There are two different methods for how to specify where the media There are two different methods for how to specify where the media
should be delivered: should be delivered for unicast transport:
dest_addr: The presence of this parameter and its values indicates dest_addr: The presence of this parameter and its values indicates
the destination address or addresses (host address and port the destination address or addresses (host address and port
pairs for IP flows) necessary for the media transport. pairs for IP flows) necessary for the media transport.
No dest_addr: The lack of the dest_addr parameter indicates that the No dest_addr: The lack of the dest_addr parameter indicates that the
server SHALL send media to same address for which the RTSP server SHALL send media to same address for which the RTSP
messages originates. Does not work for transports requiring messages originates. Does not work for transports requiring
explicitly given destination ports. explicitly given destination ports.
The choice of method for indicating where the media is to be The choice of method for indicating where the media is to be
delivered depends on the use case. In many case the only allowed delivered depends on the use case. In some case the only allowed
method will be to use no explicit address indication and have the method will be to use no explicit address indication and have the
server deliver media to the source of the RTSP messages. server deliver media to the source of the RTSP messages.
For Multicast there is several methods for specifying addresses but
they are different in how they work compared with unicast:
dest_addr with client picked address: The address and relevant
parameters like TTL (scope) for the actual multicast group to
deliver the media to. There are security implications
(Section 21) with this method that needs to be addressed if
using this method because a RTSP server can be used as a DoS
attacker on a existing multicast group.
dest_addr using Session Decription Information: The information
included in the transport header can all be comming from the
session description, e.g. the SDP c= and m= line. This
mitigates some of the security issues of the previous methods
as it is the session provider that picks the multicast group
and scope. The client SHALL include the information if it is
available in the session description.
No dest_addr: The lack of an explicit multicast group request the
server to decide the group address and its scope. For this to
work the server needs to have a context about what scope that
works. This method is currently under specified.
An RTSP proxy will need to take care. If the media is not desired to An RTSP proxy will need to take care. If the media is not desired to
be routed through the proxy, the proxy will need to introduce the be routed through the proxy, the proxy will need to introduce the
destination indication. destination indication.
Below are the configuration parameters associated with transport: Below are the configuration parameters associated with transport:
General parameters: General parameters:
unicast / multicast: This parameter is a mutually exclusive unicast / multicast: This parameter is a mutually exclusive
indication of whether unicast or multicast delivery will be indication of whether unicast or multicast delivery will be
skipping to change at page 130, line 18 skipping to change at page 130, line 49
server MUST perform security checks (see Section 21.1) and server MUST perform security checks (see Section 21.1) and
SHOULD log such attempts before allowing the client to direct a SHOULD log such attempts before allowing the client to direct a
media stream to a recipient address not chosen by the server. media stream to a recipient address not chosen by the server.
Implementations cannot rely on TCP as reliable means of client Implementations cannot rely on TCP as reliable means of client
identification. If the server does not allow the host address identification. If the server does not allow the host address
part of the tuple to be set, it SHALL return 463 (Destination part of the tuple to be set, it SHALL return 463 (Destination
Prohibited). Prohibited).
The host address part of the tuple MAY be empty, for example The host address part of the tuple MAY be empty, for example
":58044", in cases when only destination port is desired to be ":58044", in cases when only destination port is desired to be
specified. specified. Responses to request including the Transport header
with a dest_addr parameter SHOULD include the full destination
address that is actually used by the server. The server MUST
NOT remove address information present already in the request
when responding unless the protocol requires it.
src_addr: A general source address parameter that can contain one or src_addr: A general source address parameter that can contain one or
more address specifications. Each combination of Protocol/ more address specifications. Each combination of Protocol/
Profile/Lower Transport needs to have the format and Profile/Lower Transport needs to have the format and
interpretation of its address specification defined. For RTP/ interpretation of its address specification defined. For RTP/
AVP/UDP and RTP/AVP/TCP, the address specification is a tuple AVP/UDP and RTP/AVP/TCP, the address specification is a tuple
containing a host address and port. containing a host address and port.
This parameter MUST be specified by the server if it transmits This parameter MUST be specified by the server if it transmits
media packets from another address than the one RTSP messages media packets from another address than the one RTSP messages
skipping to change at page 131, line 32 skipping to change at page 132, line 15
channel. One example of such usage is the second channel used channel. One example of such usage is the second channel used
for RTCP, where both server and client sends RTCP packets on for RTCP, where both server and client sends RTCP packets on
the same channel. the same channel.
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live. When included in requests the value ttl: multicast time-to-live for IPv4. When included in requests the
indicate the TTL value that the client desires to use. In value indicate the TTL value that the client request the server
response the value actually being used is returned. A server to use. In a response, the value actually being used by the
will need to consider what values that are reasonable and also server is returned. A server will need to consider what values
the authority of the user to set this value. that are reasonable and also the authority of the user to set
this value. Corresponding function are not needed for IPv6 as
the scoping is part of the address.
RTP-specific: RTP-specific:
These parameters are MAY only be used if the media transport protocol These parameters are MAY only be used if the media transport protocol
is RTP. is RTP.
ssrc: The ssrc parameter, if included in a SETUP response, indicates ssrc: The ssrc parameter, if included in a SETUP response, indicates
the RTP SSRC [RFC3550] value(s) that will be used by the media the RTP SSRC [RFC3550] value(s) that will be used by the media
server for RTP packets within the stream. It is expressed as server for RTP packets within the stream. It is expressed as
an eight digit hexadecimal value. an eight digit hexadecimal value.
skipping to change at page 135, line 10 skipping to change at page 136, line 10
16.56. WWW-Authenticate 16.56. WWW-Authenticate
See [H14.47]. See [H14.47].
17. Proxies 17. Proxies
RTSP Proxies are RTSP agents that sit in between a client and a RTSP Proxies are RTSP agents that sit in between a client and a
server. A proxy can take on both the role as a client and as server server. A proxy can take on both the role as a client and as server
depending on what it tries to accomplish. Proxies are also depending on what it tries to accomplish. Proxies are also
introduced for several different reasons. introduced for several different reasons and the below are often
combined.
Caching Proxy: This type of proxy is used to reduce the workload on Caching Proxy: This type of proxy is used to reduce the workload on
servers and connections. By caching a presentation, both servers and connections. By caching a presentation, both
description and media streams the proxy can serve a client description and media streams the proxy can serve a client
content without requesting it from the server once it has been content without requesting it from the server once it has been
cached and hasn't become stale. See the caching Section 18. cached and hasn't become stale. See the caching Section 18.
This type of proxy is expected to also understand RTSP end-
point functionality, i.e. functionality identified in the
Require header in addition to what Proxy-Require demands.
Translator Proxy: This type of proxy is used to ensure that a RTSP
client get access to servers and content on an external network
or using content encodings not supported by the client. The
proxy performs the necessary translation of addresses,
protocols or encodings. This type of proxy is expected to also
understand RTSP end-point functionality, i.e. functionality
identified in the Require header in addition to what Proxy-
Require demands.
Access Proxy: This type of proxy is used to ensure that a RTSP Access Proxy: This type of proxy is used to ensure that a RTSP
client get access to servers on an external network. Thus this client get access to servers on an external network. Thus this
proxy is placed on the border between two domains, e.g. a proxy is placed on the border between two domains, e.g. a
private address space and the public internet. The proxy private address space and the public internet. The proxy
performs the necessary translation, usually addresses, and performs the necessary translation, usually addresses. This
often also media stream translation or redirection. type of proxies are required to redirect the media to
themselves or a controlled gateway that perform the translation
before the media can reach the client.
Security Proxy: This type of proxy is used to help facilitate Security Proxy: This type of proxy is used to help facilitate
security functions around RTSP. For example when having a security functions around RTSP. For example when having a
firewalled network, the security proxy request that the firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client in necessary pinholes in the firewall is opened when a client in
the protected network want to access media streams on the the protected network want to access media streams on the
external side. It can also provide network owners with a external side.This proxy can also limit the clients access to
certain type of content. This proxy can perform its function
without redirecting the media between the server and client.
However, in deployements with private address spaces this proxy
is likely to be combined with the access proxy. Anyway, the
functionality of this proxy is usually closely tied into
understand all aspects of how the media transport.
Auditing Proxy: RTSP proxies can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that tracks or limits their employees access to corporations that tracks their employees usage of the network.
certain type of content. This type of proxy can perform its function without inserting
itself or any other node in the media transport. This proxy
type can also accept unknown methods as it doesn't interfere
with the clients requests.
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificate chains with TLS as RTSP 2.0 allows the client to approve certificate chains
used for connection establishment from a proxy, see Section 19.3.2. used for connection establishment from a proxy, see Section 19.3.2.
However that trust model may not be suitable for all type of However that trust model may not be suitable for all type of
deployment, and instead secured sessions do by-pass of the proxies. deployment, and instead secured sessions do by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters etc may fail in a proxy that protocols or profiles, new parameters etc may fail in a proxy that
isn't maintained. Thus resulting in blocking further development of isn't maintained. Thus resulting in blocking further development of
RTSP and its usage. RTSP and its usage.
17.1. Proxies and Protocol Extensions
The existence of proxies must always be considered when developing The existence of proxies must always be considered when developing
new RTSP extensions. There must be definition of how proxies may new RTSP extensions. Most type of proxies will need to implement any
handle the extension, if it is required to understand it, thus new method to operate correct in the presence of that extension. New
requiring a feature-tag to be used in the Proxy-Require header. headers will be possible to introduce without being blocked by
proxies not yet updated. However, it is important to consider if
this header and its function is required to be understood by the
proxy or can be forwarded. If the header needs to be understood a
feature-tag representing the functionality needs to be included in
the Proxy-Require header. Below are guidelines for analysis if the
header needs to be understood. The transport header and its
parameters also shows that headers that are extensible and requires
correct interpretation in the proxy also requires handling rules.
When defining a new RTSP header it needs to be considered if RTSP
proxies are required to understand them to achieve correct
functionality. Determining this is not easy as the functionality for
proxies are widely varied as can be understood from the above list of
functionality. When evaluating this one can dived the functionality
into three main categories:
Media modifying: The caching and translator proxies are modifying
the actual media and therefore needs to understand also request
directed to the server that affects how the media is rendered.
Thus this type of proxies needs to also understand the server side
functionality.
Transport modifying: The access and the security proxy both need to
understand the how the transport is performed, either for opening
pinholes or to translate the outer headers, e.g. IP and UDP.
Non-modifying: The audit proxy is special in that it do not modify
the messages in other ways than to insert the Via header. That
makes it possible for this type to forward RTSP message that
contains different type of unknown methods, headers or header
parameters.
Based on the above classification one should evaluate if ones
functionality requires the Transport modifying type of proxies to
understand it or not.
18. Caching 18. Caching
In HTTP, response-request pairs are cached. RTSP differs In HTTP, response-request pairs are cached. RTSP differs
significantly in that respect. Responses are not cacheable, with the significantly in that respect. Responses are not cacheable, with the
exception of the presentation description returned by DESCRIBE. exception of the presentation description returned by DESCRIBE.
(Since the responses for anything but DESCRIBE and GET_PARAMETER do (Since the responses for anything but DESCRIBE and GET_PARAMETER do
not return any data, caching is not really an issue for these not return any data, caching is not really an issue for these
requests.) However, it is desirable for the continuous media data, requests.) However, it is desirable for the continuous media data,
typically delivered out-of-band with respect to RTSP, to be cached, typically delivered out-of-band with respect to RTSP, to be cached,
skipping to change at page 138, line 29 skipping to change at page 140, line 29
authentication [RFC2617] so that Server who requires the client to authentication [RFC2617] so that Server who requires the client to
authenticate can trust that the capability is present. authenticate can trust that the capability is present.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in not provide full control message security. Therefore, in
environments requiring tighter security for the control messages, TLS environments requiring tighter security for the control messages, TLS
SHOULD be used, see Section 19.2. SHOULD be used, see Section 19.2.
19.2. RTSP over TLS 19.2. RTSP over TLS
RTSP SHALL follow the same guidelines with regards to TLS [RFC4346] RTSP SHALL follow the same guidelines with regards to TLS [RFC5246]
usage as specified for HTTP, see [RFC2818]. RTSP over TLS is usage as specified for HTTP, see [RFC2818]. RTSP over TLS is
separated from unsecured RTSP both on URI level and port level. separated from unsecured RTSP both on URI level and port level.
Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" Instead of using the "rtsp" scheme identifier in the URI, the "rtsps"
scheme identifier MUST be used to signal RTSP over TLS. If no port scheme identifier MUST be used to signal RTSP over TLS. If no port
is given in a URI with the "rtsps" scheme, port 322 SHALL be used for is given in a URI with the "rtsps" scheme, port 322 SHALL be used for
TLS over TCP/IP. TLS over TCP/IP.
When a client tries to setup an insecure channel to the server (using When a client tries to setup an insecure channel to the server (using
the "rtsp" URI), and the policy for the resource requires a secure the "rtsp" URI), and the policy for the resource requires a secure
channel, the server SHALL redirect the client to the secure service channel, the server SHALL redirect the client to the secure service
skipping to change at page 143, line 36 skipping to change at page 145, line 36
which, by the above rule, allows whitespace before, but no line which, by the above rule, allows whitespace before, but no line
break, and whitespace after, including a linebreak. The HCOLON break, and whitespace after, including a linebreak. The HCOLON
defines this construct. defines this construct.
OCTET = %x00-FF ; any 8-bit sequence of data OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127) CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z" UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z" LOALPHA = %x61-7A ;any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9" DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control charac7ter CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127) ; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13 CR = %x0D ; US-ASCII CR, carriage return (13
LF = %x0A ; US-ASCII LF, linefeed (10) LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32) SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9) HT = %x09 ; US-ASCII HT, horizontal-tab (9)
DQ = %x22 ; US-ASCII double-quote mark (34) DQ = %x22 ; US-ASCII double-quote mark (34)
BACKSLASH = %x5C ; US-ASCII backslash (92) BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) LWS = [CRLF] 1*( SP / HT )
SWS = [LWS] ; sep whitespace SWS = [LWS] ; sep whitespace
skipping to change at page 153, line 6 skipping to change at page 155, line 6
/ ( m-type SLASH "*" ) / ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype ) / ( m-type SLASH m-subtype )
) *( SEMI m-parameter ) ) *( SEMI m-parameter )
accept-param = ("q" EQUAL qvalue) / generic-param accept-param = ("q" EQUAL qvalue) / generic-param
qvalue = ( "0" [ "." *3DIGIT ] ) qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] ) / ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info]) cred-decision = ("User" [LWS cred-info])
/ "Proxy" / "Proxy"
/ "Any" / "Any"
/ token [LWS 1*TEXT] ; For future extensions / (token [LWS 1*TEXT]) ; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data) cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64 cred-info-data = DQ RTSP-URI DQ SEMI hash-alg SEMI base64
hash-alg = "sha-256" / extension-alg hash-alg = "sha-256" / extension-alg
extension-alg = token extension-alg = token
Accept-Encoding = "Accept-Encoding" HCOLON Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ] [ encoding *(COMMA encoding) ]
encoding = codings *(SEMI accept-param) encoding = codings *(SEMI accept-param)
codings = content-coding / "*" codings = content-coding / "*"
content-coding = token content-coding = token
Accept-Language = "Accept-Language" HCOLON Accept-Language = "Accept-Language" HCOLON
[ language *(COMMA language) ] [ language *(COMMA language) ]
language = language-range *(SEMI accept-param) language = language-range *(SEMI accept-param)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" ) language-range = (1*8ALPHA *( "-" 1*8ALPHA)) / "*"
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit)) acceptable-ranges = (range-unit *(COMMA range-unit))
/ "none" / "none"
range-unit = "NPT" / "SMPTE" / "UTC" / extension-format range-unit = "NPT" / "SMPTE" / "UTC" / extension-format
extension-format = token extension-format = token
Allow = "Allow" HCOLON [Method *(COMMA Method)] Allow = "Allow" HCOLON [Method *(COMMA Method)]
Authorization = "Authorization" HCOLON credentials Authorization = "Authorization" HCOLON credentials
credentials = ("Digest" LWS digest-response) credentials = ("Digest" LWS digest-response)
/ other-response / other-response
digest-response = dig-resp *(COMMA dig-resp) digest-response = dig-resp *(COMMA dig-resp)
dig-resp = username / realm / nonce / digest-uri dig-resp = username / realm / nonce / digest-uri
/ dresponse / algorithm / cnonce / dresponse / algorithm / cnonce
/ opaque / message-qop / opaque / message-qop
/ nonce-count / auth-param / nonce-count / auth-param
username = "username" EQUAL username-value username = "username" EQUAL username-value
username-value = quoted-string username-value = quoted-string
skipping to change at page 155, line 19 skipping to change at page 157, line 17
composite-type = "message" / "multipart" / extension-token composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token extension-token = ietf-token / x-token
ietf-token = token ietf-token = token
x-token = "x-" token x-token = "x-" token
m-subtype = extension-token / iana-token m-subtype = extension-token / iana-token
iana-token = token iana-token = token
m-parameter = m-attribute EQUAL m-value m-parameter = m-attribute EQUAL m-value
m-attribute = token m-attribute = token
m-value = token / quoted-string m-value = token / quoted-string
CSeq = "Cseq" HCOLON cseq-nr CSeq = "CSeq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date Date = "Date" HCOLON RTSP-date
RTSP-date = rfc1123-date ; HTTP-date RTSP-date = rfc1123-date ; HTTP-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc1123-date = wkday "," SP date1 SP time SP "GMT"
date1 = 2DIGIT SP month SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982) ; day month year (e.g., 02 Jun 1982)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59 ; 00:00:00 - 23:59:59
wkday = "Mon" / "Tue" / "Wed" wkday = "Mon" / "Tue" / "Wed"
/ "Thu" / "Fri" / "Sat" / "Sun" / "Thu" / "Fri" / "Sat" / "Sun"
month = "Jan" / "Feb" / "Mar" / "Apr" month = "Jan" / "Feb" / "Mar" / "Apr"
/ "May" / "Jun" / "Jul" / "Aug" / "May" / "Jun" / "Jul" / "Aug"
/ "Sep" / "Oct" / "Nov" / "Dec" / "Sep" / "Oct" / "Nov" / "Dec"
ETag = "ETag" HCOLON entity-tag ETag = "ETag" HCOLON entity-tag
Expires = "Expires" HCOLON delta-seconds Expires = "Expires" HCOLON RTSP-date
From = "From" HCOLON from-spec From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-URI / absolute-URI addr-spec = RTSP-URI / absolute-URI
absolute-URI = < As defined in RFC 3986> absolute-URI = < As defined in RFC 3986>
display-name = *(token LWS)/ quoted-string display-name = *(token LWS)/ quoted-string
from-param = tag-param / generic-param from-param = tag-param / generic-param
tag-param = "tag" EQUAL token tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ( "*" / entity-tag-list) If-Match = "If-Match" HCOLON ( "*" / entity-tag-list)
entity-tag-list = entity-tag *(COMMA entity-tag) entity-tag-list = entity-tag *(COMMA entity-tag)
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
weak = "W/" weak = "W/"
opaque-tag = quoted-string opaque-tag = quoted-string
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list) If-None-Match = "If-None-Match" HCOLON ("*" / entity-tag-list)
Last-Modified = "Last-Modified" HCOLON RTSP-date Last-Modified = "Last-Modified" HCOLON RTSP-date
Location = "Location" HCOLON RTSP-URI Location = "Location" HCOLON RTSP-URI
Media-Properties = "Media-Properties" HCOLON media-prop-list Media-Properties = "Media-Properties" HCOLON media-prop-list
media-prop-list = media-prop-value *(COMMA media-prop-value) media-prop-list = media-prop-value *(COMMA media-prop-value)
media-prop-value = "Random-Access" EQUAL POS-FLOAT media-prop-value = ("Random-Access" [EQUAL POS-FLOAT])
/ "Begining-Only" / "Begining-Only"
/ "No-Seeking" / "No-Seeking"
/ "Unmutable" / "Unmutable"
/ "Dynamic" / "Dynamic"
/ "Time-Progressing" / "Time-Progressing"
/ "Unlimited" / "Unlimited"
/ "Time-Limited" EQUAL utc-range-spec / ("Time-Limited" EQUAL utc-range-spec)
/ "Time-Duration" EQUAL POS-FLOAT / ("Time-Duration" EQUAL POS-FLOAT)
/ media-prop-ext / media-prop-ext
media-prop-ext = token [EQUAL SWS 1*rtsp-unreserved / quoted-string] media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)]
Media-Range = "Media-Range" HCOLON [ranges-list] Media-Range = "Media-Range" HCOLON [ranges-list]
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream" Notify-Reas-val = "end-of-stream"
/ "media-properties-update" / "media-properties-update"
/ "scale-change" / "scale-change"
/ Notify-Reason-extension / Notify-Reason-extension
Notify-Reason-extension = token Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT startup-id = 1*8DIGIT
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = challenge *(COMMA challenge)
challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) challenge = ("Digest" LWS digest-cln *(COMMA digest-cln))
/ other-challenge / other-challenge
other-challenge = auth-scheme LWS auth-param other-challenge = auth-scheme LWS auth-param
*(COMMA auth-param) *(COMMA auth-param)
digest-cln = realm / domain / nonce digest-cln = realm / domain / nonce
/ opaque / stale / algorithm / opaque / stale / algorithm
/ qop-options / auth-param / qop-options / auth-param
realm = "realm" EQUAL realm-value realm = "realm" EQUAL realm-value
realm-value = quoted-string realm-value = quoted-string
domain = "domain" EQUAL LDQUOT URI domain = "domain" EQUAL LDQUOT URI
skipping to change at page 158, line 10 skipping to change at page 160, line 10
status-info = "status" EQUAL Status-Code status-info = "status" EQUAL Status-Code
reason-info = "reason" EQUAL DQ Reason-Phrase DQ reason-info = "reason" EQUAL DQ Reason-Phrase DQ
Require = "Require" HCOLON feature-tag-list Require = "Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag) feature-tag-list = feature-tag *(COMMA feature-tag)
RTP-Info = "RTP-Info" HCOLON rtsp-info-spec RTP-Info = "RTP-Info" HCOLON rtsp-info-spec
*(COMMA rtsp-info-spec) *(COMMA rtsp-info-spec)
rtsp-info-spec = stream-url 1*ssrc-parameter rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ stream-url = "url" EQUAL DQ RTSP-URI-Ref DQ
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter) ri-parameter *(SEMI ri-parameter)
ri-parameter = "seq" EQUAL 1*DIGIT ri-parameter = ("seq" EQUAL 1*DIGIT)
/ "rtptime" EQUAL 1*DIGIT / ("rtptime" EQUAL 1*DIGIT)
/ generic-param
Retry-After = "Retry-After" HCOLON delta-seconds Retry-After = "Retry-After" HCOLON delta-seconds
[ comment ] *( SEMI retry-param ) [ comment ] *( SEMI retry-param )
retry-param = ("duration" EQUAL delta-seconds) retry-param = ("duration" EQUAL delta-seconds)
/ generic-param / generic-param
Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ] Scale = "Scale" HCOLON ["-"] 1*DIGIT [ "." *DIGIT ]
Seek-Style = "Seek-Style" HCOLON Seek-S-values Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP" Seek-S-values = "RAP"
/ "First-Prior" / "First-Prior"
skipping to change at page 159, line 4 skipping to change at page 161, line 4
timestamp-value = *DIGIT [ "." *DIGIT ] timestamp-value = *DIGIT [ "." *DIGIT ]
delay = *DIGIT [ "." *DIGIT ] delay = *DIGIT [ "." *DIGIT ]
Transport = "Transport" HCOLON transport-spec Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec) *(COMMA transport-spec)
transport-spec = transport-id *tr-parameter transport-spec = transport-id *tr-parameter
transport-id = trans-id-rtp / other-trans transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport] trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id ; no LWS is allowed inside transport-id
other-trans = token *("/" token) other-trans = token *("/" token)
profile = "AVP" / "SAVP" / "AVPF" / token profile = "AVP" / "SAVP" / "AVPF" / token
lower-transport = "TCP" / "UDP" / token lower-transport = "TCP" / "UDP" / token
tr-parameter = SEMI ( "unicast" / "multicast" ) tr-parameter = (SEMI ( "unicast" / "multicast" ))
/ SEMI "interleaved" EQUAL channel [ "-" channel ] / (SEMI "interleaved" EQUAL channel [ "-" channel ])
/ SEMI "append" / (SEMI "ttl" EQUAL ttl)
/ SEMI "ttl" EQUAL ttl / (SEMI "layers" EQUAL 1*DIGIT)
/ SEMI "layers" EQUAL 1*DIGIT / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) / (SEMI "mode" EQUAL mode-spec)
/ SEMI "client_ssrc" EQUAL ssrc / (SEMI "dest_addr" EQUAL addr-list)
/ SEMI "mode" EQUAL mode-spec / (SEMI "src_addr" EQUAL addr-list)
/ SEMI "dest_addr" EQUAL addr-list / (SEMI trn-param-ext)
/ SEMI "src_addr" EQUAL addr-list / (SEMI "setup" EQUAL contrans-setup)
/ SEMI trn-param-ext / (SEMI "connection" EQUAL contrans-con)
/ SEMI "setup" EQUAL contrans-setup
/ SEMI "connection" EQUAL contrans-con
contrans-setup = "active" / "passive" / "actpass" contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing" contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value] trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token par-name = token
trn-par-value = *(rtsp-unreserved / DQ *TEXT DQ) trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX ssrc = 8HEX
channel = 1*3DIGIT channel = 1*3DIGIT
mode-spec = ( DQ mode *(COMMA mode) DQ ) mode-spec = ( DQ mode *(COMMA mode) DQ )
mode = "PLAY" / token mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr) addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQ (host-port / extension-addr) DQ quoted-addr = DQ (host-port / extension-addr) DQ
host-port = host [":" port] host-port = host [":" port]
/ ":" port / ":" port
extension-addr = 1*qdtext extension-addr = 1*qdtext
skipping to change at page 160, line 32 skipping to change at page 162, line 32
via-branch = "branch" EQUAL token via-branch = "branch" EQUAL token
via-extension = generic-param via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot SLASH transport-prot
protocol-name = "RTSP" / token protocol-name = "RTSP" / token
protocol-version = token protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token other-transport = token
sent-by = host [ COLON port ] sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list
20.3. SDP extension Syntax 20.3. SDP extension Syntax
This section defines in ABNF the SDP extensions defined for RTSP. This section defines in ABNF the SDP extensions defined for RTSP.
See Appendix D for the definition of the extensions in text. See Appendix D for the definition of the extensions in text.
control-attribute = "a=control:" *SP RTSP-URI control-attribute = "a=control:" *SP RTSP-URI
a-range-def = "a=range:" ranges-spec CRLF a-range-def = "a=range:" ranges-spec CRLF
skipping to change at page 162, line 38 skipping to change at page 164, line 38
server SHOULD use a large, random and non-sequential session server SHOULD use a large, random and non-sequential session
identifier to minimize the possibility of this kind of attack. identifier to minimize the possibility of this kind of attack.
However, unless the RTSP signalling always are confedentiality However, unless the RTSP signalling always are confedentiality
protected, e.g. using TLS, an on-path attacker will be able to protected, e.g. using TLS, an on-path attacker will be able to
hijack a session. For real session security, client hijack a session. For real session security, client
authentication needs to be performed. authentication needs to be performed.
Authentication: Servers SHOULD implement both basic and digest Authentication: Servers SHOULD implement both basic and digest
[RFC2617] authentication. In environments requiring tighter [RFC2617] authentication. In environments requiring tighter
security for the control messages, the transport layer security for the control messages, the transport layer
mechanism TLS (RFC 4346 [RFC4346]) SHOULD be used. mechanism TLS [RFC5246] SHOULD be used.
Stream issues: RTSP only provides for stream control. Stream Stream issues: RTSP only provides for stream control. Stream
delivery issues are not covered in this section, nor in the delivery issues are not covered in this section, nor in the
rest of this draft. RTSP implementations will most likely rely rest of this draft. RTSP implementations will most likely rely
on other protocols such as RTP, IP multicast, RSVP and IGMP, on other protocols such as RTP, IP multicast, RSVP and IGMP,
and should address security considerations brought up in those and should address security considerations brought up in those
and other applicable specifications. and other applicable specifications.
Persistently suspicious behavior: RTSP servers SHOULD return error Persistently suspicious behavior: RTSP servers SHOULD return error
code 403 (Forbidden) upon receiving a single instance of code 403 (Forbidden) upon receiving a single instance of
skipping to change at page 165, line 15 skipping to change at page 167, line 15
22. IANA Considerations 22. IANA Considerations
This section sets up a number of registries for RTSP 2.0 that should This section sets up a number of registries for RTSP 2.0 that should
be maintained by IANA. For each registry there is a description on be maintained by IANA. For each registry there is a description on
what it is required to contain, what specification is needed when what it is required to contain, what specification is needed when
adding a entry with IANA, and finally the entries that this document adding a entry with IANA, and finally the entries that this document
needs to register. See also the Section 2.3 "Extending RTSP". There needs to register. See also the Section 2.3 "Extending RTSP". There
is also an IANA registration of two SDP attributes. is also an IANA registration of two SDP attributes.
The sections describing how to register an item uses some of the The sections describing how to register an item uses some of the
requirements level described in RFC YYYY requirements level described in RFC 5226 [RFC5226], namely "First
[I-D.narten-iana-considerations-rfc2434bis], namely "First Come, Come, First Served", "Expert Review, "Specification Required", and
First Served", "Expert Review, "Specification Required", and
"Standards Action". "Standards Action".
A registration request to IANA MUST contain the following A registration request to IANA MUST contain the following
information: information:
o A name of the item to register according to the rules specified by o A name of the item to register according to the rules specified by
the intended registry. the intended registry.
o Indication of who has change control over the feature (for o Indication of who has change control over the feature (for
example, IETF, ISO, ITU-T, other international standardization example, IETF, ISO, ITU-T, other international standardization
skipping to change at page 169, line 12 skipping to change at page 171, line 12
o 3GPP-Adaptation defined in [3gpp-26234]. o 3GPP-Adaptation defined in [3gpp-26234].
o 3GPP-QoE-Metrics defined in [3gpp-26234]. o 3GPP-QoE-Metrics defined in [3gpp-26234].
o 3GPP-QoE-Feedback defined in [3gpp-26234]. o 3GPP-QoE-Feedback defined in [3gpp-26234].
The use of "x-" is NOT RECOMMENDED but the above headers in the The use of "x-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
22.5. Transport Header Registries 22.5. Accept-Credentials
The transport header contains a number of parameters which have The security framework's TLS connection mechanism has two
possibilities for future extensions. Therefore registries for these registerable entities.
needs to be defined.
22.5.1. Transport Protocol Specification 22.5.1. Accept-Credentials policies
A registry for the parameter transport-protocol specification SHALL In Section 19.3.1 three policies for how to handle certificates.
be defined with the following rules: Further policies may be defined and SHALL be registered with IANA
using the following rules:
o Registering uses the policy of Specification Required. o Registering requires an IETF Standards Action
o A contact person or organization with address and email. o A registration is required to name a contact person.
o A value definition that are following the ABNF syntax definition. o Name of the policy.
o A describing text that explains how the registered value are used o A describing text that explains how the policy works for handling
in RTSP. the certificates.
This specification registers the following values: This specification registers the following values:
RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in Any
combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over UDP. The usage
is explained in RFC XXXX, appendix Appendix C.1.
RTP/AVP/UDP: the same as RTP/AVP.
RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is
explained in RFC XXXX, appendix Appendix C.1.
RTP/AVPF/UDP: the same as RTP/AVPF.
RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "The Secure Real-time Transport Protocol
(SRTP)" [RFC3711] over UDP. The usage is explained in RFC
XXXX, appendix Appendix C.1.
RTP/SAVP/UDP: the same as RTP/SAVP.
RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "[RFC5124] over UDP. The usage is
explained in RFC XXXX, appendix Appendix C.1.
RTP/SAVPF/UDP: the same as RTP/SAVPF.
RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over TCP. The usage
is explained in RFC XXXX, appendix Appendix C.2.2.
RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained
in RFC XXXX, appendix Appendix C.2.2.
RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "The Secure Real-time Transport
Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in
RFC XXXX, appendix Appendix C.2.2.
RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "[RFC5124] over TCP. The usage is
explained in RFC XXXX, appendix Appendix C.2.2.
22.5.2. Transport modes
A registry for the transport parameter mode SHALL be defined with the
following rules:
o Registering requires an IETF Standards Action.
o A contact person or organization with address and email.
o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used
in RTSP.
This specification registers 1 value:
PLAY: See RFC XXXX. Proxy
22.5.3. Transport Parameters User
A registry for parameters that may be included in the Transport 22.5.2. Accept-Credentials hash algorithms
header SHALL be defined with the following rules:
o Registering uses the Specification Required policy. The Accept-Credentials header (See Section 16.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely
rare and could also be an interoperability problem. Therefore the
bar for registering new algorithms is placed intentional high.
o A value definition that are following the ABNF token definition. Any registration of a new hash algorithm SHALL fulfill the following
requirement:
o A describing text that explains how the registered value are used o Follow the IETF Standards Action policy.
in RTSP.
This specification registers all the transport parameters defined in o A definition of the algorithm and its identifier meeting the
Section 16.51. "token" ABNF requirement.
22.6. Cache Directive Extensions 22.6. Cache-Control Cache Directive Extensions
There exist a number of cache directives which can be sent in the There exist a number of cache directives which can be sent in the
Cache-Control header. A registry for this cache directives SHALL be Cache-Control header. A registry for this cache directives SHALL be
defined with the following rules: defined with the following rules:
o Registering requires an IETF Standards Action. o Registering requires an IETF Standards Action.
o A registration is required to contain a contact person. o A registration is required to contain a contact person.
o Name of the directive and a definition of the value, if any. o Name of the directive and a definition of the value, if any.
skipping to change at page 172, line 13 skipping to change at page 172, line 47
max-stale: max-stale:
min-fresh: min-fresh:
must-revalidate: must-revalidate:
proxy-revalidate: proxy-revalidate:
max-age: max-age:
22.7. Accept-Credentials 22.7. Media Properties
The security framework's TLS connection mechanism has two
registerable entities.
22.7.1. Accept-Credentials policies
In Section 19.3.1 three policies for how to handle certificates.
Further policies may be defined and SHALL be registered with IANA
using the following rules:
o Registering requires an IETF Standards Action
o A registration is required to name a contact person.
o Name of the policy.
o A describing text that explains how the policy works for handling
the certificates.
This specification registers the following values:
Any
Proxy
User
22.7.2. Accept-Credentials hash algorithms
The Accept-Credentials header (See Section 16.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely
rare and could also be an interoperability problem. Therefore the
bar for registering new algorithms is placed intentional high.
Any registration of a new hash algorithm SHALL fulfill the following
requirement:
o Follow the IETF Standards Action policy.
o A definition of the algorithm and its identifier meeting the
"token" ABNF requirement.
22.8. Range header formats
The Range header allows for different range formats. New ones may be
registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the
following requirements:
o Follow the Specification Required policy.
o A ABNF definition of the range format that fulfils the "range-ext"
definition.
o A Contact person for the registration.
o Rules for how one handles the range when using a negative Scale.
22.9. Media Property Values
22.9.1. Description 22.7.1. Description
The media streams being controlled by RTSP can have many different The media streams being controlled by RTSP can have many different
properties. The media properties required to cover the use cases properties. The media properties required to cover the use cases
that was in mind when writing the specification are defined. that was in mind when writing the specification are defined.
However, it can be expected that further inovation will result in new However, it can be expected that further inovation will result in new
use cases or media streams with properties not covered by the one use cases or media streams with properties not covered by the one
specified here. Thus new ones can be specified. As new media specified here. Thus new ones can be specified. As new media
properties may need substantial amount of new definitions to properties may need substantial amount of new definitions to
correctly specify behavior for this property the bar is intended to correctly specify behavior for this property the bar is intended to
be high. be high.
22.9.2. Registration Rules 22.7.2. Registration Rules
Registering new media property SHALL fulfill the following Registering new media property SHALL fulfill the following
requirements requirements
o Follow the Specification Required policy and get the approval of o Follow the Specification Required policy and get the approval of
the designated Expert. the designated Expert.
o Have a ABNF definition of the media property value name that meets o Have a ABNF definition of the media property value name that meets
"media-prop-ext" definition "media-prop-ext" definition
skipping to change at page 174, line 4 skipping to change at page 173, line 29
Registering new media property SHALL fulfill the following Registering new media property SHALL fulfill the following
requirements requirements
o Follow the Specification Required policy and get the approval of o Follow the Specification Required policy and get the approval of
the designated Expert. the designated Expert.
o Have a ABNF definition of the media property value name that meets o Have a ABNF definition of the media property value name that meets
"media-prop-ext" definition "media-prop-ext" definition
o A Contact Person for the Registration o A Contact Person for the Registration
o Description of all changes to the behavior of RTSP protocol as o Description of all changes to the behavior of RTSP protocol as
result of these changes. result of these changes.
22.9.3. Registered Values 22.7.3. Registered Values
This specification registers the 9 values listed in Section 16.29. This specification registers the 9 values listed in Section 16.29.
22.10. Notify-Reason header 22.8. Notify-Reason header
22.10.1. Description 22.8.1. Description
Notify-Reason values are the way to indicate why a notification was Notify-Reason values are the way to indicate why a notification was
sent. It may also imply that certain headers shall or should be sent. It may also imply that certain headers shall or should be
present required for the client to act upon the information the present required for the client to act upon the information the
notification carries. New notification behaviors do need to be notification carries. New notification behaviors do need to be
described to result in interoperable usage, thus specification are described to result in interoperable usage, thus specification are
required. required.
22.10.2. Registration Rules 22.8.2. Registration Rules
Registrations for new Notify-Reason value SHALL fulfill the following Registrations for new Notify-Reason value SHALL fulfill the following
requirements requirements
o Follow the Specification Required policy and get the approval of o Follow the Specification Required policy and get the approval of
the designated Expert. the designated Expert.
o Have a ABNF definition of the Notify reason value name that meets o Have a ABNF definition of the Notify reason value name that meets
"Notify-Reason-extension" definition "Notify-Reason-extension" definition
o A Contact Person for the Registration o A Contact Person for the Registration
o Description of which headers shall be included in the request and o Description of which headers shall be included in the request and
response, when it should be sent, and any affect it has on the response, when it should be sent, and any affect it has on the
skipping to change at page 174, line 39 skipping to change at page 174, line 16
o Have a ABNF definition of the Notify reason value name that meets o Have a ABNF definition of the Notify reason value name that meets
"Notify-Reason-extension" definition "Notify-Reason-extension" definition
o A Contact Person for the Registration o A Contact Person for the Registration
o Description of which headers shall be included in the request and o Description of which headers shall be included in the request and
response, when it should be sent, and any affect it has on the response, when it should be sent, and any affect it has on the
server client state. server client state.
22.10.3. Registered Values 22.8.3. Registered Values
This specification registers 3 values defined in the Notify-Reas-val This specification registers 3 values defined in the Notify-Reas-val
ABNFSection 20.2.3: ABNFSection 20.2.3:
o end-of-stream o end-of-stream
o media-properties-update o media-properties-update
o scale-change o scale-change
22.11. Seek-Style 22.9. Range header formats
The Range header allows for different range formats. New ones may be
registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the
following requirements:
o Follow the Specification Required policy.
o A ABNF definition of the range format that fulfils the "range-ext"
definition.
o A Contact person for the registration.
o Rules for how one handles the range when using a negative Scale.
22.10. RTP-Info header parameters
22.10.1. Desctiption
The RTP-Info header (Section 16.43) carries one or more parameter
value pairs with information about a particular point in the RTP
stream. RTP extensions or new usages may need new types of
information. As RTP information that could be needed is likely to be
generic enough and to maximize the interoperability registration
requires specification required.
22.10.2. Registration Rules
Registrations for new Notify-Reason value SHALL fulfill the following
requirements
o Follow the Specification Required policy and get the approval of
the designated Expert.
o Have a ABNF definition that meets the "generic-param" definition
o A Contact Person for the Registration
22.10.3. Registered Values
This specification registers 2 parameter value pairs:
o seq
o rtptime
22.11. Seek-Style Policies
22.11.1. Description 22.11.1. Description
New seek policies may be registered, however a large number of these New seek policies may be registered, however a large number of these
will complicate implementation substantially. The impact of unknown will complicate implementation substantially. The impact of unknown
policies is that the server will not honor the unknown and use the policies is that the server will not honor the unknown and use the
server default policy instead. server default policy instead.
22.11.2. Registration Rules 22.11.2. Registration Rules
skipping to change at page 175, line 40 skipping to change at page 176, line 15
22.11.3. Registered Values 22.11.3. Registered Values
This specification registers 3 values: This specification registers 3 values:
o RAP o RAP
o First-Prior o First-Prior
o Next o Next
22.12. URI Schemes 22.12. Transport Header Registries
The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these
needs to be defined.
22.12.1. Transport Protocol Specification
A registry for the parameter transport-protocol specification SHALL
be defined with the following rules:
o Registering uses the policy of Specification Required.
o A contact person or organization with address and email.
o A value definition that are following the ABNF syntax definition.
o A describing text that explains how the registered value are used
in RTSP.
This specification registers the following values:
RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over UDP. The usage
is explained in RFC XXXX, appendix Appendix C.1.
RTP/AVP/UDP: the same as RTP/AVP.
RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is
explained in RFC XXXX, appendix Appendix C.1.
RTP/AVPF/UDP: the same as RTP/AVPF.
RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "The Secure Real-time Transport Protocol
(SRTP)" [RFC3711] over UDP. The usage is explained in RFC
XXXX, appendix Appendix C.1.
RTP/SAVP/UDP: the same as RTP/SAVP.
RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "[RFC5124] over UDP. The usage is
explained in RFC XXXX, appendix Appendix C.1.
RTP/SAVPF/UDP: the same as RTP/SAVPF.
RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over TCP. The usage
is explained in RFC XXXX, appendix Appendix C.2.2.
RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained
in RFC XXXX, appendix Appendix C.2.2.
RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "The Secure Real-time Transport
Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in
RFC XXXX, appendix Appendix C.2.2.
RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "[RFC5124] over TCP. The usage is
explained in RFC XXXX, appendix Appendix C.2.2.
22.12.2. Transport modes
A registry for the transport parameter mode SHALL be defined with the
following rules:
o Registering requires an IETF Standards Action.
o A contact person or organization with address and email.
o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used
in RTSP.
This specification registers 1 value:
PLAY: See RFC XXXX.
22.12.3. Transport Parameters
A registry for parameters that may be included in the Transport
header SHALL be defined with the following rules:
o Registering uses the Specification Required policy.
o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used
in RTSP.
This specification registers all the transport parameters defined in
Section 16.51.
22.13. URI Schemes
This specification defines two URI schemes ("rtsp" and "rtsps") and This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). Registrations are following RFC reserves a third one ("rtspu"). Registrations are following RFC
4395[RFC4395]. 4395[RFC4395].
22.12.1. The rtsp URI Scheme 22.13.1. The rtsp URI Scheme
URI scheme name: rtsp URI scheme name: rtsp
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP). RTSP allows different operations on the Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However the
operations that are currently defined are: Describing the operations that are currently defined are: Describing the
skipping to change at page 176, line 42 skipping to change at page 179, line 22
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 applies also to this scheme. They needs
to be reviewed and considered in any implementation utilizing to be reviewed and considered in any implementation utilizing
this scheme. this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
22.12.2. The rtsps URI Scheme 22.13.2. The rtsps URI Scheme
URI scheme name: rtsps URI scheme name: rtsps
Status: Permanent Status: Permanent
URI scheme syntax: See Section 20.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsps scheme is used to indicate resources URI scheme semantics: The rtsps scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over TLS. RTSP allows different operations on Protocol (RTSP) over TLS. RTSP allows different operations on
skipping to change at page 177, line 39 skipping to change at page 180, line 18
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 applies also to this scheme. They needs
to be reviewed and considered in any implementation utilizing to be reviewed and considered in any implementation utilizing
this scheme. this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
22.12.3. The rtspu URI Scheme 22.13.3. The rtspu URI Scheme
URI scheme name: rtspu URI scheme name: rtspu
Status: Permanent Status: Permanent
URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme syntax: See Section 3.2 of RFC 2326.
URI scheme semantics: The rtspu scheme is used to indicate resources URI scheme semantics: The rtspu scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over unrelaible datagram transport. RTSP Protocol (RTSP) over unrelaible datagram transport. RTSP
skipping to change at page 178, line 33 skipping to change at page 181, line 16
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 applies also to this scheme. They needs
to be reviewed and considered in any implementation utilizing to be reviewed and considered in any implementation utilizing
this scheme. this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF Author/Change controller: IETF
References: RFC 2326, RFC 3986, RFC 3987 References: RFC 2326, RFC 3986, RFC 3987
22.13. SDP attributes 22.14. SDP attributes
This specification defines three SDP [RFC4566] attributes that it is This specification defines three SDP [RFC4566] attributes that it is
requested that IANA register. requested that IANA register.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: range Attribute name: range
Long form: Media Range Attribute Long form: Media Range Attribute
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
skipping to change at page 179, line 34 skipping to change at page 182, line 5
Attribute name: etag Attribute name: etag
Long form: Entity Tag Long form: Entity Tag
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
Subject to charset: No Subject to charset: No
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
Values: See ABNF definition Values: See ABNF definition
22.14. Media Type Registration for text/parameters 22.15. Media Type Registration for text/parameters
Type name: text Type name: text
Subtype name: parameters Subtype name: parameters
Required parameters: Required parameters:
Optional parameters: Optional parameters:
Encoding considerations: Encoding considerations:
skipping to change at page 181, line 20 skipping to change at page 184, line 20
Third Generation Partnership Project (3GPP), "Transparent Third Generation Partnership Project (3GPP), "Transparent
end-to-end Packet-switched Streaming Service (PSS); end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs; Technical Specification 26.234", Protocols and codecs; Technical Specification 26.234",
December 2002. December 2002.
[FIPS-pub-180-2] [FIPS-pub-180-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Federal Information Processing Standards Publications "Federal Information Processing Standards Publications
(FIPS PUBS) 180-2: Secure Hash Standard", Augusti 2002. (FIPS PUBS) 180-2: Secure Hash Standard", Augusti 2002.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 182, line 38 skipping to change at page 185, line 27
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006. RFC 4395, February 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. [RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Description Protocol (SDP) and Real Time Streaming
skipping to change at page 183, line 21 skipping to change at page 186, line 7
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
23.2. Informative References 23.2. Informative References
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "An Network Goldberg, J., Westerlund, M., and T. Zeng, "An Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)", controlled by Real-Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-06 (work in progress), draft-ietf-mmusic-rtsp-nat-07 (work in progress),
February 2008. July 2008.
[ISO.13818-1.2000] [ISO.13818-1.2000]
International Organization for Standardization, International Organization for Standardization,
"Information technology - Generic coding of moving "Information technology - Generic coding of moving
pictures and associated audio information: Systems", ISO/ pictures and associated audio information: Systems", ISO/
IEC 13818-1:2000, December 2000. IEC 13818-1:2000, December 2000.
[ISO.13818-6.1995] [ISO.13818-6.1995]
International Organization for Standardization, International Organization for Standardization,
"Information technology - Generic coding of moving "Information technology - Generic coding of moving
skipping to change at page 185, line 5 skipping to change at page 187, line 51
June 2002. June 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[Stevens98]
Stevens, W., "Unix Networking Programming - Volume 1,
second edition", 1998.
[W3C.REC-PICS-labels] [W3C.REC-PICS-labels]
Miller, J., Krauskopf, T., Resnick, P., and W. Treese, Miller, J., Krauskopf, T., Resnick, P., and W. Treese,
"PICS label distribution label syntax and communication "PICS label distribution label syntax and communication
protocols", W3C REC-PICS-labels-961031. protocols", W3C REC-PICS-labels-961031.
[W3C.REC-PICS-services] [W3C.REC-PICS-services]
Miller, J., Resnick, P., and D. Singer, "Rating services Miller, J., Resnick, P., and D. Singer, "Rating services
and rating systems (and their machine readable and rating systems (and their machine readable
descriptions)", W3C REC-PICS-services-961031, descriptions)", W3C REC-PICS-services-961031,
October 1996. October 1996.
skipping to change at page 187, line 14 skipping to change at page 190, line 14
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001" Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; Transport: RTP/AVP;unicast; ssrc=93CB001E;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="192.0.2.5:9000"/"192.0.2.5:9001" src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003" Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678 Session: 12345678
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; Transport: RTP/AVP;unicast; ssrc=A813FC13;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT Accept-Range: NPT
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30- Range: npt=0-10, npt=30-
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"; url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5 CSeq: 5
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 5 CSeq: 5
Server: PhonyServer/1.0 Server: PhonyServer/1.0
skipping to change at page 190, line 27 skipping to change at page 193, line 27
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
m=video 0 RTP/AVP 26 m=video 0 RTP/AVP 26
a=control: trackID=4 a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
skipping to change at page 191, line 21 skipping to change at page 194, line 22
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4 CSeq: 4
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30- Range: npt=0-10, npt=30-
Session: 12345678 Session: 12345678
Pipelined-Requests: 7654 Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001; Transport: RTP/AVP;unicast;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001" dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="192.0.2.5:9000"/"192.0.2.5:9001";
ssrc=93CB001E ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003; Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003"; src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13 ssrc=A813FC13
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT Accept-Range: NPT
Pipelined-Requests: 7654 Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4" RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012, ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"; url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654 Pipelined-Requests: 7654
A.3. Media on Demand (Unicast) A.3. Media on Demand (Unicast)
An alternative example of media on demand with a bit more tweaks is An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two the following. Client C requests a movie distributed from two
different media servers A (audio.example.com) and V ( different media servers A (audio.example.com) and V (
video.example.com). The media description is stored on a web server video.example.com). The media description is stored on a web server
W. The media description contains descriptions of the presentation W. The media description contains descriptions of the presentation
skipping to change at page 193, line 12 skipping to change at page 196, line 12
In this example, the client is only interested in the last part of In this example, the client is only interested in the last part of
the movie. the movie.
C->W: GET /twister.sdp HTTP/1.1 C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com Host: www.example.com
Accept: application/sdp Accept: application/sdp
W->C: HTTP/1.0 200 OK W->C: HTTP/1.0 200 OK
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 264 Content-Length: 278
Expires: 23 Jan 1998 15:35:06 GMT Expires: 23 Jan 1998 15:35:06 GMT
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5 o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0
a=range:npt=0-1:49:34 a=range:npt=0-1:49:34
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31 m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0 C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
A->C: RTSP/2.0 200 OK A->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001" src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public Cache-Control: public
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0 C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059", Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
V->C: RTSP/2.0 200 OK V->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Session: 23456789 Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059"; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003" src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Cache-Control: public Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0 C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 196, line 23 skipping to change at page 199, line 23
C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0 C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp Accept: application/x-rtsp-mh, application/sdp
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Content-base: rtsp://foo.com/test.wav/ Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp Content-type: application/sdp
Content-length: 148 Content-length: 163
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT Expires: 23 Jan 1997 17:00:00 GMT
v=0 v=0
o=- 872653257 872653257 IN IP4 192.0.2.5 o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file s=mu-law wave file
i=audio test i=audio test
c=IN IP4 0.0.0.0
t=0 0 t=0 0
a=control: * a=control: *
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control:streamid=0 a=control:streamid=0
C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0 C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast; Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY" dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971"; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="192.0.2.5:6970"/"192.0.2.5:6971"; src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712 mode="PLAY";ssrc=EAB98712
CSeq: 2 CSeq: 2
Session: 2034820394 Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT Date: 23 Jan 1997 15:35:07 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0 C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0
skipping to change at page 198, line 32 skipping to change at page 201, line 32
</html> </html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0 C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1 CSeq: 1
Supported: play.basic, play.scale Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 182 Content-Length: 183
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Supported: play.basic Supported: play.basic
v=0 v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5 o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
t=0 0
m=audio 3456 RTP/AVP 0 m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16 c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio a=control: rtsp://live.example.com/concert/audio
a=range:npt=0- a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0 C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2 CSeq: 2
Transport: RTP/AVP;multicast Transport: RTP/AVP;multicast
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/" Transport: RTP/AVP;multicast;
224.2.0.1:3457";ttl=16 dest_addr="224.2.0.1:3456"/"224.2.0.1:3457";ttl=16
Session: 0456804596 Session: 0456804596
Accept-Ranges: NPT, UTC Accept-Ranges: NPT, UTC
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0 C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3 CSeq: 3
Session: 0456804596 Session: 0456804596
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
skipping to change at page 200, line 23 skipping to change at page 203, line 23
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request it tells the server that it When the client sends its SETUP request it tells the server that it
is requires support of the play.scale feature for this session by is requires support of the play.scale feature for this session by
including the Require header. including the Require header.
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0 C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3 CSeq: 3
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057", Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
RTP/AVP/TCP;unicast;interleaved=0-1 RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale Require: play.scale
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 3 CSeq: 3
Session: 12345678 Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057"; Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001" src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Server: PhonyServer/2.0 Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
Appendix B. RTSP Protocol State Machine Appendix B. RTSP Protocol State Machine
The RTSP session state machine describes the behavior of the protocol The RTSP session state machine describes the behavior of the protocol
from RTSP session initialization through RTSP session termination. from RTSP session initialization through RTSP session termination.
The State machine is defined on a per session basis which is uniquely The State machine is defined on a per session basis which is uniquely
skipping to change at page 202, line 41 skipping to change at page 205, line 41
The response to valid request meeting the requisites is normally a The response to valid request meeting the requisites is normally a
2xx (SUCCESS) unless other noted in the response column. The 2xx (SUCCESS) unless other noted in the response column. The
exceptions needs to be given a response according to the response exceptions needs to be given a response according to the response
column. If the request does not meet the requisite, is erroneous or column. If the request does not meet the requisite, is erroneous or
some other type of error occur the appropriate response code MUST be some other type of error occur the appropriate response code MUST be
sent. If the response code is a 4xx the session state is unchanged. sent. If the response code is a 4xx the session state is unchanged.
A response code of 3rr will result in that the session is ended and A response code of 3rr will result in that the session is ended and
its state is changed to Init. A response code of 304 results in no its state is changed to Init. A response code of 304 results in no
state change. However there exist restrictions to when a 3rr state change. However there exist restrictions to when a 3rr
response may be used. A 5xx response SHALL not result in any change response may be used. A 5xx response SHALL NOT result in any change
of the session state, except if the error is not possible to recover of the session state, except if the error is not possible to recover
from. A unrecoverable error SHALL result the ending of the session. from. A unrecoverable error SHALL result the ending of the session.
As it in the general case can't be determined if it was a As it in the general case can't be determined if it was a
unrecoverable error or not the client will be required to test. In unrecoverable error or not the client will be required to test. In
the case that the next request after a 5xx is responded with 454 the case that the next request after a 5xx is responded with 454
(Session Not Found) the client knows that the session has ended. (Session Not Found) the client knows that the session has ended.
The server will timeout the session after the period of time The server will timeout the session after the period of time
specified in the SETUP response, if no activity from the client is specified in the SETUP response, if no activity from the client is
detected. Therefore there exist a timeout event for all states detected. Therefore there exist a timeout event for all states
skipping to change at page 213, line 14 skipping to change at page 216, line 14
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 257 Content-Length: 227
Content-Base: rtsp://example.com/twister.3gp/ Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT Expires: 24 Jan 1997 15:35:06 GMT
v=0 v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5 o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session s=RTSP Session
i=An Example of RTSP Session Usage i=An Example of RTSP Session Usage
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0
a=control: * a=control: *
a=range: npt=0-0:10:34.10 a=range: npt=0-0:10:34.10
t=0 0 t=0 0
m=audio 0 RTP/AVP 0 m=audio 0 RTP/AVP 0
a=control: trackID=1 a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0 C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2 CSeq: 2
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Require: play.basic Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9" Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"
setup=active;connection=new setup=active;connection=new
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 2 CSeq: 2
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9"; Transport: RTP/AVP/TCP;unicast;
dest_addr=":9"/":9";
src_addr="192.0.2.5:9000"/"192.0.2.5:9001" src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
setup=passive;connection=new;ssrc=93CB001E setup=passive;connection=new;ssrc=93CB001E
Session: 12345678 Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT Accept-Ranges: NPT
C->M: TCP Connection Establishment C->M: TCP Connection Establishment
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0 C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
skipping to change at page 214, line 31 skipping to change at page 217, line 32
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30- Range: npt=0-10, npt=30-
Session: 12345678 Session: 12345678
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"; RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
C.2.3. Handling NPT Jumps in the RTP Media Layer C.2.3. Handling Media Clock Time Jumps in the RTP Media Layer
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer[RFC3550]. Such control allows jumps to be created in NPT media layer[RFC3550]. Such control allows jumps to be created in
timeline of the RTSP session. For example, jumps in NPT can be media clock (e.g. NPT) timeline of the RTSP session. The simple
caused by multiple ranges in the range specifier of a PLAY request or case of jumps in media clock time is caused by multiple ranges in the
through a "seek" opertaion on an RTSP session which involves a PLAY, range specifier of a PLAY request. This allows the media layer
PAUSE, PLAY scenario where a new NPT is set for the session. The rendering the RTP stream without being affected by jumps in media
media layer rendering the RTP stream should not be affected by jumps clock time. The RTP timestamps for the next media segment is set so
in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be that they become continuous with the previous media segment in the
continuous and monotonic across jumps of NPT. request. The RTP sequence number for the first packet in the new
segment will be the next following the last packet in the previous
segment, i.e. monotonically increasing. The goal is to allow the
media rendering layer to work without interruption or reconfiguration
across the jumps in media clock. This should be possible in all
cases of multiple ranges in a PLAY request for media that has random-
access properties. It is also possible when one PLAY request
replaces another ongoing for media with random-access properties. In
both cases care to align frames or similar media dependent structures
are need but likely possible.
In cases where jumps in media clock time are a result of RTSP
signalling operations arriving during or after an PLAY operation, the
processing delay or request timing can result in that media becomes
non-continuous. The server becomes unable to send the media so that
it arrive timely and still carry timestamps to make the media stream
continuous. In these cases the server will produce RTP streams where
there are gaps in the RTP timeline for the media. In such cases, if
the media has frame structure, aligning the timestamp for the next
frame with the previous structure reduces the burden to render this
media. The gap should represent the time the server hasn't been
serving media, e.g. the time between the end of the media stream or a
PAUSE request and the new PLAY request. In these cases the RTP
sequence number would normally be monotonically increasing across the
gap.
For RTSP sessions with media that lacks random access properties,
like live streams, any media clock jump is commonly result of
correspondingly long pause of delivery. The RTP timestamp will have
increased in direct proportion to the duration of the paused
delivery. Not also that in this case the RTP sequence number should
be the next packet number. If not, the RTCP packet loss reporting
will indicate as loss all packets not received between the point of
pausing and later resuming. This may trigger congestion avoidance
mechanisms.
The goal when handling jumps in media clock time is that the provided
stream is continuous without gaps in RTP timestamp or sequence
number. However, when delivery has been halted for some reason the
RTP timestamp when resuming SHALL represent the duration the delivery
was halted. RTP sequence number MUST be the next number. A client
can not rely on that a server will align when resuming playing even
if it is RECOMMENDED. The RTP-Info header will provide information
if this have occurred or not.
We cannot assume that the RTSP client can communicate with the RTP We cannot assume that the RTSP client can communicate with the RTP
media agent, as the two may be independent processes. If the RTP media agent, as the two may be independent processes. If the RTP
timestamp shows the same gap as the NPT, the media agent will timestamp shows the same gap as the NPT, the media agent will
assume that there is a pause in the presentation. If the jump in assume that there is a pause in the presentation. If the jump in
NPT is large enough, the RTP timestamp may roll over and the media NPT is large enough, the RTP timestamp may roll over and the media
agent may believe later packets to be duplicates of packets just agent may believe later packets to be duplicates of packets just
played out. played out. Having the RTP timestamp jump will also affect the
RTCP measurements based on this.
As an example, assume a clock frequency of 8000 Hz, a packetization As an example, assume a RTP timestamp frequency of 8000 Hz, a
interval of 100 ms and an initial sequence number and timestamp of packetization interval of 100 ms and an initial sequence number and
zero. timestamp of zero.
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
Range: npt=10-15 Range: npt=10-15
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Session: abcdefg Session: abcdefg
skipping to change at page 220, line 32 skipping to change at page 224, line 32
RTSP. This section provides the necessary steps that needs to be RTSP. This section provides the necessary steps that needs to be
meet. meet.
The following things needs to be considered when adding a new The following things needs to be considered when adding a new
protocol of profile for use with RTSP: protocol of profile for use with RTSP:
o The protocol or profile needs to define a name tag representing o The protocol or profile needs to define a name tag representing
it. This tag is required to be a ABNF "token" to be possible to it. This tag is required to be a ABNF "token" to be possible to
use in the Transport header specification. use in the Transport header specification.
o The useful combinations of protocol/profile/lower-layer needs to o The useful combinations of protocol, profiles and lower layer
be defined and for each combination declare the necessary transport for this extension needs to be defined. For each
parameters to use in the Transport header. combination declare the necessary parameters to use in the
Transport header.
o For new media protocols the interaction with RTSP needs to be o For new media protocols the interaction with RTSP needs to be
addressed. One important factor will be the media addressed. One important factor will be the media
synchronization. synchronization. May need new headers similar to RTP info to
carry information.
o Discuss congestion control for media, especially if transport
without built in congestion control is used.
See the IANA section (Section 22) for information how to register new See the IANA section (Section 22) for information how to register new
attributes. attributes.
Appendix D. Use of SDP for RTSP Session Descriptions Appendix D. Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, [RFC4566]) may be used to The Session Description Protocol (SDP, [RFC4566]) may be used to
describe streams or presentations in RTSP. This description is describe streams or presentations in RTSP. This description is
typically returned in reply to a DESCRIBE request on an URI from a typically returned in reply to a DESCRIBE request on an URI from a
server to a client, or received via HTTP from a server to a client. server to a client, or received via HTTP from a server to a client.
skipping to change at page 222, line 12 skipping to change at page 226, line 12
1. the RTSP Content-Base field; 1. the RTSP Content-Base field;
2. the RTSP Content-Location field; 2. the RTSP Content-Location field;
3. the RTSP Request-URI. 3. the RTSP Request-URI.
If this attribute contains only an asterisk (*), then the URI SHALL If this attribute contains only an asterisk (*), then the URI SHALL
be treated as if it were an empty embedded URI, and thus inherit the be treated as if it were an empty embedded URI, and thus inherit the
entire base URI. entire base URI.
Note, RFC 2326 was very unclear on the processing of relative URI
and several RTSP 1.0 implementations at the point of publishing
this document did not perform RFC 3986 processing to determine the
resulting URI, instead simple concatenation is common. To avoid
this issue completely it is recommended to use absolute URI in the
SDP.
The URI handling for SDPs from container files need special The URI handling for SDPs from container files need special
consideration. For example lets assume that a container file has the consideration. For example lets assume that a container file has the
URI: "rtsp://example.com/container.mp4". Lets further assume this URI: "rtsp://example.com/container.mp4". Lets further assume this
URI is the base URI, and that there is a absolute media level URI: URI is the base URI, and that there is a absolute media level URI:
"rtsp://example.com/container.mp4/trackID=2". A relative media level "rtsp://example.com/container.mp4/trackID=2". A relative media level
URI that resolves in accordance with RFC 3986 [RFC3986] to the above URI that resolves in accordance with RFC 3986 [RFC3986] to the above
given media URI is: "container.mp4/trackID=2". It is usually not given media URI is: "container.mp4/trackID=2". It is usually not
desirable to need to include in or modify the SDP stored within the desirable to need to include in or modify the SDP stored within the
container file with the server local name of the container file. To container file with the server local name of the container file. To
avoid this, one can modify the base URI used to include a trailing avoid this, one can modify the base URI used to include a trailing
skipping to change at page 225, line 7 skipping to change at page 229, line 12
Section 4.6 and MAY be extended with further formats. Any open ended Section 4.6 and MAY be extended with further formats. Any open ended
range (start-), i.e. without stop range, is of unspecified duration range (start-), i.e. without stop range, is of unspecified duration
and SHALL be considered as non-seekable content unless this property and SHALL be considered as non-seekable content unless this property
is overridden. Multiple instances carrying different clock formats is overridden. Multiple instances carrying different clock formats
MAY be included at either session or media level. MAY be included at either session or media level.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Examples: Examples:
a=range:npt=0-34.4368 a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203 a=range:clock=19971113T211503Z-19971113T220300Z
Non seekable stream of unknown duration: Non seekable stream of unknown duration:
a=range:npt=0- a=range:npt=0-
D.1.7. Time of Availability D.1.7. Time of Availability
The "t=" field MUST contain suitable values for the start and stop The "t=" field MUST contain suitable values for the start and stop
times for both aggregate and non-aggregate stream control. The times for both aggregate and non-aggregate stream control. The
server SHOULD indicate a stop time value for which it guarantees the server SHOULD indicate a stop time value for which it guarantees the
description to be valid, and a start time that is equal to or before description to be valid, and a start time that is equal to or before
the time at which the DESCRIBE request was received. It MAY also the time at which the DESCRIBE request was received. It MAY also
skipping to change at page 225, line 51 skipping to change at page 230, line 8
The optional "a=etag" attribute identifies a version of the session The optional "a=etag" attribute identifies a version of the session
description. It is opaque to the client. SETUP requests may include description. It is opaque to the client. SETUP requests may include
this identifier in the If-Match field (see Section 16.24) to only this identifier in the If-Match field (see Section 16.24) to only
allow session establishment if this attribute value still corresponds allow session establishment if this attribute value still corresponds
to that of the current description. The attribute value is opaque to that of the current description. The attribute value is opaque
and may contain any character allowed within SDP attribute values. and may contain any character allowed within SDP attribute values.
ABNF for the attribute is defined in Section 20.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=etag:158bb3e7c7fd62ce67f12b533f06b83a a=etag:"158bb3e7c7fd62ce67f12b533f06b83a"
One could argue that the "o=" field provides identical One could argue that the "o=" field provides identical
functionality. However, it does so in a manner that would put functionality. However, it does so in a manner that would put
constraints on servers that need to support multiple session constraints on servers that need to support multiple session
description types other than SDP for the same piece of media description types other than SDP for the same piece of media
content. content.
D.2. Aggregate Control Not Available D.2. Aggregate Control Not Available
If a presentation does not support aggregate control no session level If a presentation does not support aggregate control no session level
"a=control:" attribute is specified. For a SDP with multiple media "a=control:" attribute is specified. For a SDP with multiple media
skipping to change at page 227, line 4 skipping to change at page 231, line 7
In this scenario, the server has multiple streams that can be In this scenario, the server has multiple streams that can be
controlled as a whole. In this case, there are both a media-level controlled as a whole. In this case, there are both a media-level
"a=control:" attributes, which are used to specify the stream URIs, "a=control:" attributes, which are used to specify the stream URIs,
and a session-level "a=control:" attribute which is used as the and a session-level "a=control:" attribute which is used as the
Request-URI for aggregate control. If the media-level URI is Request-URI for aggregate control. If the media-level URI is
relative, it is resolved to absolute URIs according to Appendix D.1.1 relative, it is resolved to absolute URIs according to Appendix D.1.1
above. above.
Example: Example:
C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0 C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Date: Thu, 23 Jan 1997 15:35:06 GMT Date: Thu, 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/ Content-Base: rtsp://example.com/movie/
Content-Length: 228 Content-Length: 227
v=0 v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.211 o=- 2890844256 2890842807 IN IP4 192.0.2.211
s=I contain s=I contain
i=<more info> i=<more info>
e=adm@example.com e=adm@example.com
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
t=0 0
a=control:* a=control:*
t=0 0
m=video 8002 RTP/AVP 31 m=video 8002 RTP/AVP 31
a=control:trackID=1 a=control:trackID=1
m=audio 8004 RTP/AVP 3 m=audio 8004 RTP/AVP 3
a=control:trackID=2 a=control:trackID=2
In this example, the client is required to establish a single RTSP In this example, the client is required to establish a single RTSP
session to the server, and uses the URIs session to the server, and uses the URIs
rtsp://example.com/movie/trackID=1 and rtsp://example.com/movie/trackID=1 and
rtsp://example.com/movie/trackID=2 to set up the video and audio rtsp://example.com/movie/trackID=2 to set up the video and audio
streams, respectively. The URI rtsp://example.com/movie/, which is streams, respectively. The URI rtsp://example.com/movie/, which is
skipping to change at page 229, line 12 skipping to change at page 233, line 12
care to follow the recommendations about availability in the SDP care to follow the recommendations about availability in the SDP
specification [RFC4566]. specification [RFC4566].
Appendix E. Text format for Parameters Appendix E. Text format for Parameters
A resource of type "text/parameters" consists of either 1) a list of A resource of type "text/parameters" consists of either 1) a list of
parameters (for a query) or 2) a list of parameters and associated parameters (for a query) or 2) a list of parameters and associated
values (for an response or setting of the parameter). Each entry of values (for an response or setting of the parameter). Each entry of
the list is a single line of text. Parameters are separated from the list is a single line of text. Parameters are separated from
values by a colon. The parameter name SHALL only use US-ASCII values by a colon. The parameter name SHALL only use US-ASCII
visable characters while the values are UTF-8 text strings. visable characters while the values are UTF-8 text strings. The
media type registration template is in Section 22.15.
There exist a potential interoperability issue for this format. It There exist a potential interoperability issue for this format. It
was named in RFC 2326 but never defined, even if used in examples was named in RFC 2326 but never defined, even if used in examples
that hint at the syntax. This format matches the purpose and its that hint at the syntax. This format matches the purpose and its
syntax supports the examples provided. However, it goes further by syntax supports the examples provided. However, it goes further by
allowing UTF-8 in the vaue part, thus usage of UTF-8 strings may not allowing UTF-8 in the vaue part, thus usage of UTF-8 strings may not
be supported. However, as individual parameters are not defined, the be supported. However, as individual parameters are not defined, the
using application anyway needs to have out-of-band agreement or using using application anyway needs to have out-of-band agreement or using
feature-tag to determine if the end-point supports the parameters. feature-tag to determine if the end-point supports the parameters.
skipping to change at page 230, line 38 skipping to change at page 234, line 38
o The round-trip time can be estimated as in TCP (RFC 1123) o The round-trip time can be estimated as in TCP (RFC 1123)
[RFC1123], with an initial round-trip value of 500 ms. An [RFC1123], with an initial round-trip value of 500 ms. An
implementation may cache the last RTT measurement as the initial implementation may cache the last RTT measurement as the initial
value for future connections. value for future connections.
o If RTSP is used over a small-RTT LAN, standard procedures for o If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those used in optimizing initial TCP round trip estimates, such as those used in
T/TCP (RFC 1644) [RFC1644], can be beneficial. T/TCP (RFC 1644) [RFC1644], can be beneficial.
o The Timestamp header (Section 16.50) is used to avoid the o The Timestamp header (Section 16.50) is used to avoid the
retransmission ambiguity problem XXY Need ref for Stev94:TCP and retransmission ambiguity problem [Stevens98].
obviates the need for Karn's algorithm.
o The registered default port for RTSP over UDP for the server is o The registered default port for RTSP over UDP for the server is
554. 554.
o RTSP messages can be carried over any lower-layer transport o RTSP messages can be carried over any lower-layer transport
protocol that is 8-bit clean. protocol that is 8-bit clean.
o RTSP messages are vulnerable to bit errors and should not be o RTSP messages are vulnerable to bit errors and should not be
subjected to them. subjected to them.
skipping to change at page 232, line 17 skipping to change at page 236, line 17
This section contains notes on issues about backwards compatibility This section contains notes on issues about backwards compatibility
with clients or servers being implemented according to RFC 2326 with clients or servers being implemented according to RFC 2326
[RFC2326]. Note that there exist no requirement to implement RTSP [RFC2326]. Note that there exist no requirement to implement RTSP
1.0, in fact we recommend against it as it is difficult to do in an 1.0, in fact we recommend against it as it is difficult to do in an
interoperable way. interoperable way.
A server implementing RTSP/2.0 MUST include a RTSP-Version of A server implementing RTSP/2.0 MUST include a RTSP-Version of
RTSP/2.0 in all responses to requests containing RTSP-Version RTSP/2.0 in all responses to requests containing RTSP-Version
RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond RTSP/2.0. If a server receives a RTSP/1.0 request, it MAY respond
with a RTSP/1.0 response if it chooses to support RFC 2326. If the with a RTSP/1.0 response if it chooses to support RFC 2326. If the
server chooses not to support RFC 2326, it SHOULD respond with a 505 server chooses not to support RFC 2326, it SHALL respond with a 505
(RTSP Version not supported) status code. A server MUST NOT respond (RTSP Version not supported) status code. A server MUST NOT respond
to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0 to a RTSP-Version RTSP/1.0 request with a RTSP-Version RTSP/2.0
response. response.
Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP- Clients implementing RTSP/2.0 MAY use an OPTIONS request with a RTSP-
Version of 2.0 to determine whether a server supports RTSP/2.0. If Version of 2.0 to determine whether a server supports RTSP/2.0. If
the server responds with either a RTSP-Version of 1.0 or a status the server responds with either a RTSP-Version of 1.0 or a status
code of 505 (RTSP Version not supported), the client will have to use code of 505 (RTSP Version not supported), the client will have to use
RTSP/1.0 requests if it chooses to support RFC 2326. RTSP/1.0 requests if it chooses to support RFC 2326.
skipping to change at page 233, line 7 skipping to change at page 237, line 7
Some server implementations of RFC 2326 maintain a one-to-one Some server implementations of RFC 2326 maintain a one-to-one
relationship between a connection and an RTSP session. Such relationship between a connection and an RTSP session. Such
implementations require clients to use a persistent connection to implementations require clients to use a persistent connection to
communicate with the server and when a client closes its connection, communicate with the server and when a client closes its connection,
the server may remove the RTSP session. This is worth noting if a the server may remove the RTSP session. This is worth noting if a
RTSP 2.0 client also supporting 1.0 connects to a 1.0 server. RTSP 2.0 client also supporting 1.0 connects to a 1.0 server.
Appendix H. Open Issues Appendix H. Open Issues
This section contains a list of open issues that still needs to be Open issues are filed and tracked in the bug and feature trackers at
resolved. However also any open issues in the bug tracker at http://rtspspec.sourceforge.net. Open issues are discussed on MMUSIC
http://rtspspec.sourceforge.net should also be considered. list.
1. Should the SMPTE range format be updated to support the 50 and
60 frames per second modes?
2. Should we define a recommended format for error message bodies?
3. Today there is no recommended or required format for 300
response entities containing URI lists. Should one be defined?
4. Should the dest_addr parameter in the Transport header in
responses include the destination used by the server?
5. Should a IPv6 multicast scope parameter for the Transport header
be defined? This would be similar to TTL.
6. The Expires header (Section 16.22 contains the below paragraph:
Expires header field with a date value of some time in the
future on a media stream that otherwise would by default be non-
cacheable indicates that the media stream is cacheable, unless
indicated otherwise by a Cache-Control header field
(Section 16.10).
Is there any purpose for this in RTSP, or could we remove this
statement and instead rely on the Cache-Control header?
7. Should proxies strip out the credentials for themselves when
forwarding messages with Accept-Credentials?
8. Is Session ID combined with TLS a sufficient mechanism to
prevent hijacking?
9. Move to start TLS mechanism like the one defined in RFC 2817?
10. Look into the GRID communities proxy-certs and see how this
relates to the current TLS proxy solution.
11. Resolve Eric Rescorlas security comments on the Proxy TLS
solution:
1. There doesn't seem to be any way to communicate your cipher
suite preferences.
2. I don't see how certificate-based client authentication
works. Is it supposed to?
3. You need to provide the entire cert chain in Connection-
Credentials, not just the certificate.
12. Consider to switch to SHA256 instead of SHA1 for the digest over
the DER encoded certs.
13. Resolve the following Stephen Farrel issue: "C. I don't
understand how the client-side proxies can be expected to know
enough about proxies existing toward the server. If they don't
then I'm not sure how they can be expected to make any decision
that's better than would be the case were policy to be dealt
with solely on a hop-by-hop basis. Maybe I'm missing something
that can provide that information?"
14. Resolve the following Stephen Farrel issue: "D. The "User"
policy model is that a client presents acceptable name/URIs and
digests to the proxy. TLS doesn't really provide a way for that
proxy, as a client, to ask the server for the "right"
certificate, so I suspect there's a gap here that'll be hard to
fill. (If the client imposed a constraint as to the root-CA
that had to be used then that'd map to the next TLS connection,
but maybe it'd be too coarse-grained?)"
Appendix I. Changes Appendix I. Changes
Compared to RTSP 1.0 (RFC 2326), the below changes has been made when Compared to RTSP 1.0 (RFC 2326), the below changes has been made when
defining RTSP 2.0. Note that this list does not reflect minor defining RTSP 2.0. Note that this list does not reflect minor
changes in wording or correction of typographical errors. changes in wording or correction of typographical errors.
o The section on minimal implementation was deleted without o The section on minimal implementation was deleted without
substitution. substitution.
skipping to change at page 244, line 10 skipping to change at page 248, line 5
o Aravind Narasimhan contributed by rewriting Media Transport o Aravind Narasimhan contributed by rewriting Media Transport
Alternatives (Appendix C) and editorial improvements on a number Alternatives (Appendix C) and editorial improvements on a number
of places in the specification. of places in the specification.
Appendix K. RFC Editor Consideration Appendix K. 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 [RFC5124]
receives.
Authors' Addresses Authors' Addresses
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
 End of changes. 168 change blocks. 
557 lines changed or deleted 730 lines changed or added

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